Real-Time Ray Tracing : Holy Grail or Fools’ Errand? *Partial Reconstruction*

[AlNom]

Okay, here's my attempt at bringing back *some* of the posts I could find floating about on the internet. I'll update each post as I go along i.e. 1 post = 1 page of the original thread I could find.

I did find all of page 2... it may very well be the longest single post in B3D history.

With Intel making noise about acceleration of real-time ray tracing in recent months, especially where it concerns future hardware they're working on, DeanoC found himself a little puzzled as to why.

Pitting real-time Whitted RT vs traditional real-time rasterisation, Deano's article compares the two approaches to see where the pros and cons of each approach lie. Should we be hailing our future shiny ball overlords, or does recent RT chatter need a bit more to back it up?

Have a read and find out

---------------------------------------------------------------------------------------------------------------------------------

Fool's errand IMO.

Yeah, rasterization is a gross simplification, but so is ray tracing.

With Intel making noise about acceleration of real-time ray tracing in recent months, especially where it concerns future hardware they're working on, DeanoC found himself a little puzzled as to why.

Intel are emphasizing ray tracing because it is something their CPUs do better than GPUs. When ray tracing gets interesting (lots of reflections, lots of refractions, lots of objects) branch coherence and memory locality tanks, killing GPU performance, making Intel's CPUs look great.

Cheers

---------------------------------------------------------------------------------------------------------------------------------

Two things (no, three):

- very well written and accessible article!
- "A hybrid approach will probably offer the best of both worlds." were exactly my thoughts at seeing the topic's title, but then that was obvious enough.
- regarding the indirect lighting thing, wasn't there a company that had some kind of solution to this? (company that worked together with Guerrilla among others?) Or am I confusing things ... (global illumination maybe).

EDIT: Yes, it was indirect lighting:

http://secondintention.com/portfolio/worldlight/

from the page:

Key features

- Efficient PRT mesh format using 12 bytes per vertex - only as much data as a floating-point normal!
CPCA compression allowing arbitrary order of PRT simulation with the same per-vertex size and runtime cost. Higher orders cost more CPU time and CPCA basis table storage, but the GPU cost remains constant.
- Multiresolution shadow maps giving crisp shadows both close-up on small details and in the distance on large buildings. Shadow map selection avoids use of the stencil buffer completely.
- Depth guided screen-space shadow filtering for soft shadows without depth artifacts.
- Local cubemaps for both specular lighting and PRT Spherical Harmonic diffuse lightsource generation.
- Real-time implementation of Geigel and Musgrave tonemapping. This simulates the nonlinear behaviour of different negative and print film emulsions allowing the user to input film characteristic curve data and see the real-time world rendererd as though photographed with the film they have selected.

Seems to be relevant to the article, and maybe worthy of a B3D interview/investigation?

---------------------------------------------------------------------------------------------------------------------------------

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.

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). E.g you can use screenspace AO just as good with ray tracing as you would with rasterizing. You could even use lightmaps with ray tracing if you really wanted to :smile:

Also one thing worth noting is that currently the most expensive thing in ray tracing is not usually traversing tree or intersecting triangles but shading. Doing things like bilinearly filtered bump-mapping isn't exactly cheap to do on a regular CPU, you know


As for some of the points in article:
Aliasing
Yes, it is a "bit" more difficult with ray tracing, although there there has been some research done on the subject. Current implementations doesn't generally use LOD to reduce geometry aliasing because they try to show how fast they can trace lots of triangles. Adaptive anti-aliasing is another topic that hasn't had too much attention lately but could be quite good at reducing aliasing. Also CPUs are not good enough to do anything but bilinear texture filtering in reasonable amount of time. Intel Larrabee should have HW units for texture filtering so this point should be close to being fixed.

Static or moving scenes?
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. Skinning takes as much time as it would with rasterizing.
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.

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.

Luckily for rasterisation-based renderers, real-world scenes made of shiny transparent balls are rare.

Is it because these effects are not exactly useful or because they aren't that easily implementable on current GPUs
I wouldn't mind seeing more translucent stuff in games (liquids, glass) but things like that aren't generally used all that much. I still remember bringing my PC to halt by putting around 20 glass objects behind each other in HL1 map editor and trying to look through all those :smile:

At the same time, though, a completely dynamic scene with lots of overlapping large triangles would kill a real-time ray tracer.

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.
Tessellation helps with those large overlapping triangles, though I doubt many games have those big overlapping triangles anyway.

A hybrid approach will probably offer the best of both worlds. Many ray tracers already replace primary rays with rasterisation and only compute secondary rays through traditional ray tracing.

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. Also it would make things like overlapping translucent surfaces a lot simplier to render.
Of course in the immediate future it would lessen the load on CPU allowing it to trace more secondary rays but I highly doubt if it would be viable in the future.

The ability to spawn rays in the GPU’s shader core would solve many hard problems that rasterisation engines have to face.

Yes but that would require GPU to have all the information about the entire scene in its memory at all times, including the acceleration structure. You couldn't just trace rays before you've sent all the geometry to be rendered. No matter how you look at it this kind of GPU rasterizer won't look anything like we have today.



Also I'm quite sure that ray tracing games on general CPUs will not be done any time soon as they lack a whole lot of useful HW units and they always lag behind special HW like GPUs. Of course there have been some rea-time demos but I'm talking about game-quality here. On the other hand if we would have a decent HW that has lots of FP power and some special units then it could very well be doable. Larrabee with its 24+ 4-way SMT cores and 512bit SIMD looks like something that could allow it.

Larrabee might not be the only contender to the ray-tracing chip title, there have been other researches on the subject. One of the latest one is Hardware Ray Tracing using Fixed Point Arithmetic, a bit older one is Estimating Performance of a Ray-Tracing ASIC Design (more stuff here). Both offer a special purpose solution and are likely much more efficient than general CPU or GPU doing the same thing.


I bet most people already have heard about Intel demo of ray traced Quake4. 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.


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 and there are still problems left to be solved. Of course the simple direct ray tracing won't be the one trying to compete with rasterizing, it will be something like instant global illumination that got demonstrated a few years ago.

*) my guess 1.5-3 years for first good looking tech-demos, 4-6 for some serious games sold for gamers.

---------------------------------------------------------------------------------------------------------------------------------

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.

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.

---------------------------------------------------------------------------------------------------------------------------------

1) it takes about 4 years to build a game USING foundation of existing production workflows and supporting toolset.

Yes, I agree. I was actually thinking of Intel showing something when they release Larrabee around late next year/early 2009, others won't have something for years to come :smile:

About point 3, what makes it impossible to use similar techniques with ray tracing? As I've said one can use pretty much every rasterizing trick in ray tracing too.

---------------------------------------------------------------------------------------------------------------------------------

I bet most people already have heard about Intel demo of ray traced Quake4. 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.

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.

---------------------------------------------------------------------------------------------------------------------------------

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.

Seems like someone forgot to watch the demo video

http://www.idfun.de/temp/q4rt/videos...elPohl_cut.wmv
hint: ~2:30

