[QUOTE=Lux_] [QUOTE=hoho] In short I wouldn't say it is fools errand. It will surely take years* for ray tracing to become a viable alternative for game developers *) my guess 1.5-3 years for first good looking tech-demos, 4-6 for some serious games sold for gamers. [\QUOTE] First, thank you for the excellent post! It's the quoted part I'm not excatly agreed with. 1) it takes about 4 years to build a game USING foundation of existing production workflows and supporting toolset. To introduce something significantly different would introduce delays: the larger the change, the more there are bugs and more need to relearn/train. Watch Vista for example ;). Nobody wants their product to be delayed for 1,5 years. 2) The harware for "very good looking" rasterization games is not exactly here yet, as can be seen in latest batch of DX10 benchmarks. Raytracing provides better quality, not better speed - and the consumer space is not in position to choose better quality at the expense of double-digit drop in framerate just yet. 3) There are "known" ways to significantly speed up rasterization-based rendering: I remember one paper from this year's SigGraph, where the author accumulated shader results across frames (can't find the link right now). For example when running character was shaded, there were big speedups, because large parts remained unchanged across the frames. I don't know how easy it is to introduce this technique using current frameworks, but I imagine it is orders of magnitudes easier than similar techniques for raytracing. Maybe I'm mistaken. [\QUOTE] [QUOTE=crystall] [QUOTE=hoho] I bet most people already have heard about Intel demo of ray traced Quake4 (http://www.q4rt.de/). It was first shown at December last year running on QX6700 at 256x256 and achieving around 17FPS. This year they made "little" changes to their algorithm (replaced OpenRT with their internal tracer, probably MLRTA based one) and showed it on 2P quadcore Penryn at 1024x1024 running at around 90FPS. For low-quality video see news -> 28th September 2007 on their page. [\QUOTE] Reading between the lines it seems to me that they're talking about navigating a level, that's a completely static scene on which you can spend as much time as you want to build an optimal tree. The day you could really handle a ray-traced Quake IV-like game at a decent resolution, with decent AA & AF levels on a general purpose CPUs the GPUs will be probably doing much, much more than that. [\QUOTE] [QUOTE=Gubbi] Ultimately secondary rays is the entire reason ray tracing exists as a concept. That basically makes ray tracing an excercise in pointer-chasing (heck, there even was a raytracer in the *integer* spec2000 suite for exactly this reason). That means performance is ultimately limited by latency. Rasterizers exploit the great locality rasterization implies (pixels in screen space, textures etc). That makes it more limited by bandwidth than latency. That ultimately favours rasterizers as bandwidth is a lot easier to improve than latency. The difference between raytracers and rasterizers has gone up for the past many years and I see no reason for that to change. Given the same amount of silicon real estate I can't see raytracers displacing rasterizers. Cheers [\QUOTE] [QUOTE=Simon F] Regarding AA and Raytracing... [QUOTE=article] There are two solutions used in the off-line world: cone/beam tracing or distributed ray tracing. The first is simply too expensive, as the cost of an intersection test with cones or beams is extremely high. [\QUOTE] Many, many moons ago, I wrote a Amantides (http://portal.acm.org/citation.cfm?id=808589&dl=ACM&coll=GUIDE&CFID=38755532&CFTOKEN=27284278)-style "Cone Ray Tracer", but I don't recall that the the intersection test with objects was that much more expensive. I certainly think it was much cheaper than the equivalent number of stochastic rays. [\QUOTE] [QUOTE=nAo] Thanks for you article Dean, it doesn't happen every day to read a such a well written piece about such a complex matter. [QUOTE=hoho] The main difference between ray tracing and rasterizing is how well they scale: 1) Rasterizing scales linearly with number of triangles and logarithmically with number of pixels. 2) Ray tracing scales linearly with number of pixels and logarithmically with number of triangles. [\QUOTE] wrong, in both cases. 1) rasterization scales linearly with regards to pixel count and triangle count. 2) ray tracing scales linearly with regards to pixel count and triangle count. What can make both algorithms scale logarithmically are spatial subdivsion structures, there's nothing inherently logarithmic in ray tracing (or rasterization for all that matter) [\QUOTE] [QUOTE=Dee.cz] [QUOTE] Instead, solving the indirect lighting problem is the real holy grail of real-time rendering. Of course, at this point, no one even has a serious framework to do so that doesn't require massive amounts of precomputed data [\QUOTE] Check this list of GI demos (http://realtimeradiosity.com/demos), at least Lightsprint and AMD things seem to seriously work without precalculations. Btw, I'll very seriously move state of the art in a few weeks, wait for new demo... [\QUOTE] [QUOTE=Mintmaster] [QUOTE=hoho] The main difference between ray tracing and rasterizing is how well they scale: 1) Rasterizing scales linearly with number of triangles and logarithmically with number of pixels. 2) Ray tracing scales linearly with number of pixels and logarithmically with number of triangles. [\QUOTE] What? Both scale linearly wrt pixel count, and why are you ignoring LOD in rasterization? That makes it logarithmic wrt triangles for both. Even more pertinent is that we don't need more than a few billion polys per second before reaching eye resolution limits in realtime applications. That throughput will be a piece of cake in a few years, using rather little silicon. [QUOTE] Another difference is that rasterizing starts with some very basic approximations and adds all sorts of tricks to make it look like real-life. Ray tracing takes a physically-correct model and to make it fast you can start adding all kinds of tricks to make it faster (dropping global illumination helps a lot). [\QUOTE] That's BS. What's so much more physically correct about raytracing? Any local lighting model you use in RT can by used in rasterization. The only thing slightly more realistic about raytracing is point-light shadowing, but not only do stencil shadows give you precisely the same result, but cascaded shadow maps are are almost equivalent to ray tracing in terms of ray density/efficiency. Shadow comparisons out there are so stupid. Run the raytracer at a quarter resolution and a quarter the FPS while gimping the rasterizer with a low res shadow map. Yeah, that's fair. :roll: [QUOTE] I'd say this is half-solved problem. Building a bounding interval hierarchy over tens of thousands of triangles takes a few milliseconds on newer CPU core and it is possible to parallelize it. Also it is possible to build it lazily. [\QUOTE] Sure, a few milliseconds for whatever scene you're talking about. The scaling, however, is not logarithmic anymore, which is the primary justification for going to ray-tracing in the first place. And even that is flawed, as I mentioned above. [QUOTE] Only problem with ray tracing is instancing. If you have ten enemies running towards you with each and every one being rendered at different animation frame you will have to have ten copies of those meshes in memory. [\QUOTE] That's a huge problem! One of the primary advantages of rasterization is the streaming nature from start to finish without storage (aside from textures). RAM is pretty much the only thing stopping us from a fully destructable, physically real world. The CPU power and software is more than enough now. [QUOTE] Global Illumination It is much more expensive than direct ray tracing but doable. It will just need about an order of magnitude more performance. Until we don't have so powerful HW we can use all the tricks being used with rasterizing. [\QUOTE] IMO this is the only justification for ray-tracing. Until we have so powerful HW there's no use for it in realtime rendering. [QUOTE] A completely dynamic scene would kill a rasterizer also as it takes lots of time to update the geometry and send it to GPU, it won't be much worse with ray tracing allthough BVH building will surely add to it a bit. [\QUOTE] What? A fully dynamic scene is a piece of cake to do on a rasterizer. You just update a few matrices on the CPU and do bounding volume frustum tests, and everything else is identical. [QUOTE] Tracing primary rays is rather cheap actually. If we already have good enough HW for tracing secondary rays then tracing primaries won't be much slower than rasterizing them. [\QUOTE] The point Deano is making is that realtime raytracing consisting mostly of primary rays is useless. Reflection/refraction/shadowing in rasterization (i.e. single secondary ray per pixel effects) are pretty much solved to satisfaction for realtime applications. Only when you have lots of secondary rays (e.g. for GI) does raytracing make sense. 10-100 million secondary rays per frame is many, many years away from realtime. Only if rasterization has failed to come up with an acceptable GI approximation by then will realtime raytracing be useful, because we won't have anything else useful to do with the rasterization hardware then. [\QUOTE] [QUOTE=Geo] [QUOTE=Mintmaster] That's a huge problem! One of the primary advantages of rasterization is the streaming nature from start to finish without storage (aside from textures). RAM is pretty much the only thing stopping us from a fully destructable, physically real world. The CPU power and software is more than enough now. [\QUOTE] How much RAM are you wanting for that?:smile: [\QUOTE] [QUOTE=MfA] [QUOTE=Mintmaster] That's BS. What's so much more physically correct about raytracing? Any local lighting model you use in RT can by used in rasterization. [\QUOTE] Refraction and reflection can't be done precisely and while it is in theory possible to do shadows to the same precision as raytracing with a shadow buffer ... although strictly speaking it would not be rasterization since none of the sample points in the shadow buffer would be on a raster, a more precise term is object order rendering. Regardless, no one is doing shadows like that. [\QUOTE] [QUOTE=Mintmaster] Nah, I think I'll stay on the copout path. :wink: I'll say this: If you can halve RAM cost by doubling computation cost, do it. Often it's worth it to go well beyond that. From this point of view, it makes little sense to raytrace for any realtime scene without GI, as rasterization is unlikely to have much higher computational cost (it's usually much lower) and raytracing will take much more memory. [\QUOTE] [QUOTE=Xmas] [QUOTE=Mintmaster] Reflection/refraction/shadowing in rasterization (i.e. single secondary ray per pixel effects) are pretty much solved to satisfaction for realtime applications. [\QUOTE] I'm not sure I agree with that sentiment. [\QUOTE] [QUOTE=CaseMillennium] Mmhh, sorry but the article is pretty bad and doesnt really show much knowledge of the topic. 1. Aliasing: Yes, aliasing is a problem, as is with rasterization. However, there are two different sources of antialiasing: geometric aliasing and texture aliasing. Texture aliasing is easy to solve with mipmaps and good shader programming. This is more or less independent of the raytracing/rasterization issue - although it is a littlebit more difficult with raytracing since you need ray differentials that propagate over reflections/refractions. Geometric aliasing is the hard one and needs to be solved with additional rays in raytracing. However, adaptiv supersampling and filtering can be applied so you dont need as many rays as one might think at first. A simple way would be to keep track on neighbouring fragments and if the color difference is above a threshold shoot additional rays. If one does proper texture antialiasing the numner of additional rays wont be very large for normal scenes and therefore the speed impact is not too bad. 2. Static or moving scenes: Ok, this is indeed a problem but lets face it: Framerates above 30 fps dont make sense, the human eye is to slow to recognize it. So if you are doing a complete rebuild of a acceleration structure for raytracing, you would need to do this about 30 times per second. The best algorithms I know at the moment can do a rebuild for about 1 million triangles per second per core. Using multithreading and at least an 8 Core machine (you will need this), you can completely rebuild a 250k triangle scene 30 times a second. 3. Global illumination: You need raytracing to build a photon map, you need raytracing for collision detection, you need raytracing for true glossy reflections. Shure, you need to shoot more rays, but hardware gets faster and cheaper. So the point about raytracing is: With raytracing you CAN solve all problems from true global illumination, glossy reflections, soft shadows, reflections, refractions WITHOUT needing to fake it. Of course, you will need lots of cpu power for this, but at least it is possible. With rasterization on the other side, many of those problems cant be solved, they can just be faked. Correct reflections are nearly impossible (especially on curved objects), refractions are impossible to solve. Global illumination can only be baked or approximated, even ambient occlusion cant be calculated correctly with rasterization. Baking results in textures is just another fake and is pretty wrong: You are stuck with completely static lighting and changing the lighting will simply make your baked textures wrong. Also, texture resolution is limited, making hard features impossible to capture. Rasterization has another problem that gets more and more important as shaders get more and more complex: It suffers from massive overdraw. When a classic rasterizer gets a triangle it just calculates the fragments it covers on screen, calculates the shading for each fragment and writes the result to the framebuffer if it passes the z-test. However, the next triangle may be directly in front of the first triangle so the same pixels are again shaded and written to the framebuffer. Early z-Test doesnt help in this situation since it still depends on the order the triangles are passed to the rasterizer (early z just avoids shading a fragment if there already is a value in the z-buffer that is closer to the viewer). Some ways to improve the situation exist (http://www.3dinteractive.de/) but these again use raytracing... Some other algorithms just try to prevent overdraw within one mesh, multiple meshes are not considered. With raytracing on the other hand, each pixel is shaded exactly once causing zero overdraw. Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears. A GPU is highly optimized for a very specific purpose, with (on a Geforce 8800 GTX) 128!! processors running in parallel (with blocks of, I think 8, processors linked together). Current CPUs have maximum of 4 Cores and are designed to do about everything. So current CPU raytracers need to do everything, including raysetup, tracing the rays and shading. And even a simple trilinear texture lookup isnt that simple anymore when you start to write it yourself. So if you want a true comparison about raytracing and rasterization, just write a software rasterizer and a software raytracer and compare those. Or just use something like nvemulate and turn on software rasterization. So what we just need is a specialized raytracing chip (larrabee?) that does all the things current GPUs do and just uses another way to produce the fragments. And we should also not forget that all!!! tricks that are used in rasterization can be done with raytracing as well. So I currently have a raytracer that uses brebaked ambient occlusion and filtered cubemaps for glossy reflections and just adds specular reflections, shadows and refractions on top of this. [\QUOTE] [QUOTE=JHoxley] Interesting article. I like the simple reference to raster vs ray-traced graphics coming from the early days of computer graphics. Context is very important here. The good old OpenGL vs Direct3D argument stemmed from comparisons that have since lost relevance and context, which seems a little similar to whats happening here... [\QUOTE] [QUOTE=CaseMillennium] Mmhh, sorry but the article is pretty bad and doesnt really show much knowledge of the topic. 1. Aliasing: Yes, aliasing is a problem, as is with rasterization. However, there are two different sources of antialiasing: geometric aliasing and texture aliasing. Texture aliasing is easy to solve with mipmaps and good shader programming. This is more or less independent of the raytracing/rasterization issue - although it is a littlebit more difficult with raytracing since you need ray differentials that propagate over reflections/refractions. Geometric aliasing is the hard one and needs to be solved with additional rays in raytracing. However, adaptiv supersampling and filtering can be applied so you dont need as many rays as one might think at first. A simple way would be to keep track on neighbouring fragments and if the color difference is above a threshold shoot additional rays. If one does proper texture antialiasing the numner of additional rays wont be very large for normal scenes and therefore the speed impact is not too bad. 2. Static or moving scenes: Ok, this is indeed a problem but lets face it: Framerates above 30 fps dont make sense, the human eye is to slow to recognize it. So if you are doing a complete rebuild of a acceleration structure for raytracing, you would need to do this about 30 times per second. The best algorithms I know at the moment can do a rebuild for about 1 million triangles per second per core. Using multithreading and at least an 8 Core machine (you will need this), you can completely rebuild a 250k triangle scene 30 times a second. 3. Global illumination: You need raytracing to build a photon map, you need raytracing for collision detection, you need raytracing for true glossy reflections. Shure, you need to shoot more rays, but hardware gets faster and cheaper. So the point about raytracing is: With raytracing you CAN solve all problems from true global illumination, glossy reflections, soft shadows, reflections, refractions WITHOUT needing to fake it. Of course, you will need lots of cpu power for this, but at least it is possible. With rasterization on the other side, many of those problems cant be solved, they can just be faked. Correct reflections are nearly impossible (especially on curved objects), refractions are impossible to solve. Global illumination can only be baked or approximated, even ambient occlusion cant be calculated correctly with rasterization. Baking results in textures is just another fake and is pretty wrong: You are stuck with completely static lighting and changing the lighting will simply make your baked textures wrong. Also, texture resolution is limited, making hard features impossible to capture. Rasterization has another problem that gets more and more important as shaders get more and more complex: It suffers from massive overdraw. When a classic rasterizer gets a triangle it just calculates the fragments it covers on screen, calculates the shading for each fragment and writes the result to the framebuffer if it passes the z-test. However, the next triangle may be directly in front of the first triangle so the same pixels are again shaded and written to the framebuffer. Early z-Test doesnt help in this situation since it still depends on the order the triangles are passed to the rasterizer (early z just avoids shading a fragment if there already is a value in the z-buffer that is closer to the viewer). Some ways to improve the situation exist (http://www.3dinteractive.de/) but these again use raytracing... Some other algorithms just try to prevent overdraw within one mesh, multiple meshes are not considered. With raytracing on the other hand, each pixel is shaded exactly once causing zero overdraw. Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears. A GPU is highly optimized for a very specific purpose, with (on a Geforce 8800 GTX) 128!! processors running in parallel (with blocks of, I think 8, processors linked together). Current CPUs have maximum of 4 Cores and are designed to do about everything. So current CPU raytracers need to do everything, including raysetup, tracing the rays and shading. And even a simple trilinear texture lookup isnt that simple anymore when you start to write it yourself. So if you want a true comparison about raytracing and rasterization, just write a software rasterizer and a software raytracer and compare those. Or just use something like nvemulate and turn on software rasterization. So what we just need is a specialized raytracing chip (larrabee?) that does all the things current GPUs do and just uses another way to produce the fragments. And we should also not forget that all!!! tricks that are used in rasterization can be done with raytracing as well. So I currently have a raytracer that uses brebaked ambient occlusion and filtered cubemaps for glossy reflections and just adds specular reflections, shadows and refractions on top of this. [\QUOTE] [QUOTE=CaseMillennium] Mmhh, sorry but the article is pretty bad and doesnt really show much knowledge of the topic. 1. Aliasing: Yes, aliasing is a problem, as is with rasterization. However, there are two different sources of antialiasing: geometric aliasing and texture aliasing. Texture aliasing is easy to solve with mipmaps and good shader programming. This is more or less independent of the raytracing/rasterization issue - although it is a littlebit more difficult with raytracing since you need ray differentials that propagate over reflections/refractions. Geometric aliasing is the hard one and needs to be solved with additional rays in raytracing. However, adaptiv supersampling and filtering can be applied so you dont need as many rays as one might think at first. A simple way would be to keep track on neighbouring fragments and if the color difference is above a threshold shoot additional rays. If one does proper texture antialiasing the numner of additional rays wont be very large for normal scenes and therefore the speed impact is not too bad. 2. Static or moving scenes: Ok, this is indeed a problem but lets face it: Framerates above 30 fps dont make sense, the human eye is to slow to recognize it. So if you are doing a complete rebuild of a acceleration structure for raytracing, you would need to do this about 30 times per second. The best algorithms I know at the moment can do a rebuild for about 1 million triangles per second per core. Using multithreading and at least an 8 Core machine (you will need this), you can completely rebuild a 250k triangle scene 30 times a second. 3. Global illumination: You need raytracing to build a photon map, you need raytracing for collision detection, you need raytracing for true glossy reflections. Shure, you need to shoot more rays, but hardware gets faster and cheaper. So the point about raytracing is: With raytracing you CAN solve all problems from true global illumination, glossy reflections, soft shadows, reflections, refractions WITHOUT needing to fake it. Of course, you will need lots of cpu power for this, but at least it is possible. With rasterization on the other side, many of those problems cant be solved, they can just be faked. Correct reflections are nearly impossible (especially on curved objects), refractions are impossible to solve. Global illumination can only be baked or approximated, even ambient occlusion cant be calculated correctly with rasterization. Baking results in textures is just another fake and is pretty wrong: You are stuck with completely static lighting and changing the lighting will simply make your baked textures wrong. Also, texture resolution is limited, making hard features impossible to capture. Rasterization has another problem that gets more and more important as shaders get more and more complex: It suffers from massive overdraw. When a classic rasterizer gets a triangle it just calculates the fragments it covers on screen, calculates the shading for each fragment and writes the result to the framebuffer if it passes the z-test. However, the next triangle may be directly in front of the first triangle so the same pixels are again shaded and written to the framebuffer. Early z-Test doesnt help in this situation since it still depends on the order the triangles are passed to the rasterizer (early z just avoids shading a fragment if there already is a value in the z-buffer that is closer to the viewer). Some ways to improve the situation exist (http://www.3dinteractive.de/) but these again use raytracing... Some other algorithms just try to prevent overdraw within one mesh, multiple meshes are not considered. With raytracing on the other hand, each pixel is shaded exactly once causing zero overdraw. Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears. A GPU is highly optimized for a very specific purpose, with (on a Geforce 8800 GTX) 128!! processors running in parallel (with blocks of, I think 8, processors linked together). Current CPUs have maximum of 4 Cores and are designed to do about everything. So current CPU raytracers need to do everything, including raysetup, tracing the rays and shading. And even a simple trilinear texture lookup isnt that simple anymore when you start to write it yourself. So if you want a true comparison about raytracing and rasterization, just write a software rasterizer and a software raytracer and compare those. Or just use something like nvemulate and turn on software rasterization. So what we just need is a specialized raytracing chip (larrabee?) that does all the things current GPUs do and just uses another way to produce the fragments. And we should also not forget that all!!! tricks that are used in rasterization can be done with raytracing as well. So I currently have a raytracer that uses brebaked ambient occlusion and filtered cubemaps for glossy reflections and just adds specular reflections, shadows and refractions on top of this. [\QUOTE] [QUOTE=CaseMillennium] Sorry if this gets posted more than once but the last 2 posts just didnt show up... Mmhh, sorry but the article is pretty bad and doesnt really show much knowledge of the topic. 1. Aliasing: Yes, aliasing is a problem, as is with rasterization. However, there are two different sources of antialiasing: geometric aliasing and texture aliasing. Texture aliasing is easy to solve with mipmaps and good shader programming. This is more or less independent of the raytracing/rasterization issue - although it is a littlebit more difficult with raytracing since you need ray differentials that propagate over reflections/refractions. Geometric aliasing is the hard one and needs to be solved with additional rays in raytracing. However, adaptiv supersampling and filtering can be applied so you dont need as many rays as one might think at first. A simple way would be to keep track on neighbouring fragments and if the color difference is above a threshold shoot additional rays. If one does proper texture antialiasing the numner of additional rays wont be very large for normal scenes and therefore the speed impact is not too bad. 2. Static or moving scenes: Ok, this is indeed a problem but lets face it: Framerates above 30 fps dont make sense, the human eye is to slow to recognize it. So if you are doing a complete rebuild of a acceleration structure for raytracing, you would need to do this about 30 times per second. The best algorithms I know at the moment can do a rebuild for about 1 million triangles per second per core. Using multithreading and at least an 8 Core machine (you will need this), you can completely rebuild a 250k triangle scene 30 times a second. 3. Global illumination: You need raytracing to build a photon map, you need raytracing for collision detection, you need raytracing for true glossy reflections. Shure, you need to shoot more rays, but hardware gets faster and cheaper. So the point about raytracing is: With raytracing you CAN solve all problems from true global illumination, glossy reflections, soft shadows, reflections, refractions WITHOUT needing to fake it. Of course, you will need lots of cpu power for this, but at least it is possible. With rasterization on the other side, many of those problems cant be solved, they can just be faked. Correct reflections are nearly impossible (especially on curved objects), refractions are impossible to solve. Global illumination can only be baked or approximated, even ambient occlusion cant be calculated correctly with rasterization. Baking results in textures is just another fake and is pretty wrong: You are stuck with completely static lighting and changing the lighting will simply make your baked textures wrong. Also, texture resolution is limited, making hard features impossible to capture. Rasterization has another problem that gets more and more important as shaders get more and more complex: It suffers from massive overdraw. When a classic rasterizer gets a triangle it just calculates the fragments it covers on screen, calculates the shading for each fragment and writes the result to the framebuffer if it passes the z-test. However, the next triangle may be directly in front of the first triangle so the same pixels are again shaded and written to the framebuffer. Early z-Test doesnt help in this situation since it still depends on the order the triangles are passed to the rasterizer (early z just avoids shading a fragment if there already is a value in the z-buffer that is closer to the viewer). Some ways to improve the situation exist (http://www.3dinteractive.de/) but these again use raytracing... Some other algorithms just try to prevent overdraw within one mesh, multiple meshes are not considered. With raytracing on the other hand, each pixel is shaded exactly once causing zero overdraw. Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears. A GPU is highly optimized for a very specific purpose, with (on a Geforce 8800 GTX) 128!! processors running in parallel (with blocks of, I think 8, processors linked together). Current CPUs have maximum of 4 Cores and are designed to do about everything. So current CPU raytracers need to do everything, including raysetup, tracing the rays and shading. And even a simple trilinear texture lookup isnt that simple anymore when you start to write it yourself. So if you want a true comparison about raytracing and rasterization, just write a software rasterizer and a software raytracer and compare those. Or just use something like nvemulate and turn on software rasterization. So what we just need is a specialized raytracing chip (larrabee?) that does all the things current GPUs do and just uses another way to produce the fragments. And we should also not forget that all!!! tricks that are used in rasterization can be done with raytracing as well. So I currently have a raytracer that uses brebaked ambient occlusion and filtered cubemaps for glossy reflections and just adds specular reflections, shadows and refractions on top of this. [\QUOTE] [QUOTE=Arun] [QUOTE=CaseMillennium] Mmhh, sorry but the article is pretty bad and doesnt really show much knowledge of the topic. [\QUOTE] I beg to differ, see below. [QUOTE] 1. Aliasing: Yes, aliasing is a problem, as is with rasterization. However, there are two different sources of antialiasing: geometric aliasing and texture aliasing. [\QUOTE] I certainly hope you don't think Deano doesn't realize that... [QUOTE] Texture aliasing is easy to solve with mipmaps and good shader programming. This is more or less independent of the raytracing/rasterization issue - although it is a littlebit more difficult with raytracing since you need ray differentials that propagate over reflections/refractions. [\QUOTE] Correct. You also can't compute derivatives based on quads as in rasterization, AFAICT - although with very small triangles, that's besides the point. [QUOTE] Geometric aliasing is the hard one and needs to be solved with additional rays in raytracing. However, adaptiv supersampling and filtering can be applied so you dont need as many rays as one might think at first. A simple way would be to keep track on neighbouring fragments and if the color difference is above a threshold shoot additional rays. If one does proper texture antialiasing the numner of additional rays wont be very large for normal scenes and therefore the speed impact is not too bad. [\QUOTE] Sure, nothing is 'too bad'. But it still reduces performance significantly, making you 'lose' at least one cycle of Moore's Law. That is NOT negligible. [QUOTE] 2. Static or moving scenes: Ok, this is indeed a problem but lets face it: Framerates above 30 fps dont make sense, the human eye is to slow to recognize it. [\QUOTE] Let's face it: you don't know anything about on this point. If we had perfect motion blur (y'know, like in movies?) and games weren't interactive, I would agree with you. But we don't have that, and games ARE interactive, thus latency matters. Think about it this way: your brain's vision system is massively parallel and it is NOT synchronized with your monitor's refresh rate. This means that lower response times are definitely an advantage, no matter what, for interactive applications. You could argue that doesn't matter much outside of FPS games, but hey, that's a big part of the market last I heard... [QUOTE] So if you are doing a complete rebuild of a acceleration structure for raytracing, you would need to do this about 30 times per second. The best algorithms I know at the moment can do a rebuild for about 1 million triangles per second per core. Using multithreading and at least an 8 Core machine (you will need this), you can completely rebuild a 250k triangle scene 30 times a second. [\QUOTE] Thank you for proving the opposite point of what you meant to prove. Current PS3/XBox360 games very easily go above 1M triangles/frame, and in some cases I'm sure many of them are dynamic. So much for raytracing having an advantage with high polygon counts! [quote]3. Global illumination: You need raytracing to build a photon map, you need raytracing for collision detection, you need raytracing for true glossy reflections. Shure, you need to shoot more rays, but hardware gets faster and cheaper.[quote]I suggest you read other comments before responding, as this nicely summarizes the problem with your reasoning: [QUOTE=Mintmaster] Only when you have lots of secondary rays (e.g. for GI) does raytracing make sense. 10-100 million secondary rays per frame is many, many years away from realtime. Only if rasterization has failed to come up with an acceptable GI approximation by then will realtime raytracing be useful, because we won't have anything else useful to do with the rasterization hardware then. [\QUOTE] ... [QUOTE] So the point about raytracing is: With raytracing you CAN solve all problems from true global illumination, glossy reflections, soft shadows, reflections, refractions WITHOUT needing to fake it. Of course, you will need lots of cpu power for this, but at least it is possible. [\QUOTE] Sure, raytracing is more flexible, but that's not the point. The point really is that for a given number of computation requirements, rasterization will practically always look (perhaps very significantly) better than raytracing. [QUOTE] With rasterization on the other side, many of those problems cant be solved, they can just be faked. Correct reflections are nearly impossible (especially on curved objects), refractions are impossible to solve. Global illumination can only be baked or approximated, even ambient occlusion cant be calculated correctly with rasterization. [\QUOTE] I agree, but the human eye is really not that good at figuring out whether reflection and refraction are physically correct, as long as it looks 'subtle enough'. Think of it this way: there was no advantage for mammals and primates in the last 200M years to be able to get very accurate data from reflections and especially refractions. If you think you can tell the difference most of the time, then my guess is you're probably either mistaken or simply bluffing. [QUOTE] Baking results in textures is just another fake and is pretty wrong: You are stuck with completely static lighting and changing the lighting will simply make your baked textures wrong. Also, texture resolution is limited, making hard features impossible to capture. [\QUOTE] Baking textures is outdated, I'm not sure where you have been in the last five years, but okay :p See, that's also the problem: many proponents of raytracing are simply using outdated information about rasterization-related techniques. Deano was the Lead Programmer for Heavenly Sword - I'm not sure why I should believe you are more up-to-date on these things than he is. [QUOTE] Rasterization has another problem that gets more and more important as shaders get more and more complex: It suffers from massive overdraw [...] Early z-Test doesnt help in this situation since it still depends on the order the triangles are passed to the rasterizer (early z just avoids shading a fragment if there already is a value in the z-buffer that is closer to the viewer). [\QUOTE] You clearly have no clue what you are talking about here. I suggest you look into Z passes, as they solve that problem perfectly. Alternatively, you may wish to look into TBDRs (which also solve blending much better than peeling or even raytracing IMO, but that's a hardware fix, not a software one). [QUOTE] Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears. [\QUOTE] Correct, but that doesn't mean an apple-to-apple comparison would be sufficiently better. I have very good reasons to think so, including ones related to Larrabee, but this is not the right thread for this, I fear. And even if you were right on this, it still wouldn't solve my above concerns. [\QUOTE] [QUOTE=AndyTX] Arun and nAo have already responded to pretty much everything, but I'll add a point or two: [QUOTE=CaseMillennium] So the point about raytracing is: With raytracing you CAN solve all problems from true global illumination, glossy reflections, soft shadows, reflections, refractions WITHOUT needing to fake it. Of course, you will need lots of cpu power for this, but at least it is possible. [\QUOTE] First, no one is disagreeing that raytracing is more flexible, but as has been explained several times using that logic to throw out the rasterizer is just plain stupid... the two can work together just fine, so why not just use the most efficient algorithms/data structures where they are appropriate? Secondly I would definitely like to reiterate that "faking it" is the basis of pretty much all graphics right now, real-time or otherwise. This isn't because we don't know how to do it properly, it's because faking it sometimes looks *better* than reality to be honest, and in other cases looks good enough for a fraction of the cost. To cite some specific examples, refraction generally just has to warp a bit and people accept it... do you remember the paper from SIGGRAPH a few years ago that literally used image-based "copy-paste, mirror, warp" type techniques to do refractions and it looked pretty much fine? With the latest two-sided refraction techniques that have come out recently you'd be hard-pressed to notice the differences. Now I admit that *local* reflections and refractions are hard to capture properly, but they really don't end up mattering in a large number of cases (excepting perhaps, automobile visualization, etc). That said, when they do matter, you can certainly raytrace *only those secondary rays*. And regarding AO, that can be done perfectly and efficiently with rasterization and shadow maps (see GPU Gems 2). Why do you say you need raytracing for it? If you look at the rays that you're shooting they're just shadow rays... On the GI front, I've seen as much promise in rasterization techniques as raytracing TBH. Deferred instant radiosity - for example - works pretty well on modern cards and is *much* faster than photon mapping. [QUOTE=CaseMillennium] Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears. [\QUOTE] Raytracing has been done on every bit of hardware under the sun including GPUs, CPUs and Cell most recently. Cell is pretty much ideal hardware for computing ray intersections (I doubt custom hardware would do much better) and even though it can produce respectable and usable numbers don't get any misconceptions: it still gets crushed by a decent rasterizer for coherent rays (the only place the two can be compared). [\QUOTE] [QUOTE=Arun] [QUOTE=AndyTX] Cell is pretty much ideal hardware for computing ray intersections (I doubt custom hardware would do much better) [\QUOTE] I don't think I agree with that! ;) See: http://forum.beyond3d.com/showpost.php?p=1011003&postcount=45 Also, the full paper I was thinking of in that post is available here, including the RPU's chip layout (Figure 7): http://graphics.cs.uni-sb.de/Publications/2006/drpuasic_rt06_final.pdf [\QUOTE] [QUOTE=CaseMillennium] [QUOTE=Arun] You also can't compute derivatives based on quads as in rasterization, [\QUOTE] And why would that be? Of course you can. It just isnt ideal because the quality sucks and it doesnt work with reflections anyways. For raytracing you use ray differentials and propagate them. Works perfectly :) [QUOTE] Thank you for proving the opposite point of what you meant to prove. Current PS3/XBox360 games very easily go above 1M triangles/frame, and in some cases I'm sure many of them are dynamic. So much for raytracing having an advantage with high polygon counts! [\QUOTE] Ok, first of all: I didnt say current systems are there yet. But lets simple guess the larrabee processor will be what it is supposed to be: A massive parallel processor with 80 Cores with the performance necessary. Then we are at 2.5 Million completely dynamic triangles per seconds - and this is beyond what current Geforce8 Hardware can do. The current games are not completely dynamic, they use structured dynamics and static models for most of their scenes. Try putting 2.5 completely indepentently transformed triangles on you current hardware - performance will be terrible. As for raytracing: You wont rebuild the complete scene anyway. Use BVH on a scene level and KDTree/BIH on object level und just rebuild the BVH hierarchy and those objects that changed. Performance is not much lower with this approach and building a 10000 object BVH is a piece of cake. [QUOTE] Sure, raytracing is more flexible, but that's not the point. The point really is that for a given number of computation requirements, rasterization will practically always look (perhaps very significantly) better than raytracing. [\QUOTE] No it wont. Lets forget about games for a moment and take a look at industrial applications. Then try to load a complete Plane CAD model (means: About 1 Billion triangles) and render it with a rasterizer. Maybe you will get the first frame after a Minute. Raytracing can do this at interactive (means 1-2 fps) speeds on current hardware. [QUOTE] I agree, but the human eye is really not that good at figuring out whether reflection and refraction are physically correct, as long as it looks 'subtle enough'. Think of it this way: there was no advantage for mammals and primates in the last 200M years to be able to get very accurate data from reflections and especially refractions. If you think you can tell the difference most of the time, then my guess is you're probably either mistaken or simply bluffing. [\QUOTE] Ever tried rendering a cars headlight? [QUOTE] Baking textures is outdated, I'm not sure where you have been in the last five years, but okay :p See, that's also the problem: many proponents of raytracing are simply using outdated information about rasterization-related techniques. Deano was the Lead Programmer for Heavenly Sword - I'm not sure why I should believe you are more up-to-date on these things than he is. [\QUOTE] Shure, I am not in the games bizz but in the virtual reality industry. And I just happend to get my company to be the leader on visual quality for virtual reality within two years - using GPUs and shaders of course. Funny thing about it: When the people see our images they always think it is raytraced......but it isnt......yet.... [QUOTE] You clearly have no clue what you are talking about here. I suggest you look into Z passes, as they solve that problem perfectly. [\QUOTE] So instead of rendering 5 Million triangles you render 10 Million triangles. Great Idea. Tested it, was even slower for my applications (ok, our usual scene size is about 15 million triangles). And that is although my shaders tent to be very, very long (up to 1000 lines of code). And better than with raytracing this cant be solved unless you do undersampling. With raytracing you shade exactly one fragment per pixel, thats it. [QUOTE] Correct, but that doesn't mean an apple-to-apple comparison would be sufficiently better. [\QUOTE] Just show me a fast software rasterizer. I have yet to see one. [\QUOTE] [QUOTE=nAo] [QUOTE=CaseMillennium] No it wont. Lets forget about games for a moment and take a look at industrial applications. Then try to load a complete Plane CAD model (means: About 1 Billion triangles) and render it with a rasterizer. Maybe you will get the first frame after a Minute. Raytracing can do this at interactive (means 1-2 fps) speeds on current hardware. [\QUOTE] Rasterization will take a 'long time' (not really a minute on any decent modern GPU) to render such a model only if you employ it in a naive way, same story for ray tracing. Why do ray tracing ppl like you compares RT + spatial subdivision structures with plain rasterization is beyond me. There are plenty of ways to reduce rendering time with rasterization as well (spatial subdivion, occlusion queries, etc..) [QUOTE] Then we are at 2.5 Million completely dynamic triangles per seconds - and this is beyond what current Geforce8 Hardware can do. The current games are not completely dynamic, they use structured dynamics and static models for most of their scenes. Try putting 2.5 completely indepentently transformed triangles on you current hardware - performance will be terrible. [\QUOTE] Do you understand that having dynamic geometry or static geometry won't make any difference to a rasterizer? There are already games around that push over a milion dynamic triangles per frame at 30 fps and HD resolution with antiliasing, dynamic soft shadows, complex shaders, etc. And we just started to understand how to push the hw (PS3/360 which don't exactly have a last gen GPU). [QUOTE] So instead of rendering 5 Million triangles you render 10 Million triangles. Great Idea. [\QUOTE] Nothing wrong with that as the first 5M are insanely fast. On next gen consoles we easily render 200-300M triangle per second in the z pre pass (just filling the z buffer). Why you can't achieve these numbers is a mystery.And you can do even better than that using conditional rendering. [QUOTE] Tested it, was even slower for my applications (ok, our usual scene size is about 15 million triangles). And that is although my shaders tent to be very, very long (up to 1000 lines of code). [\QUOTE] Well, I guess you did something very wrong then. And better than with raytracing this cant be solved unless you do undersampling. With [\QUOTE] [QUOTE=AndyTX] [QUOTE=nAo] 2) It's perfectly doable, again, have you ever heard about sampling a texture in your vertex shader to fetch the transform you need? And we already employ a different transform per triangle in games to encode a per primitive vectors basis to give a local reference frame to normal maps. [\QUOTE] Actually to back that up I wrote a fluids demo a few months back (been meaning to post some vids, etc. haven't gotten around to it) that did all of the simulation on the GPU *and* rendered 2mil+ fully dynamic polygons @60fps on a single 8800 GTX. I wasn't doing anything special to make it fast even... it's not hard to get those sorts of numbers or better. [\QUOTE] [QUOTE=nAo] Talking about ray tracing and AA.. what about beam tracing? :) A Real-time Beam Tracer with Application to Exact Soft Shadows (http://www-csl.csres.utexas.edu/gps/publications/beamtrace-egsr07/) [\QUOTE] [QUOTE=CaseMillennium] [QUOTE=AndyTX] I dunno about that... it's clear that raytracing is often necessary/desirable for secondary rays, but switching away for primary rays is dumb. Need I again mention that RTT (rtt.ag, but you probably already know about them if you're in visualization) uses a real-time GPU raytracer that rasterizes the primary rays and I've yet to see anything comparably flexible that is significantly faster. [\QUOTE] Funny you mention RTT because most people in the industry are not really impressed with that raytracer - or should I say: it sucks. The quality it delivers is not what I am used to. Opticore does it quite a bit better but that on is CPU based. [\QUOTE] [QUOTE=CaseMillennium] [QUOTE=nAo] I 1) I'm really curious to know why you need to transform 250k triangles, each with a *completely different* transform. Any real world application? [\QUOTE] Of course not. But no one would rebuild a whole acceleration structure for raytracing each frame either. [QUOTE] For the tenth time, it's easy to get vertex limited if you believe that the only way to render a monster model with a gazilion triangles is to throw it at the GPU as it is. [\QUOTE] And what will you do against that in a modelling application like Maya? The best you can do is using VBOs and maybe view frustum culling. [QUOTE] You mean that thing with craptastic lighting, shadowing and an insanely low triangle count? How do you plan to have soft shadows and AA without throwing dozens of rays per pixel? [\QUOTE] First of all: Triangle count does not matter that much. For the characters, yes, but not for the environment. And about shadows: Use shadowmaps. I didnt say you should use raytracing for everything (at least not yet). [QUOTE] A bilion rays per frame at 30 fps over a milion pixels image means that you have only 30 rays per pixel to use. How many rays do you need to have soft shadows for a single light? [\QUOTE] One! http://www.tml.tkk.fi/~samuli/publications/lehtinen2006eurographics_paper.pdf [QUOTE] what if you have multiple lights? add AO..ad reflections and refraction, 30 rays are nothing if you wanna compete with modern GPUs. when you will have RT hw capable of that GPUs will already be on another planet. Again..you don't really want to use RT for everything, it just doesn't make any sense. [\QUOTE] Of course not. It does make sense for may thing though. [QUOTE] No offense but maybe ppl in virtual reality industry are not exactly pushing the hw the way it's mean to be used. [\QUOTE] That is probably caused by the fact that models in the vr-industry tend to be larger and not optimizable in many aspects. Or spoken otherwise: Just try for yourself to write a system that know exactly nothing about what the model ist and how it was constructed. If you are lucky, you know which of the 1000 transforms are static. In a game you have full controll over your content. In the industry you dont have that controll. The people just throw their bunch of triangles at it an you need to work with that. [\QUOTE] [QUOTE=Mintmaster] [QUOTE=Xmas] I'm not sure I agree with that sentiment. [\QUOTE] When you consider what people see as close enough to correct, and also consider that with enough GPU time you can make great shadows and reflection maps (whether cube or planar) while being waaaay under the computational cost of raytracing, I don't see anything wrong with my statements. [\QUOTE] [QUOTE=Mintmaster] CaseMillennium, you suffer from the same problem as all the other ray-tracing whores. In all your comparisons, you gimp the rasterizer with 1980 technology. [QUOTE=CaseMillennium] Rasterization has another problem that gets more and more important as shaders get more and more complex: It suffers from massive overdraw. [\QUOTE] Overdraw is a solved problem. If you have geometric capacity to spare, then you do a Z-pre pass. If not, then you take the same heirarchical bounding structure that you have for ray tracing (but a much coarser one will do) and sort the objects from front to back. Then you get maybe 20% overdraw. If you really did take a virtual reality company to the top, how can you be so naive as not to realize this? Also, do you know if your 5-15 million polygon scene is even affected by overdraw? Double the resolution and tell me what happens to framerate. [QUOTE=CaseMillennium] Geometric aliasing is the hard one and needs to be solved with additional rays in raytracing. However, adaptiv supersampling and filtering can be applied so you dont need as many rays as one might think at first. A simple way would be to keep track on neighbouring fragments and if the color difference is above a threshold shoot additional rays. If one does proper texture antialiasing the numner of additional rays wont be very large for normal scenes and therefore the speed impact is not too bad. [\QUOTE] Adaptive sampling is wrought with artifacts. Taking your example, what happens when you render a car with tons of seams between panels? All too often adjacent rays are identical, without any clue that there's a seam inbetween. [QUOTE=CaseMillennium] Ok, first of all: I didnt say current systems are there yet. But lets simple guess the larrabee processor will be what it is supposed to be: A massive parallel processor with 80 Cores with the performance necessary. Then we are at 2.5 Million completely dynamic triangles per seconds - and this is beyond what current Geforce8 Hardware can do. The current games are not completely dynamic, they use structured dynamics and static models for most of their scenes. Try putting 2.5 completely indepentently transformed triangles on you current hardware - performance will be terrible. [\QUOTE] Completely independent triangles is a useless case. However, 2.5 million vertices with completely different transformation matrices by way of character skinning is a very realistic scene, and even XBox 360 will eat it for breakfast. Even more pertinent is that only a fraction of its math power is used, whereas you're fully using an 80-core billion-transistor chip from the future! [QUOTE] No it wont. Lets forget about games for a moment and take a look at industrial applications. Then try to load a complete Plane CAD model (means: About 1 Billion triangles) and render it with a rasterizer. Maybe you will get the first frame after a Minute. Raytracing can do this at interactive (means 1-2 fps) speeds on current hardware. [\QUOTE] Bullshit. If you can create a ray acceleration structure, then you can chop up the model and LOD each segment. Automatically if you want to. Even if you're conservative and average 10 polys per pixel, a rasterizer will fly through it two orders of magnitude faster. [QUOTE] Ever tried rendering a cars headlight? [\QUOTE] Car headlights in recent games look fantastic. It's not even close to being the limiting factor in realism for car scenes, either. The point of realtime rendering is to get the look right, not get pinpoint 5-bounce accuracy. Nonetheless, there are ways to make the reflection more accurate with rasterization if you were so inclined. [QUOTE] Just show me a fast software rasterizer. I have yet to see one. [\QUOTE] A hardware raytracer doesn't simplify as much as a rasterizer does when comparing to a general purpose CPU. The rasterizing part doesn't need to do pointer chasing, nor does it need high precision arithmetic. The data flow per pixel is very minimal. [quote=CaseMillennium;1079540] [QUOTE=MfA] Well, we all see how well parallelism works for rasterization when you have a look at SLI in SFR Mode. [\QUOTE] Yet again you gimp the rasterizer. If you had the bounding scene heirarcy of raytracing with the rasterizer, you can easily parallelize in SFR mode. Just look at tiling on the XBox 360. It does sections of the screen at a time. If you had multiple chips, they could do multiple tiles with perfect scaling. The only reason that SFR SLI doesn't scale well is that games don't communicate any bounding info to the GPU, so it has to send all the geometry to each card. [\QUOTE] [QUOTE=ShootMyMonkey] [QUOTE=CaseMillennium] Well, we all see how well parallelism works for rasterization when you have a look at SLI in SFR Mode. However, raytracing is really parallel. I heared rumors that opticore tested their raytracing on a large cluster and they reached the limit at 500 CPUs or so.... [\QUOTE] Well, that's fine and all, but we're not really limited by computational load when you start getting into raytracing complex dynamic scenes. It's the data access and the pointer chasing, and the data reorganization. And that's exactly what gets you with SLI or multiple GPUs. Sure, you get more fillrate, but you're not always fillrate limited. And about the only thing that really says that raytracing will scale higher is the fact that you simply have massively more jobs to throw out when you've delved into Monte Carlo secondary rays and so on. And as Andy said, we're not at the point where rasterization is short for threads to fill in execution resources either. If we were having this argument over the shoes that could be filled by raytracing vs. the same for rasterization, the whole thing would take a different tack. I'm more of a raytracing freak than most of the people here, but I'm not about to say that there are strong arguments to take the dive *right now*... more of a "must have for the future" type of position. The only real gain we might have for raytracing right now would be non-affine camera models (with the advantage that you get per-pixel projection) which is not a big enough value to say "give it to me now". Well, there are a few exceptions, but they are cases where you're trying to support a hack to avoid something more exhaustive... no point in using that as an argument for the most exhaustive thing of all. [QUOTE=CaseMillennium] It has been fought before things like coherent raytracing, SIMD utilization and packet traversal were used. [\QUOTE] Meh. They're neat ideas for the primary rays, and they work well when you're building an architecture which is just a massive collection of floating point units. And of course, SIMD is globally applicable simply because it is vector work, so I'm ignoring that (suffice to say that it doesn't just help raytracers)... The interesting stuff is what follows after those primary rays, and that's a huge, huge problem. Look at Larrabee, which is just enormous on floating point, both in terms of SIMD and scalar, has an enormously wide memory bus, and you've got a gigantic tiled L2 cache, and for all that, no one has said "we can run raytracing" with additional bounces or soft shadows or anything. [\QUOTE] [QUOTE=Soo B3autiful] You are all pissing on Intel now... But at least it is trying something revolutionary for the industry. I am tired of blocky, lifeless, crappy graphics (this include Crysis), and any company showing some interest in change it is welcome. [\QUOTE] [QUOTE=Arun] [QUOTE=lycium] btw, even metropolis light transport can be approached using coherent methods! moreover, you can extract a fair amount of coherence for secondary rays by using a standard deferred shading approach. [\QUOTE] Two very interesting points I hadn't considered at least - same for the advances in dynamic objects, although it doesn't really help if you need any reflection at all in your scene. And dynamic objects reflecting properly is hardly a small thing, but maybe I'm just nitpicking. Anyway, I do appreciate that you are pointing out a couple of the latest state-of-the-art advances, since I'm not aware of all of them myself (I can't speak for others though, so I'm not sure there)! However, I hope you will still agree that comparing 2007 rasterization to 2004 raytracing isn't quite as bad as comparing 2007 raytracing to 1970-1980 rasterization, as some seem to be doing, even here... Furthermore, I would be very surprised if even you were considering cutting-edge rasterization techniques (say, have you read GPU Gems 2/3 and ShaderX 5/6, plus recent papers on things such as caustics or shadowmaps) so I think we're about equal here! :) [QUOTE] all you're left with then is the truly incoherent reflection and refraction, which seems to be a really minimal cost (there is simply no way to get it any cheaper and there is absolutely no wasted computation). [\QUOTE] For physically correct results for most standard mediums, yeah, agreed completely. However, and I don't want to play Devil's Advocate, but as I said above reflections and refractions are the systems that have been the least focused on by natural evolution, IMO. I don't know about you, but my capability to determine whether refraction is correct is pretty damn weak. If it's just one medium change (i.e. air->water), then it could be worse. But for things more complex than that, my brain just has NO IDEA. As for reflection, I can do basic computations regarding where an object is based on a reflective plane, but it's rather approximative (otherwise cubemaps wouldn't work so well!) and my capability to determine the position of objects based on more complex reflective surfaces is rather weak, or at least slow and not subconscient. My point here is simply that even if raytracing can be inherently superior to rasterization for reflection and refraction, I would be VERY surprised if they became the 'weakest links' for image quality in games within 10 years. The eye and the brain just don't seem to care *that* much about how realistic they are, IMO. Of course, that's incredibly subjective since it's MY brain and MY preferences, so feel free to disagree. [QUOTE] see for example benthin et. al's paper on Packet-based Ray Tracing of Catmull-Clark Subdivision Surfaces (ask yourself how rasterising those scenes in realtime would happen!): http://www.sci.utah.edu/~wald/Publications/2007///Subdiv/download//subdiv.pdf [\QUOTE] Well, tesselators are not something you should fear! :) And nice HW ones are slowly being integrated, with R600 already having one (although unexposed at this time) and G92 probably following suit. FWIW, I'm also not a fan of abusing subdivision surfaces. The real world is not made of them, thank you very much. I'm more of a displacement mapping fan myself, but I can see why opinions would tend to differ on these kinds of things and it's not the subject of this thread, so no matter that... [QUOTE] i really don't see how rasterisation can even attempt to solve something like caustic rendering, let alone rendering bounced caustics through specular glass. [\QUOTE] First rule of interactive rendering: Never, ever underestimate the power of hacks... ;) The following page has interesting papers on caustics and also reflection/refraction: http://www.cs.uiowa.edu/~cwyman/publications/ It is expensive and so won't be used in games for a while, but hey, raytracing solutions to that problem are also expensive! And in practice, for a given cost, I wouldn't be surprised if they looked worse. There are other interesting ways to do basic caustics with rasterization, but I don't remember the names of those papers, sorry. Anyway, the proof is in the pudding: Crysis looks splendid underwater. While that might not be the most difficult implementation of caustics, it very well might be the most important in the short-term. [QUOTE] the biggest missing piece of the puzzle, dynamic spatial subdivision schemes, has largely been addressed and is getting better and better. if you threw half as much processing power at ray tracing as we currently do at rasterisation, it would be much faster and you'd have all those nifty effects without any programmer hassle. [\QUOTE] Wait, much faster than what? Than current RT solutions, maybe. But compared to rasterization approaches, I very much doubt that at this point. So even if it 'just' runs at 30FPS instead of 60FPS for a given manufacturing cost, that's pretty much 18 months behind rasterization. And that's a lot in such an incredibly competitive industry... Of course, you could get some effects to look better with raytracing, but then for a given level of performance, other (potentially more important) aspects of the graphics might have to look worse... [QUOTE] i don't see how the term applies when you're doing the absolute minimum possible. if it's efficient it's not brute force. [\QUOTE] I think anyone would agree that coherent raytracing for primary hits and shadow hits is pretty much brute force compared to rasterization... Of course, the raytracing proponent's arguement is that these things will become effectively 'free' over time, but we are not quite at that point today, or even within several years. [QUOTE] if you want to talk about brute force, let's take a look at stencil shadow algorithms... [\QUOTE] Considering the research done by AndyTX (and nAo) in shadowmap filtering, I think it's rather ironic you try to use such an arguement :p There clearly aren't many stencil shadow fans left today in the rasterization world, so no offense intended, but I suspect you're also a bit behind the cutting edge there! :) (which is fine, really, but worth admitting for every side of the debate) Anyway, see my next post for a different kind of reply to your other points... (i.e. not technical per-se!) [\QUOTE] [QUOTE=nAo] [QUOTE=Arun] (say, have you read GPU Gems 2/3 and ShaderX 5/*6*, plus recent papers on things such as caustics or shadowmaps) [\QUOTE] Wow..you already read it, I thought it was going to be published next February :) [\QUOTE] [QUOTE=DeanoC] [QUOTE=lycium] hmm the sarcasm was a bit too thick... i agree, it isn't a problem, but the article said it *is* a problem to ray trace lots of dynamic stuff. however, just as havok got around it (collision queries are essentially ray tests, so they have the exact same problem), ray tracing can get around it with these fast new spatial subdivision schemes. this isn't mentioned in the article, and again, it really does change the game completely. [\QUOTE] Erm Havok does not do ray tests for its main collision and dynamics! [QUOTE=lycium] well, that's a fundamental thing. the rendering equation in its full generality cannot be efficiently solved by rasterisation methods. sure, you can render the scene for every ray that needs to be tested, but as you rightly pointed out in your first point, there's not a lot of coherence - and rasterisation exists only because it is efficient through coherence. global illumination is SERIOUSLY complex to solve in its entirety! as i've mentioned, even the most sophisticated metropolis methods have slow convergence in certain tricky situations and i really don't see how rasterisation can even attempt to solve something like caustic rendering, let alone rendering bounced caustics through specular glass. [\QUOTE] Ah okay you've not read some of the ongoing research into GPU GI. Heres a few from SIGGRAPH 2007 that are attempts at real-time path tracing http://www-sop.inria.fr/reves/Basilic/2007/DSDD07/ImplicitVisibilityAndAntiradiance.pdf http://www.mpi-inf.mpg.de/resources/EikonalRendering/index.html This is a bit older but still and interesting read http://artis.imag.fr/Publications/2006/KTHS06/kths06-prt.pdf Also worth pointing out Geomerics Enlighten http://www.geomerics.com/products.htm In fact if you want to over state the case, you could probably claim that for static scenes GI is a solved problem for GPU architectures... But I didn't and don't claim that because its a worthless statement until dynamic scenes can be handled imho. [\QUOTE] [QUOTE=nAo] [QUOTE=lycium] i'm also in the "spare a thought for incoherent ray tracing" group ;) however, it's always one step at a time: gpus didn't have t&l, programmable shading, unified processor and memory architectures etc. right from the start, it takes a while to get there. and one of the ways to make ray tracing more immediately available is to use coherent ray packets. [\QUOTE] While you're right and it takes time to get 'there' for most part advancement in rasterization and GPUs are here to stay. At the same time we can't really say we care that much about advancements in ray tracing coherent rays. Now don't get me wrong, research it's always a good thing and it's never enough, but I got the feeling most of the attentions are focused on coherent rays cause that's the easy part to address. [QUOTE] there's another reason to push ray tracing for primary rays btw. it's definitely occured to a lot of people, that it's actually really dumb to have sub-pixel-sized triangles ;) processing power is outpacing memory bandwidth ridiculously much these days, so instead of pushing all of that memory around to approximate surfaces, why don't we just render the surfaces we want to approximate directly? this way we also usually get perfect surface normals, tangents, perfect lod, ... [\QUOTE] Is this really that relevant to thid discussion? You're talking to something that can be relatively orthogonal to rasterization and ray tracing. REYES, for instance, looks much more like plain rasterization than ray tracing, but it almost never shade anything that doesn't generate any coverage (before stochastic sampling/compositing) [QUOTE] well, that's a fundamental thing. the rendering equation in its full generality cannot be efficiently solved by rasterisation methods. [\QUOTE] Again, is this really relevant? What we should ask ourselves if a certain algorithm can be used to find an approximate solution for the rendering equation that doesn't require too much specialization. Something good enough to fool our brains. [QUOTE] if you threw half as much processing power at ray tracing as we currently do at rasterisation, it would be much faster and you'd have all those nifty effects without any programmer hassle. [\QUOTE] This is quite shocking claim, can you prove it? Why don't we already have cheap graphics hardware based on ray tracing? [\QUOTE] [QUOTE=Mintmaster] [QUOTE=lycium] Global illumination: I think this is a bit out of place when discussing realtime ray tracing. Even sophisticated implementations of Metropolis light transport will struggle in certain difficult situations, like viewing caustics via specular reflection. Since MLT is the most robust rendering method we know (photon mapping coming a close second, often needing Metropolis sampling in difficult settings), one can hardly expect lesser monte carlo methods to do the job reliably in any conceivable situation. Efficiently handling *any* mode of light transport path is a massive big fat unsolved problem in rendering, and until that's solved for offline rendering we shouldn't expect to see it in realtime! [\QUOTE] In the context of how valuable realtime raytracing is, I think GI is fundamental to the argument. That's the only aspect of graphics that has a solution with raytracing but no currently acceptable substitute in rasterization. Realtime graphics does not have a goal of accuracy, but rather believability. If you ignore GI, there's really no point to realtime raytracing, because all problems are pretty much solved. High poly count isn't really an issue. If we wanted more polys right now, we could do it, as only a fraction of rasterization hardware today is devoted to triangle setup. LOD negates the need for more than a few billion tris/sec, and hardware will get there when the rest of the system can handle that. Reflection/refraction for all but the rarest surfaces looks very believable with rasterization methods. If you want perfect interreflections, then fine, I concede that raytracing is the only way to go. However, reflection quality is never a complaint with realtime graphics. Hell, people have long been praising water rendered with a cube map for the environment instead of a reflection map, even though the former has no all local reflection for anything in the water or near the shore! For shadowing, you're looking at really bad solutions. Stencil shadows was just a fleeting solution which was semi-popular a few years ago because it mapped so well to hardware and scenes were so low poly. Perspective shadow mapping was just one of the first ways to get better texel distribution for shadow mapping. More robust is cascade shadow mapping, and there the number of pixels drawn in the shadow map is not that far off from the number of secondary rays you'd need in raytracing. The only duplication is from shadows that pass through the cascade boundaries. If you ignore GI, then realtime raytracing is trying to solve a problem that just isn't there. All the die space devoted to the stream processors today has nothing to do with the raytracing/rasterization argument. Only a small amount is devoted to triangle setup and rasterization, yet it will take one hell of a processor to get raytracing up to a similar speed. [\QUOTE] [QUOTE=Mintmaster] [QUOTE=nAo] This is quite shocking claim, can you prove it? Why don't we already have cheap graphics hardware based on ray tracing? [\QUOTE] A lot of people don't realize how little power we do throw at rasterization. Take out all the stream processors and insert a fixed function matrix tranform to complement the triangle setup (since that's the only extra work compared to a raytracer), and you have something that packs one or two orders of magnitude more punch per transistor than a Larabee raytracer, even for scenes with 10M polygons in the view frustum. [\QUOTE] [QUOTE=lycium] [QUOTE=nAo] I don't agree with this explanation (it sounds like a conspiracy theory), but for the sake of discussion let say you're right. Then why companies like 3Dfx went with rasterization and not with ray tracing? [\QUOTE] people were rasterising triangles so they brought out hardware that does exactly that, but much faster and with bilinear filtering. seems kinda straightforward to me - to introduce ray tracing prematurely (no dynamic geometry, and i shudder to think how long a SAH-based k-D tree would take to build back then) at that stage would be suicide. it was the right time for hw rasterisation, particularly if you look at the transistor budget. [QUOTE=nAo] Well..I fail to see where ray tracing vs rasterization efficiency is discussed/compared in that paper. Should I buy a new pair of glasses? ;) [\QUOTE] it's not difficult to see that Great Things could be done with the power available to modern gpus. you can never do an apples-to-apples comparison, but with old algorithms from 2005, a 66mhz prototype fpga and a tiny straw of memory bandwidth they were doing extremely well. ... this is slowly getting ugly. i didn't come here on a crusade to start converting people, i'm interested in all aspects of computer graphics and think it's all awesome. the progress being made with realtime ray tracing is really remarkable and i wanted to point some of them which this article overlooked that change the picture dramatically. the article's title asks if rtrt is the holy grail, to that i say yes simply on the basis of can vs cannot do. this isn't about make do - i fully agree that what we have with gpus kicks plenty of ass and i didn't buy my geforce 8800 to do ray tracing - but the fact is that when you're talking about the holy grail simple things like reflection and refraction must be accounted for at some stage, and even greater things like global illumination are just entirely out of rasterisation's reach. [\QUOTE] [QUOTE=DeanoC] [QUOTE=lycium] ... this is slowly getting ugly. i didn't come here on a crusade to start converting people, i'm interested in all aspects of computer graphics and think it's all awesome. the progress being made with realtime ray tracing is really remarkable and i wanted to point some of them which this article overlooked that change the picture dramatically. [\QUOTE] Which is cool, I'm glad you did :) Opinion peices (which I hope its clear it is) are meant to get a debate going. I come from a GPU background, where I see fantastic advances in GI and advanced lighting are occurring all the time. Well above simple reflection and refraction, but this isn't mentioned once in ray tracing articles (and we get comparisions with 5 year old games and 1980 teapots ;-) ). So this is a counter-point, designed for proponents of both sides to have a discussion. In fact I'd love to see a "Rasterisation : Holy grail or fools errand" article by someone like yourself pointing out the faults in rasterisation based approach. [\QUOTE] [QUOTE=Davros] hey ive just had an idea (please feel free to tell me how stupid i am) the x-fi dsp deals with ray tracing of a sort (the reflections and occlusion of sound waves) they also own 3dlabs - they should make some ray tracing hardware :D [\QUOTE] [QUOTE=DeanoC] [QUOTE=lycium] guys, i really must duck out of this discussion for now and do some serious studying for my exams :/ about that offer to do an article on realtime ray tracing, i'd actually really like to do that and would be honoured to author an article for beyond3d. i have two requests, however: it should be in good spirit, not head-to-head competitive as these things tend to be, and i'd have to write it in mid-november after my exams. offer still valid? [\QUOTE] Good luck with your studying, I can't speak for the Beyond3D (i'm just a guest :) ) but i'm personally interested into your insights into real time ray tracing so any article, at any time I'd find intersting. Again good luck! :) [\QUOTE] [QUOTE=Laa-Yosh] It seems to me that lycium has a more academic approach to rendering: do everything in the physically correct way and "solve" rendering by providing every feature imaginable. This includes caustics and diffraction and everything else. I'd agree that raytracing is required for most of these features so rasterization alone wouldn't work for his purposes. However most of the other posters, and the industry itself, is not interested in being physically correct. All we care about is the result and faking various features is not even okay, but a requirement. This is a far more practical approach and has a very different view of what's important and what's not. For example, huge amounts of geometry and textures are far more important to raise the level of immersion then physically correct reflections or refractions - noone has ever complained about the car shaders in Gran Turismo, yet everyone would appreciate more detailed enviroments. And it's just a racing game, nowhere near as ambitious as the next Grand Theft Auto, which would benefit from the above mentioned technical advances even more. And let's be honest, even raytracing is using vastly simplified models for lighting, using terms like diffuse instead of actually modeling the microscopic irregularities of the surface... Also, baking lighting information, or anything really, is a perfectly valid option as long as the imposed constraints are acceptable. Destroying every piece of level geometry would break gameplay in most cases, movig large pieces of shadow-casting geometry doesn't usually happen in the real world either, changing the time of day is only important if the player has to spend a long time in the scene, and so on. Regarding offline rendering, ray tracing is indeed gaining a lot of ground lately. Pixar had to implement a good raytracing engine into PRMan, partially because their own projects' requirements (reflective cars) and because of their clients' requests. The most recent case for grand scale raytracing has been Transformers, with all the shiny car parts and battered metal in the robots' exposed mechanics. And yet, whenever they could, ILM's artists have used simple reflection maps on them to speed up the rendering, as going fully raytraced on 3-4 robots in a single scene has usually resulted in rendering times up to 38 hours. Now that's still only on a single computer, as distributing a single frame over a computer network is less effective as having each rendernode work on individual frames of a sequence. But even with thousands of CPUs this means that artists can't send out their work to be rendered over a single night, which seriously constrains the highly iterative nature of offline rendering. It is perfectly usual to re-render all sequences dozens, even hundreds of times during a production and progressively increase the quality of assets, effects, lighting etc. until it reaches a certain level or production time runs out. But this requires relatively fast rendering times - which have usually remained at around 30-120 minutes for more then a decade. As computers get faster, the detail is increased accordingly. Transformers is more of an exception to this with its huge rendering times, and ILM will surely request Pixar to work on their raytracing a little more for the second installment of the movie. Other common uses for raytracing include ambient occlusion, where the VFX industry is very interested in what the GPU-related research can offer as an alternative. The same goes for translucency (and I'd rather we use this term instead of its most common implementation, subsurface scattering), reflection occlusion and any kind of indirect illumination. Brute force GI solutions like Maxwell are generaly reserved for the architectural visualisation guys, who can bake the results anyway, because all they care about are static enviroments. Turning these advanced features on will seriously increase rendering times and even with faster computers, fakes and tricks and such are still preferred and even required to finish a job. And as tight as our deadlines may be, completing a frame in 1/30 of a second is still tighter... [\QUOTE] [QUOTE=MfA] [QUOTE=nAo] A Real-time Beam Tracer with Application to Exact Soft Shadows (http://www-csl.csres.utexas.edu/gps/publications/beamtrace-egsr07/) [\QUOTE] I always mistakingly thought of beam tracing as using one beam per pixel, this makes much more sense. You can actually get away with a much more coarse subdivision of the scene with this than with raytracing because you can simply throw the first object you come across at the beam tree, rather than only throwing beams at the objects. It can function as a hybrid object/image order rendering technique. Still lacks some of the regularity of pure object order rendering, but it's a lot better than raytracing for primary/shadow rays (as long as the beam tree doesn't fragment too much). Carmack rejected this approach at the time of Quake, but his use of a single BSP for the level meant that any gap providing long distance view (such as the sky) meant you had to test much more of the scene than strictly necessary. [\QUOTE] [QUOTE=Geo] [QUOTE=CaseMillennium] But I am drifting offtopic. [\QUOTE] You are, but I suspect that conversation would be very welcome by our hardcore coder types in the 3D Algos & Coding subforum to this one. Feel free to start a new topic in there and y'all can exchange some information on the differences/similarities between using gaming hardware for gaming vs what you do. I bet some of our guys would love to have that convo. [\QUOTE] [QUOTE=Joshua Luna] This is a very interesting and instructive discussion. Thanks guys. I would like to add a small note about this discussion from an enthusiest/hobbiest perspective. Before I became a regular lurker to B3D about 5 years ago I had always had the impression that Raytracing was superior to Rasterization and was the way of the future once the hardware was fast enough. I would absolutely say, from a layperson perspective, there is a mentality that Raystracing IS the holy grail of graphics. If we wanted CGI quality graphics, Rasterization wasn't going to get us there--Raytracing was absolutely necessary. And then it was brought to my attention that most CGI and CGI films, at least partially, used Rasterization. I found this surprising, and it defied much of what I (and others) had heard over the years. Sometimes information gets exaggerated/distorted as it filters down to the end user/audiance, but I would say I am not the only one who has heard this. From a lay perspective I think most find it shocking that VFX artists will use Raster techniques because they give a similar (if not identical result) in many situations and it is much faster. Another element of the broader discussion is Global Illumination. I cannot speak for everyone, but I know that I assumed that Raytracing=Global Illumination, which isn't the case. And imo, it is GI, and not Raytracing, that is the "Holy Grail (TM)" of realtime graphics. How this solves itself in the realtime arena will be interesting (hybrid RT/Raster solutions? Precomputed data?). I think the "ball" we need to keep our eye on is return on investment. From a realtime perspective I think whoever said, "We are aiming for believability, not realism" hit the nail on its head. If a Rasterization solution is 90% "accurate" but believable and 4x as fast it is going to win. Raytracing is going to need to give better results at the same 'cost' or the same results at a lower 'cost' for it to become significantly relevant in the realtime arena for games. Developers aren't going to chuck their legacy tools and workflow for a solution that doesn't offer either a sizable speed or IQ improvement, and companies like NV and AMD won't dump their billions of GPU investment for a solution that gives end users LESS in terms of visual quality. I think the lack of a discerning eye among consumers will also play into this. e.g. Project Gotham Racing 4 is using data from the previous frame to get reflections that include dynamic world objects (like crowds and cars) that are anti-aliased. A sneak solution with a decent, if not imperfect, result. Yet... few ever noticed the cars were missing from the reflection! Seeing the work some developers are doing with shadow maps, PRT, ambient occlusion maps, etc and you wonder: At what point do consumers lose the ability to identify and differntiate? If Raytracing is treating corner cases where Rasterization fails, do these trouble areas merit the attention in the consumer/realtime arena? Would that investment be better placed in other areas that could benefit from the transistor investment? *I don't know the answers to these questions of course.* It seems likely that in the future we will see hybrid Raytracing/Rasterization solutions. IMO, the article definately speaks to my experience: Raytracing is the holy grail for realtime graphics and Rasterization is a cheap hack that won't deliver us to CGI quality graphics. I wouldn't mind hearing some of you guys sound off on this question: What will happen first: A.) GPUs will offer realtime "CGI quality" results (albeit dated, lets say A Bug's Life, Toy Story 2, etc) B.) Realtime Raytracing will match performance/quality of GPUs released in the same timeframe(about 6-12 months) IMO, if A.) happens the Raytracing question becomes much less relevant as the point in realtime graphics for consumers is what is on screen, not how it got there (with a big assist to "how easy is it for developers"). Until A.) happens, the door is still open for B.). The real question is will either occur before we hit the physical limits of silicon, and if not will we find a mass producable alternative for the consumer market. The future is sure foggy looking 10-15 years into the future. [\QUOTE] [QUOTE=Laa-Yosh] [QUOTE=Luna] A.) GPUs will offer realtime "CGI quality" results (albeit dated, lets say A Bug's Life, Toy Story 2, etc) [\QUOTE] Considering that only Bug's Life has used raytracing and only in the scenes with the glass jar full of nuts, we can theoretically render any scene from those movies on current GPUs. The lighting was based on lots of simple lights and shadow maps. Practical problems would be: - insane amount of geometry: lots of objects, everything is tesselated to micropolygons, quads less then 1 pixel in size, and most surfaces are displaced - very complex procedural shaders: some used for the vegetation and the ground, some for the bug body parts, all combining color, specular and displacement information - very high quality 3D motion blur (Pixar's stuff is probably the best) - very high quality geometry and shader antialiasing and texture filtering I guess that only the subdivision + displacement would be hard to do on current architectures, the rest is really an issue of performance, and the audience would probably not care about even significant downscaling of the visual detail and sharpness (ie. lower quality AA/texture filters/shadows etc). If Carmack really has some solution planned out for the geometry issue for id Tech 6, then we can expect the next generation console hardware to really do something remarkably similar to those Pixar movies in real time. [\QUOTE] [QUOTE=Rys] What about the programming side of things? Assume Intel delivers amazing hardware and research solves the acceleration structure problem (two enormous assumptions, but stick with me), and that somehow there's a slowdown in the march of consumer monitor resolution going up and up for less and less money. Is there not a significant programming hurdle to climb, to pull away developers used to doing good things with IMR hardware and Direct3D and OpenGL? Surely you want to use something else to program a ray tracer in a common fashion, and does Intel have any notion of programmers driving hardware development, even if something shows up? I can't see you wanting to program a real-time RT chip with D3D or similar, but maybe I'm missing something there. Even if all of that works out, there are well established market forces in terms of graphics supply and demand that mean Intel have a near vertical waterfall of water to swim up. Are they even planning for that? [\QUOTE] [QUOTE=MfA] [QUOTE=CaseMillennium] While you can use one processor for each triangle to transform and another one for each pixel to shade, you have no chance of knowing a priori which pixels your triangle will overlap. [\QUOTE] That's not how you parallelize rasterization on clusters, you simply tile the screen (with all due respect to all the research into sort last and sort middle parallelization there is just no advantage at all over sort first if you have the scene data to work with). The limit case would be 1 pixel tiles, you'd be working on single pixels just like raytracing. The way parallelization is handled at the moment with GPUs is just an artifact of the API, has little to do with the fundamentals of rasterization (or rather, object order rendering). The example of the 360 and tiled rendering has already been brought up. [\QUOTE] [QUOTE=CaseMillennium] [QUOTE=MfA] That's not how you parallelize rasterization on clusters, you simply tile the screen (with all due respect to all the research into sort last and sort middle parallelization there is just no advantage at all over sort first if you have the scene data to work with). The limit case would be 1 pixel tiles, you'd be working on single pixels just like raytracing. [\QUOTE] But if you do that, the problem case is a triangle covering the whole screen. Each processor will need to transform this triangle. Doing sort first you only avoid the work for the pixelshader and rasterizer and a littlebit for the vertex shader if you do view frustum culling. But you are doing work multiple times for a single triangle. And sort first doesnt scale as well with the number of CPUs as raytracing does (at least the tracing part) [\QUOTE] [QUOTE=CaseMillennium] [QUOTE=Rys] Is there not a significant programming hurdle to climb, to pull away developers used to doing good things with IMR hardware and Direct3D and OpenGL? Surely you want to use something else to program a ray tracer in a common fashion, and does Intel have any notion of programmers driving hardware development, even if something shows up? I can't see you wanting to program a real-time RT chip with D3D or similar, but maybe I'm missing something there. [\QUOTE] Well, OpenRT has been around for some time now and some OpenSource implementations already exist. And with RTSL (http://www.cs.utah.edu/~boulos/papers/rtsl.pdf) a shading language for raytracing has been proposed as well. Of course it takes time for something like this to evolve but it is a start. [\QUOTE] [QUOTE=nutball] [QUOTE=CaseMillennium] But if you do that, the problem case is a triangle covering the whole screen. [\QUOTE] Forgive me for interjecting but to a layman like myself this seems like a trivially irrelevant corner case. Each processor will transform this triangle, which will take what... a few hundred nanoseconds. Is this a bottleneck in practical terms? I'm genuinely interest here ... [\QUOTE] [QUOTE=Davros] [QUOTE=AndyTX] Please see the excellent paper Splatting Indirect Illumination (http://www-sop.inria.fr/reves/Carsten.Dachsbacher/download/sii.pdf[/url) . [\QUOTE] Doesnt exist [\QUOTE]