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."
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.
Bog standard ray tracing, which is what intel are harping on about at the moment isn't the be all and end all of global illumination algorithms, as many people who get all misty eyed about the technique would have you believe. It's terrible for diffuse interactions for one thing. Photon mapping is a more realistic technique which simulates light more accurately.
Tim.
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.
I'm sure there's some market for these things, but there's so much more involved even after these algorithms are implemented. Now you have to add settings (or additional texture maps), for each object (or light). As soon add something with live reflections, you can't even throw away what's not on screen (or facing away from camera). So your memory requirements jump just because of that. There's many things that have to come in to place for these technologies are adopted widely. A lot of these algorithms have been around for over 25 years already and are just seeing wide adoption in feature films (most would be surprised at how much is faked, even today).
I hope there's a class of games that don't use these things or take 1 or 2 of these things and use them in innovative ways. While I like the WW2 (or futuristic) FPS games, I feel all that dev time is better spent on innovative game play.
Sorry that the brief reply I planned turned in to a rant.
"Ray tracing" traditionally means specifically tracing rays from the eye out into the scene. Other methods are usually referred to by different names.
And even so, while tracing either photons or eye rays may be the most feasible method at the moment, it is by no mean the only way to solve the rendering equation, nor any kind of theoretical best.
Except the double-slit experiment. It's based on the fact that light has wavefront qualities, while ray tracing treats it as particles.
I also strongly doubt that the discreet ray approach will ever produce very good global illumination, since the number of rays bouncing between surfaces quickly grows towards infinite as the desired accuracy grows.
You'd need to do "wavefront racing" to fix these, and I for one have no idea how to do this - solve the quantum field equations for each particle in the scene after inventing the Grand Unified Theory ?-)
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
As far is I've understood it he isn't exactly using the octree for LOD but for storing all voxel data in s parse (there we have it ;) manner. If you only have one "layer" of voxels at whatever resolution defining eg. only the surface of things, most nodes of the octree will remain empty, and so you can reduce the data set to storing only what's necessary for rendering instead of having to store a full-resolution 3D representation of your space.
Of course this leans happily towards a LOD system, as storing the data in different resolutions aka mip-mapping the geometry and then accessing the right detail level would essentially be for free if you do it right.
In the end it's a promising approach with of course many details to be sorted out - there's still a lot of data to be stored per-voxel (texture coordinates, normals, basically everything that now goes into a vertex) if you want the full feature set like eg. lighting and such. But given dedicated hardware and combined with his mega texture stuff (which is basically only glorified unique UV mapping, perhaps somewhat generalized and with a good resource management system behind it) this could be pretty cool.
> Do you have any publications you can point me towards?
Hmm... well, I write here under a pseudonym so it's hard to look up my work. But you can look up 'TreeSPH' in google for some good references to lots of astrophysical implementation. The 'Tree' part is obviously the voxel octtrees, while the 'SPH' means they added hydrodynamics to it by making 'blobs' that have a variable kernel size for smoothing over neighbors.
Which basically means, for hydrodynamics, if it's uniform density you can use a single large 'blob' to represent it, while in an area where the density is rapidly changing you go to smaller 'blobs' because you need more computation. You then use a kernel function, which basically means how much you smooth over neighbors to get a good distribution. With this, you spend all your hydrodynamic computation time on the rapidly changing, shocky, or active stuff. So it's another example of how to decompose a problem they way Carmack seems to be suggesting.
Funny thing is, in astrophysics, this stuff came out in the late 80s/early 90s, and astrophysics usually lags behind physics by a half a decade, which lags behind pure math by a decade. I think the challenge for getting into gaming is converting codes intended for cluster/supercomputer massive calculations into the realm of fast PC gaming.
Tree codes are already heavily used in computer gaming (browsing through 'Computer Developer' magazine shows they are used for dynamic line-of-sight work a lot), so none of what Carmack suggests is cutting edge comp sci in theory. In fact, he used binary space partitioning with Doom, which is in the same field. Much as with Doom etc, the key is can he come up with a fast implementation (or even approximation). I think that's his real talent-- taking existing methods and concepts and figuring out a 'real world' implementation that's fast enough for gaming. He's a programming engineer of no small talent.
A.
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
Tracing into an SVO structure can be done with almost a Bresenham algorithm, and when you reach whatever depth of descent you want (a critical factor, you aren't going all the way to final detail on every trace), you pop out whatever data is stored there (probably some vector quantized BRDF sort of thingy) and run a "fragment program" on it.
The data sets for a game world represented like this would be massive, but it is intrinsically well suited for streaming, even over the internet, which may well be the dominant media distribution channel in the timeframe we are looking at.
John Carmack