---------------------------------------------------------------------------------------------------------------------------------

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

 

[AlNom]

Page 2:

2. Static or moving scenes: Ok, this is indeed a problem but let´s face it: Framerates above 30 fps don´t make sense, the human eye is to slow to recognize it.

Not that again....
Most humans can notice up to 60Hz (some even more), depending on their age, level of fatigue... (Ever wondered why people didn't like 60Hz CRT ?)
To have a smooth flow, you need around 60fps, of instantaneous frames.

The movie analogy is flawed since a real camera frame stores what happened during a period of 1/frequency, while a computer frame stores a shot of no duration. (instantaneous)

You can read http://en.wikipedia.org/wiki/Frame_rate

---------------------------------------------------------------------------------------------------------------------------------

Mmhh, sorry but the article is pretty bad and doesn´t really show much knowledge of the topic.

I beg to differ, see below.

1. Aliasing: Yes, aliasing is a problem, as is with rasterization. However, there are two different sources of antialiasing: geometric aliasing and texture aliasing.

I certainly hope you don't think Deano doesn't realize that...

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.

Correct. You also can't compute derivatives based on quads as in rasterization, AFAICT - although with very small triangles, that's besides the point.

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 don´t 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 won´t be very large for normal scenes and therefore the speed impact is not too bad.

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.

2. Static or moving scenes: Ok, this is indeed a problem but let´s face it: Framerates above 30 fps don´t make sense, the human eye is to slow to recognize it.

Let's face it: you don't know anything 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...

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.

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!

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.

I suggest you read other comments before responding, as this nicely summarizes the problem with your reasoning:

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.

...

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.

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.

With rasterization on the other side, many of those problems can´t 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 can´t be calculated correctly with rasterization.

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.

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.

Baking textures is outdated, I'm not sure where you have been in the last five years, but okay 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.

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 doesn´t 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).

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).

Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears.

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.

---------------------------------------------------------------------------------------------------------------------------------

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 don´t 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 won´t be very large for normal scenes and therefore the speed impact is not too bad.

With rasterization we can independently address geometric aliasing, texture aliasing and shading aliasing. With RT and the method you propose geometric aliasing and shading aliasing are the same thing, which is not the case at all.

2. Static or moving scenes: Ok, this is indeed a problem but let´s face it: Framerates above 30 fps don´t make sense, the human eye is to slow to recognize it.

Even though I perfectly agree with your 30fps assumption I can assure you that my eye (or better my brain) is perfectly able to tell the difference between 30 and 60 fps, even with fairly slow moving objects. Am I not human? :smile: tracer will be out we will be able to do much better than that on rasterizers,

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.

Dunno if your numbers are accurate or not, but 250k dynamic triangles per frame are nothing. I recently worked on a PS3 game that pushes over a milion dynamic triangles per frame, when a decent hardware rayfor free.

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.

What you don't get is that ppl working on games and movies don't give a damn about being 'correct'. They fake everything, EVERYTHING, all the time.
One day we will have machines so powerful that we could get extremely complex scenes to run in realtime with all sort of 'correct' (not really..) effects computed with RT.
Too bad your friend next door will run a scene a thousand times more complex than yours with a mixture of techniques.

With rasterization on the other side, many of those problems can´t 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 can´t be calculated correctly with rasterization.

I predict that when all this stuff will be viable in realtime employing cheap RT hardware on fairly complex scenes ppl will have addressed (or faked, as you like) most of the stuff you're talking about with algorithms that are a blend between rasterization and RT (I'm thinking about non uniform rasterization and plain good old multiple rendering passes..)

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 doesn´t 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).

Have you ever heard about z-pre-passes, deferred renderers, tile based deferred renderers, etc..?
I mean..ppl have been using z pre passes for AGES now, and this stuff is so effective just cause rasterizers are so blazing fast that we can render our scene two times per frame, no matter how complex it is, just for the sake of filling the depth buffer (and its on-chip compressed representations..) and almost completely eliminate overdraw while we are shading pixels for real. This also buys effective early rejection at massive rates (dozen of pixels per clock cycle)

With raytracing on the other hand, each pixel is shaded exactly once causing zero overdraw.

Good, but it's not really ground breaking as we already do that with rasterization, just not in one pass. But since it's so fast anyway we don't care :smile:

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!!

You know that not one of these 128 processors is involved in rasterizing the image, do you?
Your next gen hardware ray tracer to be competitive with your next gen GPU will need not only to be able to compute some dozen bilion ray inteserctions per frame, but it will also need to compete with a GPU at shading an image. Rasteriation hardware probably doesn't take that much space on current GPUs, but all the extra area needeed to accelerate ray tracing is chip area that won't be utilized to shade the image.
Maybe my assumption is wrong, maybe a dedicated ray tracing unit and memory access unit that supports it don't take more space than a custom rasterization block, but I'm not entirely sure about that.

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.

PPL have been saying this for ages on this board, future = use RT where it makes more sense, for the rest we have rasterization.
What I can't make any sense of is the "rasterization is doomed, real time raytracing is coming" mantra, cause it's laughable at best.

Marco

---------------------------------------------------------------------------------------------------------------------------------

Arun and nAo have already responded to pretty much everything, but I'll add a point or two:

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.

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.

Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears.

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).

Cell is pretty much ideal hardware for computing ray intersections (I doubt custom hardware would do much better)

I don't think I agree with that! See: http://forum.beyond3d.com/showpost.p...3&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/Publica...rt06_final.pdf

---------------------------------------------------------------------------------------------------------------------------------

You also can't compute derivatives based on quads as in rasterization,

And why would that be? Of course you can. It just isn´t ideal because the quality sucks and it doesn´t work with reflections anyways. For raytracing you use ray differentials and propagate them. Works perfectly :smile:

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!

Ok, first of all: I didn´t say current systems are there yet. But let´s 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 won´t 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.

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.

No it won´t. Let´s 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.

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.

Ever tried rendering a car´s headlight?

Baking textures is outdated, I'm not sure where you have been in the last five years, but okay 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.

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 isn´t......yet....

You clearly have no clue what you are talking about here. I suggest you look into Z passes, as they solve that problem perfectly.

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 can´t be solved unless you do undersampling. With raytracing you shade exactly one fragment per pixel, that´s it.

Correct, but that doesn't mean an apple-to-apple comparison would be sufficiently better.

Just show me a fast software rasterizer. I have yet to see one.

And why would that be? Of course you can. It just isn´t ideal because the quality sucks and it doesn´t work with reflections anyways.

Yes, sorry, I should have been a bit more precise: I was thinking in terms of it being free with rasterization for large triangles and, AFAICT, not being so with raytracing. However, large triangles are not the future anyway, so that's not really the point.

Ok, first of all: I didn´t say current systems are there yet. But let´s simple guess the larrabee processor will be what it is supposed to be: A massive parallel processor with 80 Cores with the performance necessary.

No, that is not Larrabee, sorry. Anyway, this is besides the point, so I won't elaborate here.

Then we are at 2.5 Million completely dynamic triangles per seconds - and this is beyond what current Geforce8 Hardware can do.

