Slashdot Mirror
Carmack Speaks On Ray Tracing, Future id Engines
Vigile writes "As a matter of principle, when legendary game programmer John Carmack speaks, the entire industry listens. In a recent interview he comments on a multitude of topics starting with information about Intel, their ray tracing research and upcoming Larrabee GPU. Carmack seems to think that Intel's direction using traditional ray tracing methods is not going to work and instead theorizes that using ray casting to traverse a new data structure he is developing is the best course of action. The 'sparse voxel octree' that Carmack discusses would allow for 'unique geometry down to the equivalent of the texel across everything.' He goes on to discuss other topics like the hardware necessary to efficiently process his new data structure, translation to consoles, multi-GPU PC gaming and even the world of hardware physics."
Ray Tracing has a place. New high speed FPS games are not it.
My biggest concern with where he is going with this is that it does not sound like it will play very nice with physics. In page two he makes some comments on how characters and other animated elements will still likely be done with more traditional methods and then mixed with this for the static objects like the world.
The problem with this is that we are moving more and more towards interactive environments where everything from the ground to the flowerpots are breakable, bendable or movable. It doesn't sound like this new system will play very nice with physics intensive or highly interactive environments. Now, i could be completely wrong. He doesn't address the point directly. But it is still a point for concern.
I doubt any mod team was hit harder by that fact than mine. Yet, I can't fault him for the decision. It's unlikely anyone on my team did/does. By supporting almost every hardware graphics accelerator on the market at the time, Quake 3 almost single-handedly fostered the feedback loop that drove mainstream adoption of dedicated graphics accelerators.
You sound like someone that's had the same thought every serious modder/engine-licensee has ever had; "if they could have just included/modified this ONE feature, my game would be feasible/better."
Yet you haven't encountered that phrase enough times to appreciate the fact that engine developers have to draw a performance line somewhere. Your desired feature just happened to be on the wrong side of that line.
Further, engine-developers of John Carmack's caliber would (I promise you this) love to have supported every feature you've ever thought of (and more). John Carmack's always been on the cutting edge, usually refining it. He sometimes makes decisions that are a matter of taste that you can feel free to disagree with him on, but that particular feature wasn't one of them.
Everything light does is a combination of reflections and refractions (shadows are an artifact of those).
So, yeah, what you are in effect saying is that raytracing only provides realistic rendering of things that light actually does.
Color bleeding and caustics are effects of reflection, subsurface scattering is reflection and refraction, depth of field is refraction (through a lens between the viewpoint and the image). Now, its true, that there are shortcuts that provide tolerable approximations of those effects faster than actually tracing rays in most cases, and that even static raytracers often prefer those to what would be necessary to do those effects through raytracing alone. Its also true that some real effects, to do well with raytracing, would require shooting separate rays for different wavelengths of light, which while conceptually possible (and I think some very specialized systems have been made which do this), is probably utterly impractical for realtime systems for the forseeable future (this is a lot bigger load increase than anti-aliasing would be.)
But as for realism (but not necessarily practicality, especially in a realtime setting), I think raytracing still, ultimately, wins on all of those.
Give me a little credit here. I am not suggesting that everyone blindly intersects rays with a huge list of triangles. That would be absurd, and I assumed everyone understood that. What you might have missed is that I'm not proposing a sparse voxel octree as some form of bounding hierarchy to reduce intersection tests against triangles, I am proposing that it REPLACE hierarchies of triangles or other primitives for some data sets, and this brings about significant improvements (data size) that you wouldn't have with even infinitely fast conventional ray tracing. I'm also not trying to say that this is some novel brainstorm of mine, but I have some practical experience with the direction, and I think it has promise.
One of my major points is that this is all still theoretical. I don't know what is going to be the right architecture for next gen systems. Neither do you, or Intel, Nvidia, Microsoft, Sony, or Nintendo. If I had to place a bet, it is that rasterization will still be dominant, but it is a Good Thing to have lots of people doing research into various alternatives. All the players have their own agendas, but we will all know the big win when we see it.
John Carmack
Good point.
Well, yeah, the "raytracing is ideally photorealistic" argument does rely (even ignoring the wave effects that raytracing misses), essentially, on unlimited processing power and memory, and isn't necessarily applicable in any particular practical domain. My reference to shortcut techniques to directly model particular phenomena instead of tracing all the necessary rays being a feature of even static raytracing package, and to many of the idealized advantages of raytracing not being realized in practice was based on that.
That sounds about right, probably using a quantum computer "graphics card" (QGPU?).