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."
It as if hundreds of ray tracing fanboys cried out at once, and were silenced.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Don't feel bad, he has probably never heard of you either.
Hi, I Boris. Hear fix bear, yes?
...*MORE SHADES OF BLACK*??!!
A developer who coded the engines that nearly all PC first person shooters have run on. That's obviously not enough to accept his words without hesitation, but obviously the person knows more about high-performance 3D rendering than a random coder like myself.
I respond to your sigs
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.
Because he is more of an engine/renderer designer than game developer.
Its his job, and im pretty sure his passion to think about stuff like this.
You mad
Why not analyse his argument and judge it on it's merits rather then throw it out simply because he is working on an idea of his own?
So, let me get this straight, intel says their baby is the best. Nvidia says theirs is the best. And Carmack is making his own, and saying his is the best. Wow, these articles have all been so informative. I could not possibly have predicted those outcomes.
John Carmack is not a game developer, he's an engine programmer.
Note I'm not arguing for the Doom3 engine...
Truth arises more readily from error than from confusion. -Francis Bacon
Plusses:
- One of the primary fathers of the FPS genre.
- Wolfenstien 3D
- Doom
- Quake 1
- Quake 2
- Quake 3
- Endless articles and commentary on the field
- A shitload of stuff I'm forgetting
Minusses:- "Thought multiplicative lighting was the way to go, rather than dealing with the performance hit of additive lighting in Quake 3."
Conclusion: Carmack sucks!I mean, seriously, what's your point? The man's not actually a God so we shouldn't listen to him? Is there somebody more experienced I should prefer to listen to? Is "n3tcat" the handle for somebody with thirty years experience in first-person shooter engines or something?
John Carmack == Commander Keen == id Software == Doom = Wolfenstein == Quake == ??
You've never heard of any of those? the guys you mention might not even be in gaming if it weren't for Carmack and John Romero.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
surely you mean brown...
What do you mean he's not God? Isn't that heresy? (Or was that written by someone else?)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
In other news, all games will now consist of reflective spheres moving around on checkerboards...
Worst BBC News Stories
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.
Commenting on the fact that it is unsurprising that someone working on a different technique favors that technique over raytracing is not throwing anything out.
Its not a comment either way on the merits.
Were I to comment on the merits, I would point out that his position is both fairly obviously correct (in that sparse voxel octrees or something quite like them is almost beyond question the key to raytracing that's useful for reasonable quality in realtime), and entirely incorrect in his characterization of what everyone else is pushing: he pretends that "everyone" is pushing the most naive, brute force approach to raytracing, in which you don't use any kind of bounding volume structure and just do intersection tests against triangles. I've seen literally no recommendations that do that: almost all involve some form of bounding volume heirarchy, and sparse voxel octrees are just one instance of that (perhaps a fairly ideal one, and that's great). (Also, raytracing isn't limited to triangles, although most performance comparisons of raytracing to raster-based rendering methods use models constructed from triangles because it allows you to compare same-model performance of the different mechanisms; raytracing engines, however, don't generally need to decomposed curved objects into triangle-based approximations to render them in the first place, although this can sometimes be more efficient.)
TFS further misleads by suggesting that Carmack is proposing an alternative to raytracing, when really what he is proposing is a particular approach to raytracing, and, particularly, a particular approach in one well-known problem area in raytracing to which there are currently a whole array of approaches. And his focus on what he wants to get out of raytracing is a little different. But, essentially, his piece, while there are some potentially good criticisms on some particular aspects of and arguments for Intel's specific approach to raytrace, is in accord with (not opposed to) the general idea that raytracing techniques are going to be increasingly important in gaming.
Is that enough "on the merits" for you?
It's like, how much more black could this be? And the answer is none. None more black.
Yet, when I play a game, I'll admit, I'm not playing glaring attention to these faults. The last thing that really bothered me in games was 16-bit color banding and I haven't seen any of that in, oh, like 3 or 4 years.
The gamer side of me agrees with Carmack on things looking cool who cares if it's wrong, the geek side of me is angry and demands it be pixel-accurate.
More Twoson than Cupertino
Funny. It's just freaking amazing that someone would even stoop so low as to mention Gabe Newell and not know Carmack. Hell, the original Half-Life is written on the Quake engine written by Carmack.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Carmack is not saying the industry won't go to ray tracing, but rather that the industry won't abandon rasterization because each has strengths and weaknesses.
He believes the same thing I do - a hybrid approach is most likely, at least in the short term. A sparse voxel octtree (a voxel is a 3d pixel and an octtree is a uniform 3d structure to hold the voxels - they are sparse because most are empty [hold air]) and would work well for ray tracing because it sounds like you'd need to cast rays to find the voxel. I'm not sure why/how it would save on overlapping edges unless the voxel itself holds color (texture) information and is fragment level in detail. Still, that seems like it would be an incredibly large data structure, so I'm sure he's doing some trick that I can't think of at the moment.
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.
If you neglect the impact of mobile objects on diffuse reflections, you CAN pre-generate an entire radiosity map for a game, which is good because it's slow. However, it's an important addition as the "texture", "warmth" and "naturalness" of an image depend on diffuse reflections, not direct reflections.
Ultimately, you need to consider diffuse reflections for all objects. There are a few ray-tracing techniques which, instead of assuming direct reflection only, define a distribution (usually some variant on Gaussian) over which the light is reflected. This isn't quite the same as cone-tracing - cone-tracing is generally a simplified form of this where the distributions are trivial and uniform. Wave-tracing is another method that can be used.
As for what should be done, I'd rather see hardware engineers focus on providing primitives that can support what is needed both now and in the future, as hardware changes relatively slowly. That frees software engineers to develop the best methods they can, without forcing them to wait when they reach the limits of the method.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Now if John Carmack is as legendary as /. is making him out to be, why isn't it John Carmack's Quake/Doom?
George Washington is pretty legendary, but we don't have a George Washington's America, do we? The name is irrelevant. How could the guy who basically invented the First Person Shooter not be legendary? When it first came out, the original Wolfenstein was the most highly optimized game I'd ever played. I still remember thinking it wouldn't run on my slow-ass computer, and being blown away when it ran fast as can be.
ZuluPad, the wiki notepad on crack
In 1996, Quake set the fashion for brown shooters. In 2004, for Doom 3, black was the new brown.
The Church of Carmack condemns your post, a profuse apology and confession is now your only hope to salvation. Belief in ray casting will put you down the road to truth and righteousness! But seriously, Carmack created the FPS genre and is still a leader, which makes him one of the most experienced in his field, so, you know, that kind of helps in creating a "god-like" status, or if your still skeptical, a "mini-god" status. okay, how is "almost-god" sound? At least put the word "God" and "Carmack" in the same sentence somewhere, preferably next to each other...
Interestingly, at least with American McGee, he gave an interview with GFW podcast, where he said that it was the publisher who wanted to put his name on the box, to create brand recognition, not the other way around.
Honest answer? You're a noob. John Carmack is extremely well-known.
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
RTFA, you didn't understand what the guy who wrote the article was saying.
Dude, you got pwned by JOHN CARMACK!
The raytracing applications used for optical system design can do wavefront analysis, as well as wavelength-based dispersion measurements. Calculating the phase of a wavefront at a surface is basically just a distance measurement (taking into account refraction).
It's just a bit more work, and would be unnecessary for most "realistic" scenes, which is why raytracers designed to produce pretty pictures usually skip those features.
I see phase-based optical effects fairly rarely out in the real world (as opposed to in a lab), and I suspect most folks would have never even noticed them.
"I mean, seriously, what's your point? The man's not actually a God so we shouldn't listen to him? Is there somebody more experienced I should prefer to listen to? Is "n3tcat" the handle for somebody with thirty years experience in first-person shooter engines or something?"
Many people with years of experience still make god awful mistakes. Experience can only take you so far considering that experience is also the reason why companies stagnate because people get locked into a certain way of looking at things.
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.)
Huh, I always figured John Carmack would have a sub 1000 uid. Preconceptions have been shattered!
As John mentioned in his post here, these are not new ideas. I remember playing around with raytracing/casting of sparse-octree voxels for fun almost ten years ago, and as a quick :) What is cool is that he thinks that the gaming world is ready for them, and that he is going to try and push the hardware folks to make it happen.
search of the literature shows, I was quite late to the game
One of the most fundamental properties of voxmaps is that the geometry and texture are defined hand-in-hand - they have the same resolution, and every point in the geometry has a unique texture. If you want this, then there are data structures like sparse octrees that store the data quite efficiently.
However, decoupling the geometry and texture opens the door for all sorts of tricks usefull in limited memory situations. It was these tricks that made realtime polygon graphics possible in the past. Things like low resolution polygons with high resolution texture maps, tiled/reused texture maps and layered decals, are all ways to cut down on the amount of data needed while still creating a decent looking scene.
However, as the amount of memory increases, these tricks are less necessary and less desirable. Artists want to be able to paint any part of a scene any way they want - and this is exactly what John has done in id Tech 5, their newest engine. After doing so he did some experimentation and found that storing this data in a sparse octree is even more memory efficient than the way he is doing it now, using pixmaps and polygons. If this approach were to work, artists would then have the same freedom in editing the geometry of the world as they do now with textures - the entire world would have geometry at the resolution of current texture maps with zero additional memory costs. That would be awesome.
For this to work though, you need to be able to render the data efficiently. Raycasting of sparse octrees is one of those embarrassingly parallel problems, and thus hardware acceleration for it is relatively easy. But they don't exist due to lack of market, and unfortunately graphics cards are not well suited for this, IIRC because GPUs mostly accelerate floating point calculations, while descending the sparse-octree uses a lot of integer bit-twiddling (I might be wrong about the reasons here). But with the memory-usage tradeoffs shifting in favor of voxmaps, GPU vendors looking to make their products better suited for general purpose High Performace Computing, and John Carmack pushing for it, this may be an idea whose time has come.
In our current generation codebase we have moved to completely separate representations for rendering and physics, and I expect that to continue in the future. The requirements are different enough to merit different internal storage.
John Carmack