I presume you mean per-frame. Anyway, sorry, but a 8800 GTX can do much more than that today if you were never limited by any other part of the pipeline. So you're telling me something several years away might not even be able to beat current hardware? I'm not exactly impressed.

No it won´t. Let´s 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.

If managed to render a non-preprocessed 1B triangles model in the first place, in real-time, aliasing would kill you. You'd need a ridiculous amount of supersampling to get results that look better than simply using fewer trriangles...

Also, I am willing to bet I could get better performance than 1-2 FPS on a 8800 GTX if I used smarter algorithms, including killing triangles not hitting any sample in the geometry shader and minimizing the amount of attribute fetches required...

Ever tried rendering a car´s headlight?

Nope, but fair enough point. I remain unconvinced smarter rasterization tricks couldn't solve this problem though (nAo/Deano aka Hack Masters, any idea? :smile

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 can´t be solved unless you do undersampling. With raytracing you shade exactly one fragment per pixel, that´s it.

No offense, but if you can't get it to run faster with Early Z, then you are either doing something wrong, or you're triangle setup/vertex shader/attribute fetch/whatever-limited. Trust me, it IS a very effective technique in real games with workloads nearer those GPU IHVs are optimizing for...

Just show me a fast software rasterizer. I have yet to see one.

I summon our local software rasterization god, Nick...

See: http://www.transgaming.com/products/swiftshader/ and http://sourceforge.net/projects/sw-shader

---------------------------------------------------------------------------------------------------------------------------------

No it won´t. Let´s 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.

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..)

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.

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).

So instead of rendering 5 Million triangles you render 10 Million triangles. Great Idea.

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.

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).

Well, I guess you did something very wrong then.

And better than with raytracing this can´t be solved unless you do undersampling. With

---------------------------------------------------------------------------------------------------------------------------------

I presume you mean per-frame. Anyway, sorry, but a 8800 GTX can do much more than that today if you were never limited by any other part of the pipeline. So you're telling me something several years away might not even be able to beat current hardware? I'm not exactly impressed.

Isn't that actually what most of the papers on ray-tracing on CPUs actually inadvertently get at? They state performance of current GPU a, state current performance of CPU b, then declare that x years and n cores later the CPU will finally be faster than GPU a. Somehow forgetting to mention or acknowledge that GPUs aren't exactly static themselves.

---------------------------------------------------------------------------------------------------------------------------------

I don't think I agree with that! See: http://forum.beyond3d.com/showpost.p...3&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/Publica...rt06_final.pdf

Oh I've definitely read the RPU paper (I even gave a presentation on it :smile, but among other more minor things, the biggest problem with the design is that it includes an entirely static, entirely non-programmable acceleration structure! That is an entirely unacceptable restriction for modern ray-tracers IMHO. "One size fits all" approaches to rendering have been systematically dropped over the past 20 years in scene management and acceleration structures, and the "state of the art" goes even further, breaking even the rather flexible GPU pipeline (see "programmable graphics" and Neoptica's work for instance).

If someone can demonstrate that pretty-much fully programmable "ray tracing" hardware can compute ray intersections significantly more efficiently, I'll certainly be excited. However assuming that we do indeed need full programmability of the scene, accelerator, etc. I'm not totally convinced that we can do orders of magnitude better than we do currently.

Already on Cell it's quite possible to pull in large chunks of the acceleration data structure well in advance of needing it (hiding memory latency), and keep the SPUs busy traversing through the structure. I'm curious then as to where people think that the "inefficiency" lies for Cell ray intersections.

Anyways I'm not bashing the RPU work, but it is far too inflexible to be compared to even GPU raytracers, let alone CPU/Cell.

It just isn´t ideal because the quality sucks and it doesn´t work with reflections anyways. For raytracing you use ray differentials and propagate them.

Derivatives are a moot point as they can be computed in exactly the same manner in rasterizers as ray tracers if desired... furthermore quad-based hardware derivatives are just fine for LOD selection.

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.

LOD anyone? Occlusion culling perhaps? If raytracing gets an acceleration structure, so does the rasterizer (speaking of "apples to pears"). Just because someone can code a crappy rasterizer but a good ray tracer doesn't make the latter better intrinsically.

Ever tried rendering a car´s headlight?

Hey, I specifically mentioned automotive visualization! :smile: Even then I think we have bigger fish to catch in real-time apps before people begin to care that the reflections/refractions in the headlight aren't correct This is independent of the argument, but eventually when we get to the point that proper headlights is the next step then raytracing may well be the way to go... *for the secondary rays*!!

Regarding hacks, ATI did something back in the first Ruby demo that involved pre-computing the ray paths through a complex set of reflections/refractions (a crystal in their case). As long as you're never *in* the object (inside a headlight?), this works pretty well. There are even easier "hacks" with headlights since your viewing angles are pretty restricted.

So instead of rendering 5 Million triangles you render 10 Million triangles. [...] And that is although my shaders tent to be very, very long (up to 1000 lines of code).

So use deferred shading... if your scene is so heavily geometrically bound it'll be a pure win. One render of the scene with a trivial shader; all of the heavy lifting can be done in screen space with zero overdraw.

(ok, our usual scene size is about 15 million triangles).

For the love of god use LOD!!

And better than with raytracing this can´t be solved unless you do undersampling. With raytracing you shade exactly one fragment per pixel, that´s it.

DEFERRED SHADING - look it up. You shade once per pixel and if you're clever you can also decouple lighting and geometry complexity, something which you should already be doing (even with raytracing!) if you have huge shaders!

---------------------------------------------------------------------------------------------------------------------------------

With rasterization we can independently address geometric aliasing, texture aliasing and shading aliasing. With RT and the method you propose geometric aliasing and shading aliasing are the same thing, which is not the case at all.

I didn´t say that at all. Geometric aliasing is the only thing that needs to be addressed with more rays. Shading and texture aliasing can be solved with different approaches (ray differentials, clever shader programming).

Dunno if your numbers are accurate or not, but 250k dynamic triangles per frame are nothing. I recently worked on a PS3 game that pushes over a milion dynamic triangles per frame

So please let´s define dynamic: Dynamic for the raytracer means: you can move around 250k triangles per second with each triangle having its own transformation matrix. So a PS3 can do this? I am impressed, a Geforce8 can´t do this. It starts to crawl when you try to do 250 state changes.
So I guess you mean structured dynamics (skinned characters for example). I already wrote something about this in my other posting. It can be done, it can be done fast, it is no problem in a game context.

What you don't get is that ppl working on games and movies don't give a damn about being 'correct'. They fake everything, EVERYTHING, all the time.

Yes....I guess that´s why even Pixar finally switched to using raytracing in cars - just because rasterization can´t do the things they wanted.

One day we will have machines so powerful that we could get extremely complex scenes to run in realtime with all sort of 'correct' (not really..) effects computed with RT.
Too bad your friend next door will run a scene a thousand times more complex than yours with a mixture of techniques.

I agree with that. You can easily use rasterization techniques with raytracing. Most offline rendering people use shadowmaps since they are faster than raytraced shadows and use raytracing for the stuff that doesn´t work with rasterization.

