I hope they do, and given that Google owns Youtube, it's within the realm of possibility. I think it's kind of sad that web developers don't treat video the way they treat jpegs and pngs and everything else on a web page you can save with a right click.
I don't expect youtube to change, though, until browser support for video in (at least) firefox is very good. (Meaning it doesn't require external plugins or viewers, there's a consistent and perhaps extendable interface, capability to play back the video without downloading the whole thing, and good support for scaling the video quality to match available bandwidth.) I'm not sure where it's at now, but in the past I've been less than impressed by video support in firefox (probably due to badly configured plugins, but still I tend to assume that my own experiences are fairly representative).
Why not simply provide an anchor (link) to an industry standard mpeg file that I can download and view?
If you mean, in addition to the flash video, I think the answer is pretty obvious: because they don't want their users downloading and saving videos. Yes, this is annoying, and no, they aren't going to stop everyone, but their goal isn't to stop everyone, it's to stop most people.
If you mean instead of flash, then there are several objections: a) mpeg is patent encumbered, and not everyone is going to be able to view it without downloading a (potentially illegal in some jurisdictions) mpeg viewer program, b) downloading and then viewing in an external program (if that's what you're implying) isn't much fun when you want to watch a lot of videos. Suppose you wrote a web browser that didn't do jpeg, but you're free to download the jpegs and view them in gimp if you like. Do you suppose web developers are going to bother to support that browser? c) mpeg wasn't designed with streaming in mind. I don't see any reason why a decent mpeg player would need to download the whole file before it starts playing, but mpeg is not capable of adapting its bandwidth use on the fly. And d) if you use a video plugin like mplayer or vlc, there's no guarantee that it will have a consistent, usable interface, or that that interface can be extended.
I'm no fan of flash, but I think the open source community (and the mozilla developers in particular) have dropped the ball on video support. Maybe if it was in a better state, youtube would still have chosen flash so they can keep their users from downloading the videos. But, the way I see it, they didn't have any really great alternatives to flash at the time the site was first created.
You mean via mplayer or other similar plugins? Sure, that's an option, but as far as I understand, mplayer infringes on a number of patents, and so it's not strictly legal in all jurisdictions. I just checked, and Ogg theora works fine in firefox on my system (thanks to vlc, mplayer, and totem plugins; I have no idea which one is actually rendering the video). But how many windows firefox installs also have a theora plugin? (Not a rhetorical question, I'd actually be interested in an answer.) Having some form of video support in the mainline browser code and not as an optional add-on is very important if you expect major sites to use something other than flash for video, and that's probably not going to happen with mpeg until all the relevant patents expire.
There's also the issue of being able to start watching the video before the whole thing downloads (probably not an issue with mpeg, but I don't know how well the plugins handle streaming), and the ability for the video to adapt to available bandwidth, something that mpeg does not do.
I don't disagree that flash is bad for the web, but in order to convince developers not to use it, there needs to be a valid alternative. If youtube didn't use flash for video, what would they use instead? Animated gifs? Expecting a site like youtube to just not serve video because there isn't a free software way to do what they want to do is unreasonable.
We really need at least some form of video integrated into the browser, and it looks like we might have it in firefox soon, (better many years too late than never). Then, we can at least give sites the option of serving video to browsers that support theora but not flash.
Without video, it's hard to know what they mean by "fully interactive". (Perhaps someone who saw the demo at siggraph can enlighten me.) Do they mean, interactive framerates with static geometry and a moving camera? Or do they actually move the geometry around in the scene? From the screenshots, I would guess that maybe the car moves and not much else. If that's the case, it's a impressive demo, but it doesn't address one of the hardest problems, which is how do you re-arrange the acceleration structures when anything moves?
A good implementation of BIH ought to be able to handle a few thousands or tens of thousands of independently moving objects at reasonable framerates, but traversal costs are usually a bit higher than a SAH-based kd-tree. High frame-rates are neat, but if they had to spend an hour or two to generated an optimized tree, then their accomplishment is a little less impressive. (Which isn't to say that it's not impressive at all.)
I've implemented a few variations of pagerank myself (in C, ocaml, and lua), and none of those implementations were particularly complicated, even with the addition of a few non-standard extensions of my own. (Unfortunately, the patent situation has prompted me to keep that code to myself.) You are correct; pagerank is simple and well-understood by many.
"What I've leaned about how Democrats lose? Democrats lose when they are not clear about what they stand for. Democrats lose when they are attacked and because they don't know where they stand they end up getting defensive instead of going on the offensive."
I don't see how this strategy is likely to win him more votes. I hope he changes his mind.
I don't know if there is a decent level of multi-threading in that particular game though, so that could have something to do with it.
Also, a big factor would be whether the AI is written in something like C or something like Python. I don't doubt that there are a multitude of ways of implementing AI that would suck up all the CPU resources available, but assuming a computer fast enough to do real-time ray tracing, and assuming the NPCs don't have to be good "go" players, a sensible implementation ought to be able run AI scripts and do ray tracing at the same time.
If processor power isn't enough to handle a crowd of NPCs that don't have much of an agenda in a game, how do we have enough processing power to handle the game AI PLUS Ray Tracing?
I'm not much of a gamer, but I'm skeptical of the claim that AI is really using all that CPU power. I would guess that most of the CPU resources in a modern game are devoted to managing the complexity of the 3-d models the GPU has to render. But, if we assume that AI and physics really do use the whole CPU, and that the CPU is fast enough to do ray tracing and nothing else, and that Moore's law holds, t
hen we can just wait another 18 months and have a CPU that's fast enough to do both at the same time. I don't really see this as a show-stopper for ray tracing except maybe in the near future (the next five years or so).
Also, consider that the ability to trace rays is not just useful for graphics but also for physics and AI. Storing all that geometry data in one place rather than having one copy in the video card and another copy in memory for the physics and AI seems like a good idea to me.
Also, it's pretty likely that if ray tracing does become popular, we'll have some form of hardware-accelerated ray tracing eventually, making your concerns moot.
If Ray Tracing gives a 100 percent perfect rendering, and the tricks allow for something to get to 98 percent, how many people will really notice the difference?
There are several reasons. Firstly, I don't think it's realistic to say it's a difference between 100% and 98%; if I had to make up some numbers, I'd say it's more like 50% vs 60%. Rasterization algorithms are never going to be confused with reality without a lot of pre-baked lighting effects and a lot of squinting, no matter how many polygons they can handle. Polygon counts aren't the only measure of realism.
Whitted-style ray tracing isn't really all that realistic either, but with ray tracing there is a more obvious upgrade path to real-time global illumination, which is where we're going to have to go in order to get to 98%. (I recommend you spend some time browsing Henrik Jensen's web page if you want to know what I mean.)
Also, ray tracers are in many ways easier to work with (as the article attests). Artist can focus on the actual art, rather than being distracted by all the little tricks you need to do to make everything work. Ray tracers are also less sensitive to scene complexity, so artists are less constrained about the kinds of details they can show. Tools that are easier to use translate to better games on smaller budgets.
I don't know what sort of filtering current games do on the final image, but it makes sense to do more filtering with a ray tracer because tracing more rays is so expensive. I expect the technique is more common on off-line renderers.
(Texture filtering is pretty widely used everywhere, but that's a separate issue.)
I think your definition of "looks like crap" is different than mine. I think they look pretty good. And I think their accomplishment is even more impressive when you consider that Outbound was made by a handful of students in about a year using experimental tools.
Also, the high-resolution images don't seem to have done much anti-aliasing, which would have improved the perceived quality significantly. (Outbound does support a range of AA settings. Perhaps Bikker didn't want to be accused of submitting images that weren't representative of actual gameplay.)
Also consider that Twilight Princess et. al. were made on a large budget and likely employed many of the best artists in the industry. You can do a lot with limited polygon counts and pre-baked textures if you have a lot of manpower.
Why spend the computing power in realtime raytracing when you can bake the static lighting into PTMs (polynomial texture maps), or the dynamic lighting into spherical harmonics maps, and use these to reconstruct the illumination, including self-shadowing effects, with convincing effects, at a fraction of the cost?
Because a) all those maps take up memory that could be used elsewhere and b) they don't take into account moving objects or lights.
This is not to say the existing technology is without faults, only that this raytracing issue seems to have finally caught up with games, and this discussion has been going on for the last +10 years in the traditional CG/VFX area and inevitably the result is always the same > fake the effect, and use raytracing where absolutely necessary
Yes, but finally we have a real, downloadable, playable game with full source code available that runs at a usable framerate on a commodity PC with a high level of detail. No, it isn't fast enough to compete with the latest video cards, and we aren't going to see all the big gaming studios drop everything right now and rush to ray tracing, but these games are a significant accomplishment.
The raster vs ray tracing debate may be quite old, but CPUs are now becoming fast enough to open up a lot of options that weren't available before, and we finally have software that's exercising these new options. I recommend you give Outbound a try if you have a reasonably new Windows machine available; if you're open-minded and observant, you might see a few things you haven't seen before in an interactive game.
If you want to do it right, there's actually quite a bit more to it than you're implying. But I do agree that this isn't exactly a show-stopper for ray tracing. Yes, you need a way to plot pixels on the screen, but it's not like that's an unsolved problem. You could probably even do the necessary filtering with a fragment program and give the video card something useful to do between calls to glVertex2f().
I like POV-Ray for many of the same reasons; the syntax is very friendly and the available primitives give a lot of flexibility. Most of the fastest real-time ray tracers just support triangles, though, because it makes them simpler and you don't have the overhead of deciding which ray-intersection function to use with each primitive.
I think a typical game developer isn't likely to care if they can make exact spheres and cones and such; the majority of real-life objects aren't perfect quadrics, and are most conveniently represented as triangle meshes. Some might be interested in the added flexibility, though. It'll be interesting to see if any popular ray tracing APIs are going to support anything besides triangles.
POV-Ray itself isn't likely to be competitive with real-time ray tracers any time soon. It just isn't designed for speed. I've been writing my own ray tracer in haskell (link) that implements a lot of the same primitives as POV-Ray, (spheres, cones, boxes, differences, intersections, discs, triangles, planes) and uses a good, modern acceleration structure (BIH). It's not really any faster than POV-Ray, though, and doesn't support the vast majority of POV-Ray's obscure features.
Lerner talks about that in the presentation at Google. The "solar panel" is basically a thousand layers or so of thin metal. I don't really know how it's supposed to work (and they aren't really sure how to manufacture it), but it is something they've been thinking about.
It looks like the tech talk is slashdotted, but if memory serves (and I'm not a physicist, so my understanding is fuzzy at best) the idea is that the device (which has some resemblance to a large spark plug) sits in a chamber of has a large electrical current applied and exploits a sequence of unstable states to produce a small ball of plasma where the fusion takes place. The reaction produces X-rays and a directed stream of charged particles. The X-rays are collected by a sort of multilayer onion-like solar panel that converts them to electricity, and the charged particles also get converted directly to electricity. The device can be relatively simple since there's no need for steam turbines. A steady stream of electricity can be produced by repeating the reaction over and over, and storing the output in big capacitors (and part of the resulting energy is used to initiate the next pulse).
The real problem here isn't traffic shaping, but about traffic courtesy.
This is true up to a point. It should be easy to get the offending roommate to cap their bandwidth, but it should also be easy to install a traffic-shaping router (though sadly it's not), and then the problem would be solved without having to get the cooperation of everyone (and every program on every computer) on the network, and for everyone to be constantly self-policing their own network usage.
To solve the problem in one place at a higher layer of abstraction will be more likely to prevent the problem from recurring in a different form later on.
Of course, being on friendly terms with your roommates about these sorts of issues is more important than how the problem is ultimately resolved.
OpenWRT hardware requirements
If it's version 4.0 or earlier (or the L model), it has enough RAM and flash (16MB, 4MB respectively) to run OpenWRT, or other wrt54g-friendly distributions.
(OpenWRT is pretty cool; it has an olsrd package you can install from the web configurator, and with a little bit of effort you can make an ad-hoc mesh. Not useful for traffic shaping, but interesting nonetheless. I expect there are probably tools available to do traffic shaping with OpenWRT as well, I just never needed to mess with that.)
Multimode would be fine as well. Most multimode fiber setups are good for 2 km. Singlemode is good for 20-100 km (depending on the hardware at the ends) and supports much faster data rates, but the equipment at the ends tend to be more expensive. Cable costs about the same either way. The actual fiber is very cheap, it's all the cladding around it that's expensive. Direct-bury cable can cost over a dollar per linear foot, last I checked. You could use cheaper, less well-protected cable and take your chances if ~$1500 is a bit much to spend. (I haven't tried this myself, so I don't know how well it would work.)
Old media converters that convert copper ethernet to fiber ethernet can be had for cheap on ebay; you would need one on each end, and then you can just treat it like a really long ethernet cable. One caveat: fiber ethernet isn't backwards compatible like copper ethernet. If you have a 10mbps media converter at one end, and a 100mbps converter at the other, they won't be able to communicate with each other.
If there's line of sight, I would just go with a wireless solution, but fiber would be my second choice.
It does sound familiar, but probably for a different reason than you're thinking. There was a (rather depressing) book about that scenario that I read recently called The Sparrow. (See also wikipedia link.)
Dedicated ray tracing hardware would be nice. Unfortunately, I don't think any big hardware company is going to invest in the technology until they start feeling the competitive pressure from software renderers.
During the Analyst's Day, Jen-Hsun showed a rendering of an Audi R8 that used a hybrid rasterisation and ray tracing renderer. Jen-Hsun said that it ran at 15 frames per second, which isn't all that far away from being real-time. So I asked David when we're likely to see ray tracing appearing in 3D graphics engines where it can actually be real-time?
"15 frames per second was with our professional cards I think. That would have been with 16 GPUs and at least that many multi-core CPUs â" that's what that is. Just vaguely extrapolating that into our progress, it'll be some number of years before you'll see that in real-time," explained Kirk. "If you take a 2x generational increase in performance, you're looking at least four or five years for the GPU part to have enough power to render that scene in real-time.
Modern real-time ray tracers can get respectable performance without doing any sort of GPU-hybrid trickery, or requiring any hardware other than a fast CPU. For instance, try out the Arauna demo. (Dedicated ray-tracing hardware would be nice, but I'm not aware of any hardware implementation that has significantly outperformed a well-optimized CPU ray tracer. With the resources of a major chip manufacturer I don't doubt it could be done, though.) Arauna and OpenRT and the like might still be a little too slow to run a modern game at high resolution, but they're getting there fast.
"People use ray tracing for real effects as well though. Things like shiny chains and for ambient occlusion (global illumination), which is an offline rendering process that is many thousands of times too slow for real-time," said Kirk. "Using ray tracing to calculate the light going from every surface to every other surface is a process that takes hundreds of hours."
This is just plain ignorant. Naive, O(n^2) radiosity may take that long, or path tracing with a lot of samples per pixel, but a decent photon mapping algorithm shouldn't be anywhere near that slow to produce a rendering quality acceptable for games. Maybe "hundreds of seconds" might be a more plausible number. (Or less, if you're willing to accept a less accurate approximation.) Metropolis Light Transport is another algorithm, but I don't have a good notion of how fast it is.
Slashdot Mirror
I hope they do, and given that Google owns Youtube, it's within the realm of possibility. I think it's kind of sad that web developers don't treat video the way they treat jpegs and pngs and everything else on a web page you can save with a right click.
I don't expect youtube to change, though, until browser support for video in (at least) firefox is very good. (Meaning it doesn't require external plugins or viewers, there's a consistent and perhaps extendable interface, capability to play back the video without downloading the whole thing, and good support for scaling the video quality to match available bandwidth.) I'm not sure where it's at now, but in the past I've been less than impressed by video support in firefox (probably due to badly configured plugins, but still I tend to assume that my own experiences are fairly representative).
If you mean, in addition to the flash video, I think the answer is pretty obvious: because they don't want their users downloading and saving videos. Yes, this is annoying, and no, they aren't going to stop everyone, but their goal isn't to stop everyone, it's to stop most people.
If you mean instead of flash, then there are several objections: a) mpeg is patent encumbered, and not everyone is going to be able to view it without downloading a (potentially illegal in some jurisdictions) mpeg viewer program, b) downloading and then viewing in an external program (if that's what you're implying) isn't much fun when you want to watch a lot of videos. Suppose you wrote a web browser that didn't do jpeg, but you're free to download the jpegs and view them in gimp if you like. Do you suppose web developers are going to bother to support that browser? c) mpeg wasn't designed with streaming in mind. I don't see any reason why a decent mpeg player would need to download the whole file before it starts playing, but mpeg is not capable of adapting its bandwidth use on the fly. And d) if you use a video plugin like mplayer or vlc, there's no guarantee that it will have a consistent, usable interface, or that that interface can be extended.
I'm no fan of flash, but I think the open source community (and the mozilla developers in particular) have dropped the ball on video support. Maybe if it was in a better state, youtube would still have chosen flash so they can keep their users from downloading the videos. But, the way I see it, they didn't have any really great alternatives to flash at the time the site was first created.
You mean via mplayer or other similar plugins? Sure, that's an option, but as far as I understand, mplayer infringes on a number of patents, and so it's not strictly legal in all jurisdictions. I just checked, and Ogg theora works fine in firefox on my system (thanks to vlc, mplayer, and totem plugins; I have no idea which one is actually rendering the video). But how many windows firefox installs also have a theora plugin? (Not a rhetorical question, I'd actually be interested in an answer.) Having some form of video support in the mainline browser code and not as an optional add-on is very important if you expect major sites to use something other than flash for video, and that's probably not going to happen with mpeg until all the relevant patents expire.
There's also the issue of being able to start watching the video before the whole thing downloads (probably not an issue with mpeg, but I don't know how well the plugins handle streaming), and the ability for the video to adapt to available bandwidth, something that mpeg does not do.
I don't disagree that flash is bad for the web, but in order to convince developers not to use it, there needs to be a valid alternative. If youtube didn't use flash for video, what would they use instead? Animated gifs? Expecting a site like youtube to just not serve video because there isn't a free software way to do what they want to do is unreasonable.
We really need at least some form of video integrated into the browser, and it looks like we might have it in firefox soon, (better many years too late than never). Then, we can at least give sites the option of serving video to browsers that support theora but not flash.
Without video, it's hard to know what they mean by "fully interactive". (Perhaps someone who saw the demo at siggraph can enlighten me.) Do they mean, interactive framerates with static geometry and a moving camera? Or do they actually move the geometry around in the scene? From the screenshots, I would guess that maybe the car moves and not much else. If that's the case, it's a impressive demo, but it doesn't address one of the hardest problems, which is how do you re-arrange the acceleration structures when anything moves?
A good implementation of BIH ought to be able to handle a few thousands or tens of thousands of independently moving objects at reasonable framerates, but traversal costs are usually a bit higher than a SAH-based kd-tree. High frame-rates are neat, but if they had to spend an hour or two to generated an optimized tree, then their accomplishment is a little less impressive. (Which isn't to say that it's not impressive at all.)
I've implemented a few variations of pagerank myself (in C, ocaml, and lua), and none of those implementations were particularly complicated, even with the addition of a few non-standard extensions of my own. (Unfortunately, the patent situation has prompted me to keep that code to myself.) You are correct; pagerank is simple and well-understood by many.
Quoting Obama's talk at Google (0:45:45):
"What I've leaned about how Democrats lose? Democrats lose when they are not clear about what they stand for. Democrats lose when they are attacked and because they don't know where they stand they end up getting defensive instead of going on the offensive."
I don't see how this strategy is likely to win him more votes. I hope he changes his mind.
Also, a big factor would be whether the AI is written in something like C or something like Python. I don't doubt that there are a multitude of ways of implementing AI that would suck up all the CPU resources available, but assuming a computer fast enough to do real-time ray tracing, and assuming the NPCs don't have to be good "go" players, a sensible implementation ought to be able run AI scripts and do ray tracing at the same time.
I'm not much of a gamer, but I'm skeptical of the claim that AI is really using all that CPU power. I would guess that most of the CPU resources in a modern game are devoted to managing the complexity of the 3-d models the GPU has to render. But, if we assume that AI and physics really do use the whole CPU, and that the CPU is fast enough to do ray tracing and nothing else, and that Moore's law holds, t hen we can just wait another 18 months and have a CPU that's fast enough to do both at the same time. I don't really see this as a show-stopper for ray tracing except maybe in the near future (the next five years or so).
Also, consider that the ability to trace rays is not just useful for graphics but also for physics and AI. Storing all that geometry data in one place rather than having one copy in the video card and another copy in memory for the physics and AI seems like a good idea to me.
Also, it's pretty likely that if ray tracing does become popular, we'll have some form of hardware-accelerated ray tracing eventually, making your concerns moot.
There are several reasons. Firstly, I don't think it's realistic to say it's a difference between 100% and 98%; if I had to make up some numbers, I'd say it's more like 50% vs 60%. Rasterization algorithms are never going to be confused with reality without a lot of pre-baked lighting effects and a lot of squinting, no matter how many polygons they can handle. Polygon counts aren't the only measure of realism.
Whitted-style ray tracing isn't really all that realistic either, but with ray tracing there is a more obvious upgrade path to real-time global illumination, which is where we're going to have to go in order to get to 98%. (I recommend you spend some time browsing Henrik Jensen's web page if you want to know what I mean.)
Also, ray tracers are in many ways easier to work with (as the article attests). Artist can focus on the actual art, rather than being distracted by all the little tricks you need to do to make everything work. Ray tracers are also less sensitive to scene complexity, so artists are less constrained about the kinds of details they can show. Tools that are easier to use translate to better games on smaller budgets.
I don't know what sort of filtering current games do on the final image, but it makes sense to do more filtering with a ray tracer because tracing more rays is so expensive. I expect the technique is more common on off-line renderers.
(Texture filtering is pretty widely used everywhere, but that's a separate issue.)
I think your definition of "looks like crap" is different than mine. I think they look pretty good. And I think their accomplishment is even more impressive when you consider that Outbound was made by a handful of students in about a year using experimental tools.
Also, the high-resolution images don't seem to have done much anti-aliasing, which would have improved the perceived quality significantly. (Outbound does support a range of AA settings. Perhaps Bikker didn't want to be accused of submitting images that weren't representative of actual gameplay.)
Also consider that Twilight Princess et. al. were made on a large budget and likely employed many of the best artists in the industry. You can do a lot with limited polygon counts and pre-baked textures if you have a lot of manpower.
Because a) all those maps take up memory that could be used elsewhere and b) they don't take into account moving objects or lights.
Yes, but finally we have a real, downloadable, playable game with full source code available that runs at a usable framerate on a commodity PC with a high level of detail. No, it isn't fast enough to compete with the latest video cards, and we aren't going to see all the big gaming studios drop everything right now and rush to ray tracing, but these games are a significant accomplishment.
The raster vs ray tracing debate may be quite old, but CPUs are now becoming fast enough to open up a lot of options that weren't available before, and we finally have software that's exercising these new options. I recommend you give Outbound a try if you have a reasonably new Windows machine available; if you're open-minded and observant, you might see a few things you haven't seen before in an interactive game.
If you want to do it right, there's actually quite a bit more to it than you're implying. But I do agree that this isn't exactly a show-stopper for ray tracing. Yes, you need a way to plot pixels on the screen, but it's not like that's an unsolved problem. You could probably even do the necessary filtering with a fragment program and give the video card something useful to do between calls to glVertex2f().
I like POV-Ray for many of the same reasons; the syntax is very friendly and the available primitives give a lot of flexibility. Most of the fastest real-time ray tracers just support triangles, though, because it makes them simpler and you don't have the overhead of deciding which ray-intersection function to use with each primitive.
I think a typical game developer isn't likely to care if they can make exact spheres and cones and such; the majority of real-life objects aren't perfect quadrics, and are most conveniently represented as triangle meshes. Some might be interested in the added flexibility, though. It'll be interesting to see if any popular ray tracing APIs are going to support anything besides triangles.
POV-Ray itself isn't likely to be competitive with real-time ray tracers any time soon. It just isn't designed for speed. I've been writing my own ray tracer in haskell (link) that implements a lot of the same primitives as POV-Ray, (spheres, cones, boxes, differences, intersections, discs, triangles, planes) and uses a good, modern acceleration structure (BIH). It's not really any faster than POV-Ray, though, and doesn't support the vast majority of POV-Ray's obscure features.
That doesn't sound right. Perhaps you mean $/Gbyte?
There's an xkcd comic for every occasion.
Lerner talks about that in the presentation at Google. The "solar panel" is basically a thousand layers or so of thin metal. I don't really know how it's supposed to work (and they aren't really sure how to manufacture it), but it is something they've been thinking about.
It looks like the tech talk is slashdotted, but if memory serves (and I'm not a physicist, so my understanding is fuzzy at best) the idea is that the device (which has some resemblance to a large spark plug) sits in a chamber of has a large electrical current applied and exploits a sequence of unstable states to produce a small ball of plasma where the fusion takes place. The reaction produces X-rays and a directed stream of charged particles. The X-rays are collected by a sort of multilayer onion-like solar panel that converts them to electricity, and the charged particles also get converted directly to electricity. The device can be relatively simple since there's no need for steam turbines. A steady stream of electricity can be produced by repeating the reaction over and over, and storing the output in big capacitors (and part of the resulting energy is used to initiate the next pulse).
This is true up to a point. It should be easy to get the offending roommate to cap their bandwidth, but it should also be easy to install a traffic-shaping router (though sadly it's not), and then the problem would be solved without having to get the cooperation of everyone (and every program on every computer) on the network, and for everyone to be constantly self-policing their own network usage.
To solve the problem in one place at a higher layer of abstraction will be more likely to prevent the problem from recurring in a different form later on.
Of course, being on friendly terms with your roommates about these sorts of issues is more important than how the problem is ultimately resolved.
OpenWRT hardware requirements If it's version 4.0 or earlier (or the L model), it has enough RAM and flash (16MB, 4MB respectively) to run OpenWRT, or other wrt54g-friendly distributions. (OpenWRT is pretty cool; it has an olsrd package you can install from the web configurator, and with a little bit of effort you can make an ad-hoc mesh. Not useful for traffic shaping, but interesting nonetheless. I expect there are probably tools available to do traffic shaping with OpenWRT as well, I just never needed to mess with that.)
Multimode would be fine as well. Most multimode fiber setups are good for 2 km. Singlemode is good for 20-100 km (depending on the hardware at the ends) and supports much faster data rates, but the equipment at the ends tend to be more expensive. Cable costs about the same either way. The actual fiber is very cheap, it's all the cladding around it that's expensive. Direct-bury cable can cost over a dollar per linear foot, last I checked. You could use cheaper, less well-protected cable and take your chances if ~$1500 is a bit much to spend. (I haven't tried this myself, so I don't know how well it would work.)
Old media converters that convert copper ethernet to fiber ethernet can be had for cheap on ebay; you would need one on each end, and then you can just treat it like a really long ethernet cable. One caveat: fiber ethernet isn't backwards compatible like copper ethernet. If you have a 10mbps media converter at one end, and a 100mbps converter at the other, they won't be able to communicate with each other.
If there's line of sight, I would just go with a wireless solution, but fiber would be my second choice.
It does sound familiar, but probably for a different reason than you're thinking. There was a (rather depressing) book about that scenario that I read recently called The Sparrow. (See also wikipedia link.)
Dedicated ray tracing hardware would be nice. Unfortunately, I don't think any big hardware company is going to invest in the technology until they start feeling the competitive pressure from software renderers.
Modern real-time ray tracers can get respectable performance without doing any sort of GPU-hybrid trickery, or requiring any hardware other than a fast CPU. For instance, try out the Arauna demo. (Dedicated ray-tracing hardware would be nice, but I'm not aware of any hardware implementation that has significantly outperformed a well-optimized CPU ray tracer. With the resources of a major chip manufacturer I don't doubt it could be done, though.) Arauna and OpenRT and the like might still be a little too slow to run a modern game at high resolution, but they're getting there fast.
This is just plain ignorant. Naive, O(n^2) radiosity may take that long, or path tracing with a lot of samples per pixel, but a decent photon mapping algorithm shouldn't be anywhere near that slow to produce a rendering quality acceptable for games. Maybe "hundreds of seconds" might be a more plausible number. (Or less, if you're willing to accept a less accurate approximation.) Metropolis Light Transport is another algorithm, but I don't have a good notion of how fast it is.
Yes, my mistake.