Slashdot Mirror
Ray Tracing for Gaming Explored
Vigile brings us a follow-up to a discussion we had recently about efforts to make ray tracing a reality for video games. Daniel Pohl, a research scientist at Intel, takes us through the nuts and bolts of how ray tracing works, and he talks about how games such as Portal can benefit from this technology. Pohl also touches on the difficulty in mixing ray tracing with current methods of rendering. Quoting:
"How will ray tracing for games hit the market? Many people expect it to be a smooth transition - raster only to raster plus ray tracing combined, transitioning to completely ray traced eventually. They think that in the early stages, most of the image would be still rasterized and ray tracing would be used sparingly, only in some small areas such as on a reflecting sphere. It is a nice thought and reflects what has happened so far in the development of graphics cards. The only problem is: Technically it makes no sense."
I guess one has to state the obvious in that by moving to a process which is not implemented in silicon, as with current graphics cards, the work must necessarily be done in software. That means it runs on CPUs and that's something Intel is involved in where as when you look at the computational share of bringing a game to your senses right now, NVIDIA and ATI/AMD are far more likely to be providing the horsepower than Intel.
But really, even if this wasn't a vested interest case (and it may not be, no harm exploring it after all) - the fact remains that we don't actually need this for games. Graphics hardware has gone down an entirely different route whereby you write little shader programs which create surface visual effects on top of the bread and butter polygons and textures. This is a well established system by now and has a naturally compressive effect. It's like making all your visual effects procedural in nature rather than giving objects simple real-world textures and then doing a load of crazy maths to simulate reality. It works very well. Rememeber a lot of the time you want things to look fantastical and not ultra-realistic so lighting is some of the challenge.
Games aren't having a problem looking great. They're having a problem looking great and doing it fast enough and game developers are having a problem creating the content to fill these luscious realistic-looking worlds. That's actually what's more useful, really. Ways to aid game developers create content in parallel rather than throwing out the current rendering strategy adopted world wide by the games industry.
I remember some scenes that I would create with PoV to sometimes take several hours for a single frame to complete. Now we're looking at doing it in real time. Amazing.
I get tired of hearing this talk about real time ray tracing. They might be able to get basic ray tracing at 15 frames per second or more. But it won't matter, the quality won't be as good as some of the high quality images that you see that take hours to render. Sometimes days.
See, the two are incompatible because the purpose is different. With games, the idea is "How realistic can we make something look at a generated rate of 30 frames per second". But with photorealistic rendering the idea is "How realistic can we make something look, regardless of the time it takes to render one frame."
And as time goes on and processors become faster and faster, the status quo for what people want becomes higher. Things like radiosity, fluid simulations and more becomes more expected and less possible to do in real time. So don't ever count on games looking like those still images that take hours to make. Maybe they could make it look like the pictures from 15-20 years ago. But who cares about that? Real time game texturing already looks better than that.
My blog
HAHAHAHA OPEN SOURCE GAMING? Get out of your dream world. Clearly you are not too knowledgable about games my good sir.
There, fixed that for you.
Raytracing the shiny first-intersection makes a lot of sense, even if it doesn't sell more CPUs. Sure, some day we will all have stunning holistic scene graphs that fit entirely within the pipeline cache of the processor, but it's not yet time for that.
Every change in developing a game engine requires changes in the entire toolset to deal with how to produce assets, how to fit within render time limit budgets, and how to model the scene graph and the logic graphs so that both are easily traversed and managed.
In the meantime, we have a pretty nice raster system right now, with a development strategy that provides for all those needs. You might not think that fullscale raytracing would upset this curve, but I'm not convinced. What do you do when a frame suddenly is taking more than 1/30sec to render, because the player is near a crystalline object and the ray depth is too high? How do you degrade the scene gracefully if your whole engine is built on raytracing? We've all played games where things like this were not handled well.
I contend that game AI is sometimes more advanced than academic AI because game developers are results-oriented and cut corners ruthlessly to achieve something that works well enough for a niche application. The same goes for game graphics: 33 milliseconds isn't enough to render complex scene graphs in an academically perfect and general way, it will require the same results-oriented corner-cutting to nudge the graphics beyond what anyone thought possible in 33ms. If that means using raytracing for a few key elements and ray-casting/z-buffering/fragment-shading the rest of the frame, game developers will do it.
[
This is by far the dumbest statement I've ever read. Somebody has never tried to get a job in the field before eh?
My blog
the fact remains that we don't actually need this for games.
Your post is heavily dependent on availability of suitable hardware. Software can be ported and recompiled to new platforms, but hardware-dependent software has a short lifespan precisely because getting usable hardware doesn't last particularly long. There's a lot of otherwise good enjoyable games which are unplayable now because they depended on the early Voodoo cards or other unrepeated graphics hardware. Now with CPU power ramping back up (relatively speaking), we can pull away from lifespan-limiting dependence on dedicated graphics hardware, and move the full rendering process back to generic CPU hardware.
Torques me off when I want to play something but can't - not because I don't have the horsepower, but because it requires obsolete cards.
BTW: The article notes that RT vastly outperforms raster on very high poly count scenes - that alone is reason to switch.
Can we get a "-1 Wrong" moderation option?
Why not use the old "ray-casting techniques" to take the light backwards from the camera? This would allow you to easily limit which areas of the screen received a full ray traced treatment. You would need to include reflectives as potential light sources for you back trace, but I don't see why it wouldn't be effective.
I'm sure you thought you were being clever, but you weren't.
If you knew anything about parallel algorithms you'd know that it's fairly common to have things that scale with more like 75% efficiency, and you're still happy. It's all down to how much communication is required, and how often it's required. With raytracing normally (as in, a decade ago when I knew anything about this) you'd parallelise over multiple frames. With real-time rendering you'd need to parallelise within a frame. Depending on your scene, there will be a static cost (bounding box calculations) in addition to the per-pixel costs.
jh
jh
Don't remind me. Exactly how a text editor can load slower than Photoshop will perplex me until the end of time.
How are sites slashdotted when nobody reads TFAs?
Good luck with that. Plan on typing out a model?
Ignoring that, taking into account that a coder/modeler isn't all that unlikely, you can't just slap up a game that's a notch above 'hello world' in complexity and wake up to a thriving community eager to have your children. If you want to start a game without paying people to work on it, it'll take time (probably months to years) and a few very interested/dedicated people to get it to go anywhere.
Why do you think so few FOSS games have a plot?
I just read Slashdot for the articles.
I'm assuming you mean casting the rays from the light sources, instead of the camera.
Starting the rays from the light source would be less effective because once you start adding a few more light sources to the scene you are going to have more sets of rays to keep track of then if you were to just cast the rays from the camera. Even worse, you would have to run calculations on rays that would never hit the camera. Either way, you would still have optimize the scene with BSP's or some sort of data structure to avoid unnecessary calculations.
I'm starting to think you are suggesting what they are actually doing now.
Abaddon: An Xbox 360 Indie game
I think the article that your blog entry points to is a much better read on the subject. The article linked in the summary gushes on about how it's finally possible to ray trace in HD in real time, but only if you're willing to build a small cluster computer. In addition, the summary's article goes on about how the ray traced model scales logarithmically while the raster model scales linearly, but it doesn't provide a very rigorous explanation of where the writer is getting these values from.
In short, I don't buy the summary article's viewpoint because at times he can be confusing or ambiguous with respect to his "proof." I like the parent's linked article, because the author of that article at least provides something computationally meaningful to think about.
SRSLY.
Disclaimer: I work for NVIDIA. I speak not for them.
People keep saying this, that raytracing scales up better than rasterization. It's simply not true. Both of them have aspects that scale linearly and logarithmically. They do scale differently, but in a related sort of wy.
Raytracing is O(resolution), and O(ln(triangles)), assuming you already have your acceleration structures built. But guess what? It takes significant time to built your acceleration structures in the first place. And they change from frame to frame.
Rasterization is O(ln(resolution)), and O(triangles). Basically, in a rasterizer, we only draw places that we have triangles. Places that don't have triangles have no work done. But the thing is, we've highly pipelined our ability to handle triangles. When people talk about impacting the framerate, I want to be clear what we're talking about here: adding hundreds, thousands, or even a million triangles is not going to tank the processing power of a modern GPU. The 8800 Ultra can process in the neighborhood of 300M triangles per second. At 100 FPS, that'd be (not suprisingly) 3M triangles per frame.
Modern scenes typically run in the 100-500K triangles per frame, so we've still got some headroom in this regard.
Cheers.
I currently have no clever signature witicism to add here.