Have you ever heard about z-pre-passes, deferred renderers, tile based deferred renderers, etc..?
I mean..ppl have been using z pre passes for AGES now, and this stuff is so effective just cause rasterizers are so blazing fast that we can render our scene two times per frame, no matter how complex it is, just for the sake of filling the depth buffer (and its on-chip compressed representations..) and almost completely eliminate overdraw while we are shading pixels for real.

No, people start to get to the point where they become vertex limited in some applications (not games though). And that makes rendering the whole geometry twice not really an option.

You know that not one of these 128 processors is involved in rasterizing the image, do you?

Well, it depends on what you consider to be part of the rasterizer. Transforming each vertex with the Modelviewprojection matrix for each frame is done by these processors, a step that is not necessary with raytracing. Also clipping is not necessary with a raytracer but must be done with a rasterizer.
Shure, the simple rasterization is not the problem but this is just as difficult as finding the correct worldspace position for a ray once you have your ray parameter.

Your next gen hardware ray tracer to be competitive with your next gen GPU will need not only to be able to compute some dozen bilion ray inteserctions per frame, but it will also need to compete with a GPU at shading an image.

Don´t know why you think you need billions of rays, So, when you look at the current intel raytracer more than 150 million rays per second can be done on a current 8 Core machine. So a 1280x1024 resolution with 4 samples per pixels is a reality now. Daniel Pohl showed Quake4 raytraced lately (including dynamic characters) and it was running with about 100fps at a (if I remember correctly) 1024x768 resolution including sharp shadows and reflections.
The shading is simply a matter on how good a programmer is and especially how good the artists are.

PPL have been saying this for ages on this board, future = use RT where it makes more sense, for the rest we have rasterization.
What I can't make any sense of is the "rasterization is doomed, real time raytracing is coming" mantra, cause it's laughable at best.

First of all, I haven´t said rasterization is doomed. I just think the article is very biased against raytracing without considering current state of the art techniques.

In the virtual reality industry the move away from rasterization has already begun. But then, people don´t have a problem with having to use a cluster with 32 or more PCs to get interactive raytracing with good performance just because they need the quality there.
For games it will surely take quite some time until raytracing will replace rasterization (my guess is around 2015).

---------------------------------------------------------------------------------------------------------------------------------

Well, it depends on what you consider to be part of the rasterizer.

The rasterizer is effectively just a scatter unit that generates fragments from input (homogeneous) vertices. That's it.

Transforming each vertex with the Modelviewprojection matrix for each frame is done by these processors, a step that is not necessary with raytracing. Also clipping is not necessary with a raytracer but must be done with a rasterizer.

Don't fool yourself, you're still doing the same work except that you're doing the intersection test for *every ray* instead of every triangle.

So a 1280x1024 resolution with 4 samples per pixels is a reality now. Daniel Pohl showed Quake4 raytraced lately (including dynamic characters) and it was running with about 100fps at a (if I remember correctly) 1024x768 resolution including sharp shadows and reflections.

With an equivalent amount of GPU hardware I guarantee that I could produce better results than that. Bring on the 8k by 8k+ shadow/cube maps! Hell I could even GPU raytrace the reflections if you want. Let's all switch to GPUs for rendering :smile:

In the virtual reality industry the move away from rasterization has already begun. But then, people don´t have a problem with having to use a cluster with 32 or more PCs to get interactive raytracing with good performance just because they need the quality there.

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.

So to summarize:
- only raytrace when you absolutely have to!
- for coherent rays I doubt raytracing will ever be faster
- it's unclear to me that CPUs are the most efficient raytracers

---------------------------------------------------------------------------------------------------------------------------------

I didn´t say that at all. Geometric aliasing is the only thing that needs to be addressed with more rays. Shading and texture aliasing can be solved with different approaches (ray differentials, clever shader programming).

I know you didn't say that, but I'm telling you that your way to do AA with RT CAN'Ttell the difference between geometric aliasing and shading introduced by shading.

So please let´s define dynamic: Dynamic for the raytracer means: you can move around 250k triangles per second with each triangle having its own transformation matrix. So a PS3 can do this? I am impressed, a Geforce8 can´t do this. It starts to crawl when you try to do 250 state changes.

1) I'm really curious to know why you need to transform 250k triangles, each with a completely different transform. Any real world application?
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. More I talk to you more I have the feeling you have been living in a universe where ppl are stuck with first gen 3dfx graphics cards.

Yes....I guess that´s why even Pixar finally switched to using raytracing in cars - just because rasterization can´t do the things they wanted.

So what? it still doesn't change the fact that no one employs RT across the board. You use it when you need it.

No, people start to get to the point where they become vertex limited in some applications (not games though). And that makes rendering the whole geometry twice not really an option.

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.

Don´t know why you think you need billions of rays, So, when you look at the current intel raytracer more than 150 million rays per second can be done on a current 8 Core machine. So a 1280x1024 resolution with 4 samples per pixels is a reality now.
Daniel Pohl showed Quake4 raytraced lately (including dynamic characters) and it was running with about 100fps at a (if I remember correctly) 1024x768 resolution including sharp shadows and reflections.

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?
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? 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.

First of all, I haven´t said rasterization is doomed. I just think the article is very biased against raytracing without considering current state of the art techniques.

The article is very well written, fair and balanced.

In the virtual reality industry the move away from rasterization has already begun. But then, people don´t have a problem with having to use a cluster with 32 or more PCs to get interactive raytracing with good performance just because they need the quality there.
For games it will surely take quite some time until raytracing will replace rasterization (my guess is around 2015).

No offense but maybe ppl in virtual reality industry are not exactly pushing the hw the way it's mean to be used.

---------------------------------------------------------------------------------------------------------------------------------

With raytracing on the other hand, each pixel is shaded exactly once causing zero overdraw.

You can use deferred shading regardless of whether you use raytracing or not. Hell, tracing a single ray is just rasterization with a really small frustum.

They still both have to do many extra intersection tests per pixel of course, raytracing will generally have to do less (not necessarily, since the traversal of the acceleration structure might also require them) and rasterization will generally be able to do them faster because of coherency and the greater opportunity for parallelism.

Finally, comparing current GPU-Rasterization with current CPU-Raytracing is like comparing apples with pears.

So, compare CPU raytracing to CPU rasterization instead. There is no reason to assume raytracing would get a bigger boost from specialized hardware. This battle has been fought and lost by raytracing for decades before the GPU came around.

In the end it will win, for now it will not.

---------------------------------------------------------------------------------------------------------------------------------

Regarding AA and Raytracing...

Many, many moons ago, I wrote a Amantides-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.

Thats very interesting, Thanks for the info Simon. I really couldn't find much info on Cone or Beam tracing and haven't never really written one (well I written a beam primary tracer for off line occulusion reasons but never worried about performance) its interesting that it wasn't that more expensive...

I wonder if the Quake4 RT could be changed to a cone tracer to help the AA problem...

---------------------------------------------------------------------------------------------------------------------------------

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.

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.

