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.
Redo quake? Why?
I guess you haven't seen ezquake (best obtained in the nquake package). A faster, more frantic FPS game you will not find. It's also been substantially improved graphically, so there are many more colours about the place.
Any reworking of quake 1 would be badly received by the old school (by this I mean most people who still play it). New people wouldn't see the need, since most of them have grown up on a different fps style. Why revisit quake 1?
Personally I love the game, and play it often. If I have one criticism its that most of the servers are populated by people who are so good at the game, after playing for so long, that just living long enough to pick up a gun and kill someone can be a real challenge.
Interestingly, raycasting is what id used in Wolfenstein 3D, way back in 1992.
http://en.wikipedia.org/wiki/Ray_casting
Hail Eris, full of mischief...
E pluribus sanguinem
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.
Um, no. What I meant to say is exactly what I said. My first comment was intended to be dismissive, but not of either Carmack's position or TFA so much as the presentation in TFS. And not because someone other than me is considered a "primary expert" (whatever that phrase is supposed to mean) on this subject, which is about as remote from anything that I would claim expertise in as is possible while still being a subject where I am aware of what is going on on even a very general level.
No, my second comment was (aside from the part directly referring to the post it responded to) the comment I probably would have posted at about the same time that I did whether or not I was "called out". Its not uncommon for me to post both short dashes on style (especially somewhat tongue-in-cheek ones) and longer pieces on substance in the same thread on Slashdot, and the latter generally take more reading, consideration, reflection than the former: consequently, they are often (though not always) posted later.
And I never claimed I wasn't being dismissive. Nor, except insofar as explaining, in this post, what it was I was being dismissive of is a "defense", have I posted anything defending that dismissiveness.
Please defend your assertion that any of the arguments I posted (none of which were either intended to, nor serve to, reinforce any dismissiveness) are "cut and paste".
You are misusing quotes here, I'm not sure what you intend by them, but none of the things for which quotes are properly used makes any sense. That aside, you are wrong in both your statemetns: I did take a stand on whether Carmack's approach was better than what he compared it to, and I did not try to imply anything beyond what I said: I said that it was quite clear that Carmack's approach is superior to what he compares it to (naive raytracing against raw triangle meshes), I also said it was questionable how relevant that was to the real alternatives in the domain of raytracing.
If you want a more detailed assessment: by Carmack's own admission, his specific approach is not designed to address or provide many of things held out as unique benefits of raytracing (shadows, multiple-bounce reflections), and it quite obviously isn't "as good" at those things than alternatives which do provide them. OTOH, what little I know of the general datastructure at the heart of his approach (sparse voxel octrees) doesn't provide any reason to think that the general approach couldn't be applied (if it really outperforms other techniques of reducing the number and complexity of ray-object intersection tests, something the TFA provides no evidence of) just as well to the full spectrum of raytracing tasks, including handling reflected rays, so, whether or not this is Carmack's particular interest or something his particular engine will be good for, the approach he is using seems likely, if it is good at all, to be good there, as well. Finally, on an even higher level, I think Carmack is likely correct in arguing (against Intel and others) that hybrid approaches that use raytracing with some other non-raytracing techniques (whether the kind of rasterization popular now, or something else) will have an import
Carmack is knowledgeable of 3D rendering in general, but that doesn't mean he's an expert on ray tracing specifically, and I found nothing in the article to indicate that he is. He appears to be unaware of a large body of research into the acceleration structures and optimization techniques commonly employed by modern ray tracers (Kd-trees, Bounding-interval heirarchies, MLRTA, packet tracing). He correctly claims that ray tracing is not used much by movie studios, but fails to identify one of the main reasons why this is so: ray tracing is not a memory parallel algorithm, and therefore does not perform well rendering scenes that can't fit in main memory on any one computer (citation). This isn't an issue at all for games. Carmack doesn't seem to be aware of the real drawbacks of ray-tracing either (other than a vague notion that it's "really slow", probably based on naive implementations of an algorithm that's been around for almost thirty years), such as the cost of re-building the acceleration structure when something in the scene moves. Can his sparse voxel octree data structure be updated or re-sorted quickly?
I think the parent poster was correct to call attention to the emperor's apparent lack of clothes. Just because Carmack has had a huge influence on interactive 3D gaming doesn't mean his statements should be accepted without scrutiny.
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?).
depth of field is refraction (through a lens between the viewpoint and the image)
No it's not. Depth of field is a function of aperture, and has nothing to do with either lenses or refraction.
So, it's like a variable-resolution three-dimensional bitmap? I can see how you might reduce memory consumption that way, but it would also reduce the fidelity of the rendered image. I'd be curious to know if the memory-quality tradeoff is better than if you were to just (intelligently) simplify the triangle mesh. It's an interesting idea at least.
Perhaps part of the misunderstanding of the article can be attributed to this quote:
Which would seem to imply that your approach is not really, really expensive, which would make sense if you were comparing with a ray tracer with no acceleration structure at all, and if by "expensive" we assume that you mean "processor intensive" rather than "memory intensive". Your sparse voxel octree approach, if I am understanding correctly, gets rid of a lot of ray-primitive intersections. However, those tend not to be the most CPU-expensive part of ray tracing; rather, it's the acceleration structure lookups where most of the time is spent, so I wouldn't expect your approach to be vastly superior to any other real-time ray tracer.
(Perhaps my criticism in another branch of this thread comes across a little too harsh; if so, I apologize. I thought that DragonWriter was being unfairly criticized for treating the article with the same degree of skepticism as if it had been written by someone other than John Carmack, and was perhaps a little over-enthusiastic in backing up his assessment of the article.)
No, raytracing has way too many drawbacks to be used seriously nowadays.
May contain traces of nut.
Made from the freshest electrons.