John carmack plans to switch to realtime raytracing...
category: general [glöplog]
John Carmack always reminds me of "JP" from the (crappy) movie "Grandma's Boy" - http://www.youtube.com/watch?v=Eaqq1RKXr2A
StormyOrdos : right, and look at this legs
raytracing is to rendering technology what java is to programming languages.
earx : shit ? :D
Somehow this totally fits my previous post then :)
Somehow this totally fits my previous post then :)
...take that back sir, or I must slap you in the face!
This is a serious insult for raytracing.
This is a serious insult for raytracing.
er... he speaks about expecting his prototype to run in 320x240 at 10 fps... that's not even one million rays per second... with CUDA! I don't see how he wants to impress anyone with that...
[ o btw, a mini sparse voxel octree: http://rgba.scenesp.org/iq/computer/pclouds/gfx_pcl_00.htm . Rasterized, not raycasted]
[ o btw, a mini sparse voxel octree: http://rgba.scenesp.org/iq/computer/pclouds/gfx_pcl_00.htm . Rasterized, not raycasted]
Quote:
LOL Internet :DIt's possible we could render the ray traced Amiga juggler today in real time at close to 30 fps-- but barely.
iq > could you elaborate the method ? rasterized not raycasted ?
proyected voxels guardian
Well he's got some points. Obviously rasterization will come to it's bitter end some day. The sparse voxel octree also seems to be an interesting approach. The basic problem is that this technique absolutely will not get the industry of the main problem. With each next gen the industry needs more and more artists. Carmack's solution will involve a lot of additional people who will maintain the huge amount of data being generated. Moreover he will need to develop new tools for sculpting sth like mega ZBrush.
Quote:
I mean, he coded some of the most incredible games ever. He founded ID and earned a great deal of money, plus a few extra Ferraris. He's trying to push the limits of the hardware and has gained credit in the 3D-acceleration industry.
how about making good games like gabe newell and tim sweeney?
Ok, maybe now i can add up a little more on my point of view about it.
thanks, finally a constructive remark :) I was starting to doubt wether it was possible to have a serious and constructive debate about this on pouet. indeed, traversing octrees is more simple for projecting rays on the spliting plane, but that's not where all the code in your traversal goes? I mean, you still have to push back-sided nodes onto a stack for future visit if needed, and this is damn expensive. It means either a random branch to determine wether you have to push or not, or some useless ops to move stuff onto memory and mask a stack pointer increase. in the case of octrees furthemore, you have 8 children, so you have to project against the 3 axis at each traversal step (i'm a bit unsure here, i never coded an octree traversal in my raytracer, for in havran's thesis octrees really had poor scores compared to kdtrees in terms of rendering speed). So i skipped the mplementation of octrees.
On another side, traversing kd-trees is really cheap in my eyes. I have only 7 SSE instructions per node traversal: 3 for projecting the ray onto the splitting plane (set1, sub, mul), and 4 others for comparaisons (2 cmp and 2 movemask). And that's it, the job is done for 4 rays... Yes, i know i'm still using 2*2 ray traversal, i can get even faster by doing 4*4 rays per iteration.
Then, you have probabilities of having lots of cache misses in the kd-tree traversal. A common way to reduce cache misses is to have a kd-tree node structure that takes as few bytes as possible. Currently i'm using 8 bytes per node, 2 bits for spliting plane or leaf flags, a 30 bits index for children, a 32 bits float for spliting plane position. Well, the usual. It's also possible to use only 4 bytes per node/leaf in the kd-tree, if you use the 2 lowest bits of your mantissa for the flags and organize your tree as a heap. But if you don't have a complete tree, which is most likelly the case, you waste huge amounts of memory. And also, you miss 2 bits of accuracy for the spliting plane position. However, it's possible to hack this arround and use the empty space in the heap to store the actual triangles. But we get really nasty there, so that's why i stick to the more elegant 8 byte kd-tree nodes.
About point clouds, i have to admit i dont know the figures about acceleration structures. Maybe octrees are cool for it, maybe there's better. Anyway, point clouds are cool because they are more revealant than triangles when the size of a triangle gets lower than 1 pixel, and intersecting them is much cheaper than intersecting triangles.
However, beting now that you will get dedicated hardware for this in 5 years is even more risky than beting on realtime raytracing for a game engine ;)
But why would you bother using 2 floats for uv when you can use a 32 bits integer for the color directly? ;) it takes less memory... Or even better, work in HSB color space and store only HS on 16 bits, then retreive Brightness through HDR lighting and convert back to rgb. Unless you want to project animated textures on point cloud data, you dont need uvs..
You need normals btw also for shading. You can use a lookup table for normals, 16 bits or 8 bits index even is maybe a good go.
I'm also making this topic whereas i'm in the "carmack is overrated" crowd :D But, i got really convinced by realtime raytracing, and seeing a "VIP" of 3d engines being aware of all the good stuff it can bring for the future makes me really happy. Carmack has always had the skill to foresee the next big changes and make breakthrough by impressing everyone with his technologies, even if people barelly had the hardware to run his games when they got released.
Yes, to be more precise, he wants to make a hybrid engine using raytracing for what it is fastest: static scenes, and merge the framebuffer/depth buffer with rasterised characters it seems. Very good deal. You just have to blit a framebuffer and a zbuffer every frame in HD over the pci-express, but appart from this, everything's fine.
It's also possible to do the raytracing's shading on the gpu if you use the stencil buffer as a shader index. but you need to transfer uvs if you render triangles then too. or render point clouds and tadam, you dont need uvs ;) There are problems however for secondary ray calculations, but you can resolve it by doing secondary ray shading on the CPU. You don't always need the secondary rays anyway in a game.
I suspect however; as NVIDIA and AMD seem to see raytracing as a threat currently for their rasterisation business, that they will keep the pci-express bandwidth artificially down to penalize these approaches. but time will tell. :)
But anyway, the raytracing scaling to higher poly meshes is so logarithmic (you have to multiply the amount of triangles by 1000 to see rendering speed being divided by 2 roughly), that there is always a point in number of triangles where raytracing gets faster than rasterisation, whatever fancy LOD of occlusion technics you use there... Rasterisation fanboys always argue about LOD and occlusion technics but they give flickering artifacts and object popping at the limits. It is possible to also use LOD in raytracing, it's just that its not needed. And you get no popping artifacts or nasty things when using raytracing.. As long as all the data fits in system memory... But the good point is that you have more system memory than GPU memory usually.
Quote:
nystep: and btw, octrees lean toward an efficient hardware implementation, as traversing them just means "flip and leave out bits". KD trees are my choice for software space traversal too tho :)
thanks, finally a constructive remark :) I was starting to doubt wether it was possible to have a serious and constructive debate about this on pouet. indeed, traversing octrees is more simple for projecting rays on the spliting plane, but that's not where all the code in your traversal goes? I mean, you still have to push back-sided nodes onto a stack for future visit if needed, and this is damn expensive. It means either a random branch to determine wether you have to push or not, or some useless ops to move stuff onto memory and mask a stack pointer increase. in the case of octrees furthemore, you have 8 children, so you have to project against the 3 axis at each traversal step (i'm a bit unsure here, i never coded an octree traversal in my raytracer, for in havran's thesis octrees really had poor scores compared to kdtrees in terms of rendering speed). So i skipped the mplementation of octrees.
On another side, traversing kd-trees is really cheap in my eyes. I have only 7 SSE instructions per node traversal: 3 for projecting the ray onto the splitting plane (set1, sub, mul), and 4 others for comparaisons (2 cmp and 2 movemask). And that's it, the job is done for 4 rays... Yes, i know i'm still using 2*2 ray traversal, i can get even faster by doing 4*4 rays per iteration.
Then, you have probabilities of having lots of cache misses in the kd-tree traversal. A common way to reduce cache misses is to have a kd-tree node structure that takes as few bytes as possible. Currently i'm using 8 bytes per node, 2 bits for spliting plane or leaf flags, a 30 bits index for children, a 32 bits float for spliting plane position. Well, the usual. It's also possible to use only 4 bytes per node/leaf in the kd-tree, if you use the 2 lowest bits of your mantissa for the flags and organize your tree as a heap. But if you don't have a complete tree, which is most likelly the case, you waste huge amounts of memory. And also, you miss 2 bits of accuracy for the spliting plane position. However, it's possible to hack this arround and use the empty space in the heap to store the actual triangles. But we get really nasty there, so that's why i stick to the more elegant 8 byte kd-tree nodes.
About point clouds, i have to admit i dont know the figures about acceleration structures. Maybe octrees are cool for it, maybe there's better. Anyway, point clouds are cool because they are more revealant than triangles when the size of a triangle gets lower than 1 pixel, and intersecting them is much cheaper than intersecting triangles.
Quote:
Apart from that the sparse voxel octree is quite good, given dedicated hardware.
However, beting now that you will get dedicated hardware for this in 5 years is even more risky than beting on realtime raytracing for a game engine ;)
Quote:
... and if those voxels are small enough to have a quite 1:1 voxel<->screen pixel representation, you can store tex coords and normals with them and basically use normal pixel/fragment shaders to render them. And geometry level of detail is no problem at all, too.
But why would you bother using 2 floats for uv when you can use a 32 bits integer for the color directly? ;) it takes less memory... Or even better, work in HSB color space and store only HS on 16 bits, then retreive Brightness through HDR lighting and convert back to rgb. Unless you want to project animated textures on point cloud data, you dont need uvs..
You need normals btw also for shading. You can use a lookup table for normals, 16 bits or 8 bits index even is maybe a good go.
Quote:
I'm saying this despite normally being in the "carmack si teh overrated" in-crowd too :)
I'm also making this topic whereas i'm in the "carmack is overrated" crowd :D But, i got really convinced by realtime raytracing, and seeing a "VIP" of 3d engines being aware of all the good stuff it can bring for the future makes me really happy. Carmack has always had the skill to foresee the next big changes and make breakthrough by impressing everyone with his technologies, even if people barelly had the hardware to run his games when they got released.
Quote:
(o_O) I think you didn't get Carmack's point of view.
Yes, to be more precise, he wants to make a hybrid engine using raytracing for what it is fastest: static scenes, and merge the framebuffer/depth buffer with rasterised characters it seems. Very good deal. You just have to blit a framebuffer and a zbuffer every frame in HD over the pci-express, but appart from this, everything's fine.
It's also possible to do the raytracing's shading on the gpu if you use the stencil buffer as a shader index. but you need to transfer uvs if you render triangles then too. or render point clouds and tadam, you dont need uvs ;) There are problems however for secondary ray calculations, but you can resolve it by doing secondary ray shading on the CPU. You don't always need the secondary rays anyway in a game.
I suspect however; as NVIDIA and AMD seem to see raytracing as a threat currently for their rasterisation business, that they will keep the pci-express bandwidth artificially down to penalize these approaches. but time will tell. :)
But anyway, the raytracing scaling to higher poly meshes is so logarithmic (you have to multiply the amount of triangles by 1000 to see rendering speed being divided by 2 roughly), that there is always a point in number of triangles where raytracing gets faster than rasterisation, whatever fancy LOD of occlusion technics you use there... Rasterisation fanboys always argue about LOD and occlusion technics but they give flickering artifacts and object popping at the limits. It is possible to also use LOD in raytracing, it's just that its not needed. And you get no popping artifacts or nasty things when using raytracing.. As long as all the data fits in system memory... But the good point is that you have more system memory than GPU memory usually.
It seems to me anyway that most of what j.carmack discusses about is not relevant for demos, because he assumes an army of artists "painting/sculpting" over huge assets.
Nowadays je's pretty much at the whole other end of the spectrum it seems.
Nowadays je's pretty much at the whole other end of the spectrum it seems.
Unless there's a way to piggy back content using image-based/video-based techniques
knos, and this way is PIGEONS!
ok only iq will understand that one :D
or rather, i'd say in the future using procedural methods to generate content will become more and more critical to speed up artists work...
or rather, i'd say in the future using procedural methods to generate content will become more and more critical to speed up artists work...
Quote:
he assumes an army of artists "painting/sculpting" over huge assets
but everybody knows than an army of artists working on a massive assets can be replaced by a perlin noise :) :) :) :)
but what about raytracing a perlin noise isosurface directly then instead of storing it as a point clouds ;)
here's Carmack's vision :):
http://www.jonof.id.au/forum/index.php?topic=1411.0
http://www.jonof.id.au/forum/index.php?topic=1411.0
I would like to see something decent done with that voxlap
another vision of what the future reserves ? (the last paragraph about pure software vs hardware acceleration)
Quote:
PCs will ship with a usable level of graphics functionality without having any sort of graphics hardware in the system. Your graphics hardware will be a VGA and a HDMI-out connector and that's about it. The same thing happened with sound. All the time, you had these high-end, ultra-expensive sound cards and different levels of sound acceleration.
Sweet embeded systems.
Quote:
but what about raytracing a perlin noise isosurface directly then instead of storing it as a point clouds ;)
that's called hypertextures. The 2.5D version is the famous DDA (what MojoWorlds uses for example). But that's without kdtree. Hm....
nystep,
I think the article title is bogus and misleading. Its not switching to raytracing its switching to voxels. Obviously he is only raycasting/marching (he doesnt worry about reflections or shadows). So he believes the voxel data structure is better for this scenario than kd-tree. Why? I think its what hes not saying thats important. Its not *current* scenes (surfaces) that he is targetting. My guess is he is wanting to "paint between the surfaces" using heavy atmospheric effects. Smoke, water, fire, plasma from guns, god rays etc. Under this scenario kd-trees really dont offer much but native voxel rendering does.
Probably he is considering how easy it will be to use a write to texture mechanism for updating such "smoke in a box" tricks. Maybe even on the geometry shader. Whereas with a kd-tree...well, the mind boggles.
Maybe he talks about sparse because hes intending to pass in not only normal voxels but empty voxels which may be written to by the rendering engine for dynamic effects (the box in the smoke in the box case).
He mentions that the technique would be a natural extension on his texturing engine so I guess he wants to use 3d textures (4d, 5d?), paging in blocks of voxel geometry as he goes through a world ... how would kd-trees cope with that dynamic movement? The scene isnt static when you move through it as new areas become visible, but in JCs thinking its easy to page in more geometry. He can have a simple and highly optimiised scheme for this. Paging in more texture is just a very simple way to do this.
So under these circumstances I see where he might go with voxels. What I dont understand is why he isn't voxel-splatting as iq suggests. Why trace the structure? He must think there will be an enormous depth complexity and splatting will be too slow, unless there is something much deeper I dont get yet.
In the end I think the fact that he choses voxels over kd-trees isnt a question of why he think voxels are better for doing surfaces but what else he intends to do with them that he isnt saying in an open forum...
I think the article title is bogus and misleading. Its not switching to raytracing its switching to voxels. Obviously he is only raycasting/marching (he doesnt worry about reflections or shadows). So he believes the voxel data structure is better for this scenario than kd-tree. Why? I think its what hes not saying thats important. Its not *current* scenes (surfaces) that he is targetting. My guess is he is wanting to "paint between the surfaces" using heavy atmospheric effects. Smoke, water, fire, plasma from guns, god rays etc. Under this scenario kd-trees really dont offer much but native voxel rendering does.
Probably he is considering how easy it will be to use a write to texture mechanism for updating such "smoke in a box" tricks. Maybe even on the geometry shader. Whereas with a kd-tree...well, the mind boggles.
Maybe he talks about sparse because hes intending to pass in not only normal voxels but empty voxels which may be written to by the rendering engine for dynamic effects (the box in the smoke in the box case).
He mentions that the technique would be a natural extension on his texturing engine so I guess he wants to use 3d textures (4d, 5d?), paging in blocks of voxel geometry as he goes through a world ... how would kd-trees cope with that dynamic movement? The scene isnt static when you move through it as new areas become visible, but in JCs thinking its easy to page in more geometry. He can have a simple and highly optimiised scheme for this. Paging in more texture is just a very simple way to do this.
So under these circumstances I see where he might go with voxels. What I dont understand is why he isn't voxel-splatting as iq suggests. Why trace the structure? He must think there will be an enormous depth complexity and splatting will be too slow, unless there is something much deeper I dont get yet.
In the end I think the fact that he choses voxels over kd-trees isnt a question of why he think voxels are better for doing surfaces but what else he intends to do with them that he isnt saying in an open forum...