---------------------------------------------------------------------------------------------------------------------------------

Talking about ray tracing and AA.. what about beam tracing? :smile:

A Real-time Beam Tracer with Application to Exact Soft Shadows

---------------------------------------------------------------------------------------------------------------------------------

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.

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.

1) I'm really curious to know why you need to transform 250k triangles, each with a completely different transform. Any real world application?

Of course not. But no one would rebuild a whole acceleration structure for raytracing each frame either.

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.

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.

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?

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 didn´t say you should use raytracing for everything (at least not yet).

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?

One! http://www.tml.tkk.fi/~samuli/public...hics_paper.pdf

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.

Of course not. It does make sense for may thing though.

No offense but maybe ppl in virtual reality industry are not exactly pushing the hw the way it's mean to be used.

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 don´t have that controll. The people just throw their bunch of triangles at it an you need to work with that.

---------------------------------------------------------------------------------------------------------------------------------

The article is very well written, fair and balanced.

Yeah, a lot of the things people seem to be bugged about seem to be not being able to separate certain principles from the reality. I mean, we can use hierarchies that are quicker to locally update than kd-trees and use it for more broad-phase culling and theoretically make an argument against the "moving scenes" statement, but then you lose ground in the scene complexity scaling argument... You can argue that the human eye is too slow to catch more than 30 fps or 12 fps, but you can't say that of the human brain's visual processing rate. You can say things about GI, but then nobody is comparing realtime MCPT to rasterization. One thing that people seem to forget is that it's raytracing that is part of (most) GI solutions, not the other way around. Quake3 RT and all the other demos that Intel have been showing is not GI, it's regular Whitted raytracing, and that's not the holy grail.

The OpenRT guys have been demonstrating things which reach a little farther, particularly with area lights and soft shadows and maybe 1 or 2 bounce GI approximations, but the only things they have the capacity to demo in realtime with dynamic scenes is still on the same level as the raytraced Quake demos. They're at least trying for what should be considered more of a holy grail than just straight Whitted raytracing... but whether we'll have the hardware to get there... I don't see it happening anytime soon, and it will surely take you down a path that just makes the uncanny valley look more like a bottomless pit, especially since we'll still be dreaming up more hacks along the way.

---------------------------------------------------------------------------------------------------------------------------------

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.

Interesting, because it generates pixel-accurate results with both OpenGL and offline raytracers I suspect this is more inexplicable raytracing dogma and one-upsmanship.

Computing correct ray intersections is trivially verifiable, and any raytracer that doesn't do that properly is just *wrong*. Ray tracers can thus be compared only on speed, and I think there you'll find the RTT raytracer quite competitive if not clearly ahead of the pack.

Of course not. But no one would rebuild a whole acceleration structure for raytracing each frame either.

As you've noticed, the argument is clearly circular. There are no theoretical complexity benefits to either raytracing or rasterization, although in practice rasterization is faster for dynamic content as it does not need to break things down to the ~dozen polygon level to remain efficient.

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 didn´t say you should use raytracing for everything (at least not yet).

I think the point he was making is that that demo was weak to say the least, and showed very little that couldn't be done with better quality and efficiency using rasterization. It also showed *nothing* that couldn't be done *much* better with a hybrid system.

One! http://www.tml.tkk.fi/~samuli/public...hics_paper.pdf

Uhh:

All renderings were made using 256 samples on the light source

Furthermore you need more rays/samples than one in general to solve visibility/shadows. I sketched rather trivial argument to this end in my GPU Gems 3 chapter. You can do okay in some cases with a few samples, but it easy to construct scenes that require more.

The method also seems to take 10 seconds to render a scene with 16k polygons. I can render thousands of huge shadow maps in that amount of time and thereby achieve superior quality just by brute force rasterization! So while the method may be interesting in its own right, I hardly see how it compares favorably to current real-time techniques.

---------------------------------------------------------------------------------------------------------------------------------

You can use deferred shading regardless of whether you use raytracing or not. Hell, tracing a single ray is just rasterization with a really small frustum.

They still both have to do many extra intersection tests per pixel of course, raytracing will generally have to do less (not necessarily, since the traversal of the acceleration structure might also require them) and rasterization will generally be able to do them faster because of coherency and the greater opportunity for parallelism.

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 heard rumors that opticore tested their raytracing on a large cluster and they reached the limit at 500 CPUs or so....

So, compare CPU raytracing to CPU rasterization instead. There is no reason to assume raytracing would get a bigger boost from specialized hardware. This battle has been fought and lost by raytracing for decades before the GPU came around.

It has been fought before things like coherent raytracing, SIMD utilization and packet traversal were used.

In the end it will win, for now it will not.

I agree with that. It is still a long way but it won´t be too far away (within the next 10 years I assume).

 

[AlNom]

Page 3 remnants:

I'm not sure I agree with that sentiment.

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.

CaseMillennium, you suffer from the same problem as all the other ray-tracing proponents. In all your comparisons, you gimp the rasterizer with 1980 technology.

Rasterization has another problem that gets more and more important as shaders get more and more complex: It suffers from massive overdraw.

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.

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 don´t 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 won´t be very large for normal scenes and therefore the speed impact is not too bad.

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.

Ok, first of all: I didn´t say current systems are there yet. But let´s 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.

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!

No it won´t. Let´s 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.

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.

Ever tried rendering a car´s headlight?

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.

Just show me a fast software rasterizer. I have yet to see one.

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.

Well, we all see how well parallelism works for rasterization when you have a look at SLI in SFR Mode.

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.

---------------------------------------------------------------------------------------------------------------------------------

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....

Are you joking? Have you ever been "rasterization" bottlenecked on a GPU?? You really never will be because the simple units are more than capable enough for even ridiculously high resolutions. Furthermore application-level code can easily parallelize rendering, even to a single framebuffer (Edit: Mintmaster said the same thing better!).

... before things like coherent raytracing, SIMD utilization and packet traversal were used.

aka. "lets reinvent a slower rasterizer". Seriously once you've made all of those assumptions and "optimizations", any advantages of raytracing (read: incoherent rays) are gone, and indeed you're *still* slower than rasterizing.

---------------------------------------------------------------------------------------------------------------------------------

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....

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.

It has been fought before things like coherent raytracing, SIMD utilization and packet traversal were used.

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.

---------------------------------------------------------------------------------------------------------------------------------

Anyways, Crysis and several other modern games look pretty good IMHO although of course they can be improved. Graphics will continue to improve and raytracing may play a role in that eventually, but it does nothing to improve "blocky, lifeless, crappy graphics" so you may want to look elsewhere for that. Of particular interest to the poster is that most movies use primarily rasterization, so does that mean that they also look "blocky, lifeless and crappy"? Indeed not as where the two techniques are both applicable they will give identical results and the only difference will be in speed, where rasterization wins pretty-much exclusively.

Ignored a few posts that were OT.

 

[AlNom]

Someone wanna buy me a new keyboard please?

Here's the remains of Page 4:

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 raytracing?

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.

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?

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.

---------------------------------------------------------------------------------------------------------------------------------

... 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.

Which is cool, I'm glad you did :smile: 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.

---------------------------------------------------------------------------------------------------------------------------------

aaaaah i must study, but instead i'm posting about raytracing...

your claim was that rasterisation can't do GI and ray tracing can, is just an equally over stated statement.

really, you can't solve the rendering equation ("do gi") efficiently by drawing triangles. (i say "efficiently" in the same way as i said it earlier: it is technically possible if you're going to render the scene for each visibility query, but that's of course obscenely inefficient.)

if you have a solution to the rendering equation employing rasterisation, be sure to publish!

The point I was making in the article and here is that when it comes to GI neither method has an advantage or disadvantage over the other.

i believe that's just not correct. incoherent visibility queries are not handled well by triangle rasterisation, it's an algorithm founded on coherence. that's why it's so much faster for doing most things.

Its meant to be a counter-point to the articles claiming ray tracing will take over rasterisation, something that many people agree with. I'm sure Beyond3D would be happy to host an article by yourself with the counter argument.

there's not much to say: there are very simple things (reflection and refraction) one needs in rendering, which can't be achieved by rasterising triangles. for this reason alone, even ignoring the other benefits (fast+robust shadows), it's just a matter of time.

Convince me of why ray tracing will take over and rasterisors are doomed, I'm open minded enough that show me a convincing reason I'll change my mind. But so far the argument seems to be largely, ray tracing has better lighting and scale better for large scene, which so far I haven't seen ANY evidence for...

that isn't the argument, and we both know the thing about scaling is largely equal - both algorithms need spatial subdivision. the argument for better lighting only comes in much later when we're doing distributed ray tracing (glossy reflections, soft shadows, real depth of field).

the single reason why ray tracing will eventually be the algorithm of choice is because it can do things that rasterisation can't. an analogy can be made between newton's laws and general relativity: newton's laws work awesomely in just about every case we regularly work with, however sometimes it just can't explain things. this analogy breaks down when you see how common reflection and refraction are compared to black holes in our back yards

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?

---------------------------------------------------------------------------------------------------------------------------------

Sorry, I got distracted, I should have posted this quite a while ago... And it also turned out more technical than expected, except for the conclusion - oops! :smile:

i agree. there's been such an uproar lately, first with intel's propaganda, and now here on beyond3d; i've been reading the articles and forums here for a long time and have always been impressed by the level of technical competence, but this article has really done ray tracing researchers a disservice by ignoring some of the most important recent advances, and in a really biased way.

I think the problem is that neither side (of the technical debate) understands the other is more moderate than it really is. What you seem to be arguing is that raytracing will eventually become much more widely used, but that it won't happen for several more years. That really isn't that different from what we are saying.

It's obvious that algorithmic innovations will happen (and have happened, as you pointed out) and that hardware will keep getting faster. The implicit disagreement we have is on the timeframes, and whether the 1% of a GPU's die size directly dedicated to rasterization will be eliminated to simplify its design. The former does matter but honestly, the latter simply doesn't. That's an implementation detail (whether you want to raytrace or rasterize primary rays once you have 10+ rays per pixel anyway) and it isn't worth making it the centerpiece of the debate, IMO.

Anyway, let's consider the 'hardware will keep getting faster' point more rigorously. Let's consider Intel's position to simplify the arguement; they are entering the 45nm era today. Assuming we stick to 2 years/Moore's Law cycle, we'll have 32x 45nm's transistor density in 10 years, in theory. There are problems with that assumption:
- Process scaling really isn't 0.5x nowadays. For logic, 0.55x-0.60x might even be too aggressive going forward, but let's use that for the sake of arguement: that gives us 16x rather than 32x the transistor count in 10 years.
- Costs per mm2 are going up, not down. Furthermore, megahertz scaling is much less effective today than it was in the past, with power becoming such a problem.
- Nobody has a good idea how to keep Moore's Law going beyond 16nm, especially if continuing to scale perf/watt is necessary.

So really, performance scaling in 10 years might be anything between 10x and 50x. Or it might be even lower than that (but then I suspect the entire industry is pretty much doomed, oops!) or much higher (which could only happen with a key technological breakthrough, surpassing Moore's Law). Even 50x (which, I believe, is a fair bit less than what we had in the last 10 years for GPUs) is incredibly aggressive, and would require key breakthroughs to achieve.

The 'model' I am basing most of my predictions on is about 20x today's computing performance in 10 years for a given manufacturing cost (after taking inflation into account). However, I can see a number of technologies on the horizon (including silicon photonics) that might make bandwidth scale better than that for once. So overall performance might be higher than that, and some algorithms might benefit more from certain dynamics than others.

---

So, why did I explain this in detail? Because I think it's important to put hard numbers on the performance improvements we can expect, otherwise saying that the added cost of an algorithm (in this case, raytracing) will be negligible makes no sense. We can all agree that within 1000 years, unless we all die and reptiles take over the world, tracing will completely replace rasterization. But that's not the point.

The point is whether raytracing will become more important than rasterization within 5, 10 or 15 years. And my (personal) answer to that is extremely clear: no. I am sure that unless Moore's Law dies sooner than expected, raytracing will start to get used for certain rendering effects within 10-15 years. But unless my estimation of 20x higher performance within 10 years is too pessimistic, I really don't see why I should believe raytracing will 'takeover' within that timeframe. It makes absolutely no sense in my mind.

Perhaps it makes more sense to consider how much more computational performance we need for raytracing to make sense, rather than speak in terms of years. No matter what, however, Intel's claims are ridiculous at best. Larrabee will come out within 2 years, and the last iteration based on that architecture might come out 5 years from now or so, I'd presume.

Raytracing will, IMO, be completely (or at least mostly) irrelevant for rendering in that timeframe. What many of us ponder is whether Intel is realizing that. The Havok acquisition does make me think they are, but I do suspect that some of the top-level decisions are being made without proper understanding of the dynamics at play. At this rate, we'll have to convert Beyond3D into an Executive Education website - although at least, that business model would work a bit better than the current one, heh!

lycium: Okay, cya - feel free to reply tommorow or in a couple of days, this doesn't have to be a real-time discussion! :smile:

---------------------------------------------------------------------------------------------------------------------------------

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 raytracing, 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?

Good luck with your studying, I can't speak for the Beyond3D (i'm just a guest :smile: ) but i'm personally interested into your insights into real time raytracing so any article, at any time I'd find intersting.

Again good luck! :smile:

---------------------------------------------------------------------------------------------------------------------------------

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...

---------------------------------------------------------------------------------------------------------------------------------

A Real-time Beam Tracer with Application to Exact Soft Shadows

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 ... plus with the huge poly's of the time and the boxes connected by tunnel design of levels PVSs were pretty much impossible to beat.

---------------------------------------------------------------------------------------------------------------------------------

The method also seems to take 10 seconds to render a scene with 16k polygons. I can render thousands of huge shadow maps in that amount of time and thereby achieve superior quality just by brute force rasterization! So while the method may be interesting in its own right, I hardly see how it compares favorably to current real-time techniques.

Sorry, was the wrong paper: http://www.cs.utah.edu/~bes/papers/coneShadow/shadow.ps

And yes, I know this isn´t a general solution but this isn´t the point. No rasterization technique for soft shadows I´ve seen so far is general as well. But if the rasterization people fake (LODs, Cubemaps etc...) so the raytracing people can.

For the Performance issues stated in other postings considering VR People not using the hardware as it is supposed to:

I think most game developers don´t realize that they are living in a perfect world: The models they get are perfect. They are closed, they are manifold in 99% of all cases and they have perfect texture coordinates and artists that are willing to tweak the models.
In VR you don´t have any of this. You have bad tesselated models, sometimes with overlapping triangles, no texture coordinates and no artist that is willing to spend time in preparing the model.

Just to give you an impression: The timeframe we are working on is one week. In one week we need to take a model, convert it from CAD to triangles (giving us about 35 million triangles), remove unecessary parts, apply textures and shaders for a whole bunch of different configurations and make it look as good as possible, photorealistic if achieveable.

I know, 15 million triangles is not much for a G80 (runs with about 50fps here as well) but then start to add shaders that don´t require any texture coordinates (which in many cases means you need to have procedural textures) and consider all possible lightsources OpenGL has on a per pixel basis and don´t suffer from moire effects (antialiasing procedural textures is a real fun) and still look god when you have a very close viewing distance. Or in other words: The shaders we use have about 1000 lines of code and don´t even compile on ATI hardware anymore (which doesn´t really matter since no one is using ATI in this industry anyway). Even 20% overdraw has a serious impact on performance.

Maybe I should give the z-first pass another chance, It has been quite some time when I last tested it, maybe it helps now.

About deferred shading: I thought about it a lot, maybe someone here can give me a solution: How does one handle different shaders? I mean, the world isn´t all phong. I am talking about > 100 pretty complex procedural shaders ( so putting them all into one big shader doesn´t work due to the instruction limit) with many textures (3 textures per shader minimum (diffuse, specular, bump, noise, 3 envmaps) that have pretty much nothing in common. If someone has a solution for this, I would be really glad to here it.

So in my opinion I have yet to see a game that really stresses the hardware as much as we do. I also have yet to see a game where I would say: "Woa, this looks great!". My hopes are with crysis and before that with Bioshock, but after seeing the Bioshock in real I was a littlebit disapointed (mainly because the artists did some serious bad work with the materials so it again often looked like plastic) - although it is a great game.

But I am drifting offtopic.

---------------------------------------------------------------------------------------------------------------------------------

But I am drifting offtopic.

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.

---------------------------------------------------------------------------------------------------------------------------------

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.

Ps - from a consumer standpoint watching game budgets balloon, the idea that RayTracing/GI could offer a robust, but simple solution to lighting and shadowing which is very artist-controlled and may cut down on a lot of complexity we are seeing in games is interesting. Instead of 16 texture layers per object, dozens of shader hacks to immitate certain results and worse case scenarios, and complicated multipass rendering solutions with a half dozen various buffers, a muchn simpler/elegant solution that puts more power in the artist's hands is great in theory. Seriously, how many developers can truly afford to design such complex rendering solutions? We have already heard from a number of developers that rewriting their renderer to support tiling isn't difficult, they just don't have the time. The angle that a Raytracing solution could offer more artistic input and less renderer complexity is an interesting one to explore. Maybe the GPU guys can comment on this: is Rasterizing getting too complex that there is becoming increasing disparity between those who "can" and those who "cannot"? Where does the design difficulty/complexity questions fit into the broader issue?

---------------------------------------------------------------------------------------------------------------------------------

Part of what's going on here, of course, is that Intel has a solution and is looking for a problem to apply it to. :smile: I'm hoping against hope that they are focusing in their messaging so much on the RT side because they see it as a competitive advantage for them, rather than they really intend to rely on it exclusively. But we'll see.

---------------------------------------------------------------------------------------------------------------------------------

A.) GPUs will offer realtime "CGI quality" results (albeit dated, lets say A Bug's Life, Toy Story 2, etc)

Considering that only Bug's Life has used raytracing and only in the scenes with the glass jar full of nuts, and the lighting was based on lots of simple lights and shadow maps, so no GI there either, we can theoretically render any scene from those movies on current GPUs.

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.

I'd also add that Team Fortress 2 is very, very close to those old Pixar movies, partially due to the art direction.

---------------------------------------------------------------------------------------------------------------------------------

I have a great idea for optimizing ray-tracing: Instead of intersecting rays to triangles, why don't we intersect triangles to rays? If the rays can be arranged in a orthogonal grid of some sort, it becomes very easy to resolve the intersection test...

That's crazy talk.

---------------------------------------------------------------------------------------------------------------------------------

Part of what's going on here, of course, is that Intel has a solution and is looking for a problem to apply it to. :smile: I'm hoping against hope that they are focusing in their messaging so much on the RT side because they see it as a competitive advantage for them, rather than they really intend to rely on it exclusively.

Well, from Intels point of view it is pretty clear: They want to sell multiprocessor machines. And Raytracing is one problem that is embarrisingly parallel.

If you want to take things to a limit, you will have one processor per pixel which would make every solution to the GI problem and so on very simple (you could shoot millions of rays per pixel then). That´s not the case with rasterizers. 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. So the triangle transformed by one processor might fill the same pixels as a triangle transformed by another processor which means you will need synchronisation between them which makes rasterization scale worse than raytracing.

Of course this is a littlebit utopic but I think it makes the reason clear why Intel is pushing raytracing: They want to tell everybody that having 2 processors will double your performance and having 10 processors you will have 10 times the speed. And as we see, this is roughly true with raytracing (although building an acceleration structure doesn´t work so parallel - at least I am currently stuck with a factor of 5 when using 8 cores, but that is probably just me).

---------------------------------------------------------------------------------------------------------------------------------

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?

---------------------------------------------------------------------------------------------------------------------------------

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.

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.

 

[AlNom]

Ok folks, that's all I could find. Um.... happy search-reading?

 

[Geo]

Thanks for your efforts, AlS. You da bomb!

 

[rwolf]

What an interesting article. Certainly has some excellent arguments.

 

[hoho]

I have some posts sent to my e-mail that are not listed here. I wonder how could they be merged to their correct places. If I just dump them here their order will be quite bad. It would be really nice if they would go to their correct places inbetween the posts AlStrong put here.


From the first count I have around 13 posts from the first and >10 from third page that are not here. In total I have 50 posts but many are already listed.

 

[Geo]

Put them here grouped by page and we'll at least move them to the right post above.

 

[hoho]

Problem is I have no ideas where do the pages start and end

I'll simply put them all in the order I have them in my inbox. That will mean many will be duplicates of what are already posted and lots of them will be missing but still better than nothing. It'll take a while to massage all these 50 posts to nice format so I have no ideas when I have them done.

 

[Geo]

Maybe just email it to me instead. geo at you-know-where.

 

[hoho]

Maybe just email it to me instead. geo at you-know-where.

I tried to massage it into a format I could simply copy-paste to forum but somehow it didn't work and forum displayed it as plaintext. If anyone sees the mistake just let me know so Geo won't have to manually change those 50 posts

The text is here together with the parser: http://hoho.bafsoft.net/rt-b3d/

 

[Geo]

http://arstechnica.com/journals/hardware.ars/2007/10/22/real-time-ray-tracing-the-gpu-and-gpgpu

Ars weighs in, in part in response to Deano's article.

Is it just me or is he basically saying RT = GPGPU there?

And, Gee, Jon, that "loyal" comment stung. Why didn't you formulate it correctly and just say, "Beyond3D is loyal to the GPU, unlike right thinking folks like myself who are loyal to the CPU". We wouldn't call you an Intel fanboy! (well, at least I wouldn't).

Edit: This new Intel article is linked in the Ars piece as well: http://blogs.intel.com/research/2007/10/more_on_the_future_of_raytraci.html If I'm not mistaken (and I may be), it basically says at the macro level that Deano's article is correct and a hybrid solution is the real way forward. Doesn't it? If so, nice to see Intel admit it.

 

[3dilettante]

Jon didn't say much about the article on B3D.

It's little more than a one-off chance to segue into a shot at B3D's supposed collective stance on GPGPU (which he then says he won't get into).

The concerns stated about raytracing are not really addressed, and the implication is instead made that: "B3D likes GPGPU, so the concerns about ray tracing by someone with an intimate knowledge of graphics rendering must be informed by a GPGPU bias".

The implication is that B3D lacks the sophistication to differentiate between a debate on graphics rendering and the more varied GPGPU question.

While I am partial to his position that Larrabee has potential to seriously challenge and possibly trump GPUs in much of scientific computing, I do not like the way his argumentation turned out.

I'll chalk it up to the number of separate ideas he lumped into a few paragraphs. The way that blog post was structured, the theme was a somewhat indistinct mash of several possibly different and subtly interrelated ideas that can lead to excessive interpretation.

Though I do read a little bit of the shot there at B3D for not converting so readily to the future Larrabee, and instead hewing to the known quantities of current GPU and CPU designs which currently have more of substance behind them.

Methinks Jon protests too much for the sake of Larrabee, if only because Larrabee's supposed true proponents at Intel have a mixed history of making a cogent defense themselves.

 

[Tim Murray]

Is it just me or is he basically saying RT = GPGPU there?

Yes, which is silly. Look what Mike Houston has to say about the Intel article, and Mike Houston definitely knows more about GPGPU than Jon or me. I still don't know why Jon thinks Larrabee will be immune to the biggest problems of GPGPU, unless you're talking about data structures or something. But then Mike is completely correct--you're going to get into trouble with locking and all that.

Also, Jon seems to think that what is available in CUDA or Brook right now is it as far as your GPGPU programming model can go, and I'm pretty sure that's rubbish.

Basically, I don't like Jon's argument about Larrabee because I can think of three ways it could be so much better than GPGPU to justify this excitement, and none of them are remotely likely. One, it could simply be that much faster. I don't think that's completely out of the question, although I seriously doubt its likelihood. Two, it somehow solves the CPU/GPU synchronization barrier. Unless each core is somewhat close to your Nehalem's cores or whatever, I have my doubts there. Maybe you're closer to an MIMD machine so you can avoid some things on the GPU that you would otherwise do on the CPU, but you're certainly not going to solve the problem. Three, you get data structures without ridiculous overhead. Three would change everything, but I think the chances of that happening are zero.

 

[Geo]

It's little more than a one-off chance to segue into a shot at B3D's supposed collective stance on GPGPU (which he then says he won't get into).

I think what Ars, and probably Intel, are missing about pieces like Deano's and our (B3D's) position on Intel and ray-tracing in general, is that we all want Intel to succeed and be a viable competitor and provider of high-end graphics solutions. All this critiquing isn't coming from a "hope they crash and burn" place. It's coming from a "listen to the voice of experience, new guy" place.

If anything I was fairly relieved to read the new Intel research piece he pointed out, as it's much less aggressively "all RT all the time" than previous Intel messaging on the subject.

 

[Mintmaster]

http://arstechnica.com/journals/hardware.ars/2007/10/22/real-time-ray-tracing-the-gpu-and-gpgpu

Ars weighs in, in part in response to Deano's article.

Is it just me or is he basically saying RT = GPGPU there?

That was a rather useless article.

Not only did he equate RT to GPGPU, as you said, but has no idea what the fundamental argument is here. It's not about Intel vs. GPGPU, it's about raytracing versus rasterization, and an 80 core CPU in 2010 trying to compete with a fraction of the die space of a GPU from, say, 2005.

When people from NVidia are talking about using GPUs for raytracing, they are trying to create a new market for their products. It has nothing to do with them thinking raytracing is better than rasterization.

 

[Tim Murray]

When people from NVidia are talking about using GPUs for raytracing, they are trying to create a new market for their products. It has nothing to do with them thinking raytracing is better than rasterization.

Well, I don't think anyone's said that raytracing has absolutely no place at all in rendering. And it's also true that what you'd need to do raytracing better on a GPU are many of the same things that would make GPGPU better.

But, the main points of the Intel article on the problems with GPGPU are, IMO, fairly ridiculous. I can't really imagine Intel waving their hands and "solving" the parallel data structures problem. Not that it would matter that much; unless you can keep the entirety of the data structure in some sort of cache or you can have a bajillion threads in flight at the same time, your latency from accessing pointers and such would be so great that your performance would tank anyway. And CUDA will get better, CAL will hopefully be reasonable (I haven't seen anything yet, but I'm hopeful that they'll do something good), Intel will have their own things, Brook will continue to improve (and maybe NV will open up their platform--I'd like to see that, too).

Intel is arguing that GPGPU isn't some magic bullet, but nobody said it's anything but an accelerator. Jon seems to be arguing against its use as a magic bullet as well and then dragging raytracing into the mix (which, having looked at his Larrabee article again, he doesn't understand). I have nothing but respect for him when it comes to CPUs and general architecture stuff, but I don't think he really gets the software side of massively parallel programming. I mean, we're basically talking about extremely active research topics in CS...

 

[Dee.cz]

Hello, one sentence in article conclusion could be already obsoleted today, viable realtime global illumination framework exists,

http://forum.beyond3d.com/showthread.php?t=44941

 

[ShootMyMonkey]

Hello, one sentence in article conclusion could be already obsoleted today, viable realtime global illumination framework exists

Except for the fact that it doesn't. Note the bolded part.

All the so-called realtime global illumination methods are just too limited to be of any use in practice in actual games. They work in confined spaces with few lights (typically short-range local lights), small scenes of relatively few elements, scale poorly with scene complexity (particularly when number of dynamic objects grows), rely heavily on a priori knowledge (whether by precomputation or hand-placed markups), and without exception, have failure cases which are all too common in real world usage.

There are plenty of tricks out there we all use to get GI-ish effects in realtime, and they work beautifully for the limited range of cases that they're capable of solving. Step outside of that just a little bit, and all bets are off.