154 replies to this topic

[Altair]

davepermen said:

altair, what does saarcor miss in terms of rendering quality?

Shaders, flexibility and performance are the first ones that come into mind.

[davepermen]

performance has nothing to do with rendering quality, and given the hw constraints, the performance is great (and if you have brain you should finally understand that).

shaders will have the same performance as on a rastericer gpu (as it essencially has the exact same hw logic).

flexibility. rastericers don't have much flexibility as well. they can rasterice triangles, lines and points onto rectangular buffers, sample textures, and have two places with shaders.

the raytracer can raytrace triangles onto rectangular buffers, sample textures, and will soon have one place with shaders. so where's the big difference ?

oh, and it works great together with opengl btw..

[Altair]

davepermen said:

performance has nothing to do with rendering quality

You are wrong right there boy. It's kinda ironic you claim otherwise now, when you were all for scalability yesterday :rolleyes: When you don't have performance you have to cut in quality.

davepermen said:

shaders will have the same performance as on a rastericer gpu (as it essencially has the exact same hw logic).

I guess you don't understand what coherency means and what it has to do with performance of shaders. This discussion doesn't get anywhere until you are able to understand that and frankly, I find continuing this discussion pretty much waste of time now that Goz is gone with his beta deadline :glare:

davepermen said:

flexibility. rastericers don't have much flexibility as well. they can rasterice triangles, lines and points onto rectangular buffers, sample textures, and have two places with shaders.

That's naive thinking. Rasterizers abstract only the most low level part of the rendering, while they leave more complex, non-trivial algorithms to fully programmable CPU. Raytracers restrict the rendering in much higher non-trivial level and one huge restriction because of this in raytracers is that they require scene capturing.

davepermen said:

oh, and it works great together with opengl btw..

I'm sure you got loads of experience of that to back up that comment like everything else you have stated as matter of fact.</sarcasm>

[sumedhs]

Wow, that was quite a discussion!
I want to get this topic back to The Next BIG Thingy in Real-Time Graphics but before that, just a passing thought to the two friends.
Altair..."Wrong and right" reply for "performance has nothing to do with rendering quality" is perfect as the two factors will still decide how the chip is (sells) as a whole. Also Daveperman... I dont think the discussion here is about if SaarCOR is good. Its hardware that does real rime ray tracing!! it will obviously be a better overall performer (if implemented well) than software counterparts. I think what Altair wants to argue is that if its good enough. Good enough for the time & money that will need to be invested for the development of this. Am I correct?

Well anyways. Coming back to The Next BIG Thingy in Real-Time Graphics I am surprised nobody has talked anything about Volumetric Rendering. (Sorry I joined in late :D ). Lets divide the rendering in two parts One where we do the lighting, shading & effects like shadows & the other part... Modelling. Honestly guys you got to admit.. we FAKE! I mean we know that every sphere that we render is in fact not a sphere, it is a closedfaced set of 2D Polygons. We fake when we say its 3D when we know that its hollow inside. Probably the next big thing, or the next big thing to the next big thing would be when we do the modelling to that LOD that we do layers inside a primitive, think of this... there is a wall (Ah.... no not a textured rectangle) We have detailed the wall to that level that we have layer of bricks of porus material (Ya no more bump maps lets call it 3D Porus material) which is brought together with a layer of thickened cement. & BOOM there goes the rocket from the rocket launcher. The wall (made of volumetric elements) breaks into small peices. There is a real time physics engine that will compute the the impact, breaking of the group of wall elements & what the hell... it will also compute the scatter of each of the voxel. The possibilites are unimaginable!
We can even have water / blood rendered out of small voxels where a realtime Computational Fluid Dynamics engine which will compute the flow.
Ahhh... They say I like to dream :D
But I say I dream thats why I can do! :D

[davepermen]

uhm, altair.. openrt (the api for saarcor) works flawlessly with opengl together for displaying (as saarcor is only a renderer.. the display card is still an ordinary gpu for now).

but it's okay. you don't even try to think about what i state, and just state me dump instead.

[Altair]

The problem is I understand completely what you are trying to say. Sorry, but I just got a bit frustrated about going over the same thing over and over again without anything new on the table and maybe stated things in wrong tone of voice. I had no intention to claim you are stupid and I know you are very clever guy, but that you just lack experience in game development to see the whole picture. I'm truly interested about seeking potentials for raytracing HW and would like to hear that one deciding factor why raytracing would be better option of rendering, but no one has been able to show that yet (not saying there isn't such thing). Sure there is nice natural features in raytracing like refractions and reflections, but those alone are quite weak argument when facing all the potential problems there will be and if you had the experience, you would understand that. You can't simply ignore those problems. Rasterization as it is now also has its fair share of problems, but there is also potential solutions for some of them which stand on the basis of already existing architecture and which has already been proven to work "on the field".

[davepermen]

the one definite factor is, finally, the big hacking that is 99% of the todays hw and sw part of graphics (and we all get teached now good it is on nvidias and atis and even carmacks and friends sides) to get an only near to good looking image could be over. on raytracing sides, rather scalable full working solutions for everything imaginable (in newtonian space, that is.. nobody wants quantum effects in his games.. yet:D) in terms of graphics.

just look at the whole shadow issue. there is no simple 100% working, fast, and scalable solution on gpu's yet.. and gpu's are old today.. isn't that depressing?

raytracing can handle in a clean and natural manner all sort of effects in direct, and indirect illumination situations. it can handle gi well.

rasterisation has not yet proven it can. sure, it can get managed well for movies, but heck, they still render with about 20minutes per frame. thats FAR away from todays gpu's. if we look at saarcor, thats much more close:D its in the near-to-realtime speed for gigantic meshes, it can illuminate them with nice gi, and shaders are just a bit of hw that you could copy from gpu's today. the same parallelity would still exist, only coherence effects (texture cache comes to mind) would get issues.


it looks like you have no clue how far we are away from natural illuminated and rendered scenes.. its quite far. todays images look good, but to get closer to 'the solution', we have to add a lot of additional work onto the gpu (near to 1 render per pixel.. this is not scalable). they can (and do) this in scenarios for movie-renderings. accurate reflections get more or less raytraced with a rastericer for the intersections.

if you read enough about what gi involves, and start to look at the real world again, you notice how much just depends on reflections. every surface gets reflections, that change it's look. often its rather diffuse, and only a bit, but it mathers to detect what sort of material it is. brdfs are highly complex for all sort of materials, and they all need accurate input from the whole surroundings to get an accurate shading output. you can fake that more or less. but only raytracing can give the real input values for your shaders to give the correct output.

i don't see problems in raytracers. if you finally compared the hw of saarcor to the hw of a gf6 (only hw features), and do the math, then you notice that there is a hw-speed difference of a factor 50 to 90 (depending on how you do the math..).

now scale saarcor by a factor 50 in speed (raytracers scale well, you know that yet), and take the other numbers and images on www.openrt.de and you can start imagine what a saarcor with nvidia hw technology in the back-ass would be able to do.

one simple statement: the term "interactive global illumination" would not exist anymore. they could call it "realtime global illumination".

but you fail to, for one time, look at it and _CARE_ABOUT_WHAT_YOU_SEE_. (oh, you should read all the papers..).

i'm tired of saing the sam over and over again, but i got trained as i talk about it since quite long.. i feel quite lonely at my position, people are trained to believe in rasterisation and gpu's, they get trained by their jobs, by the nvidia and ati marketing, and the fact that "everyone around uses it, too..". they don't even bother to look around and 'restart thinking'.

[davepermen]

fuck that got much too long :D sorry..

i had now nearly one week no pc.. now i have a new one.. athlon 64 :D

[Melvin]

davepermen said:

the one definite factor is, finally, the big hacking that is 99% of the todays hw and sw part of graphics (and we all get teached now good it is on nvidias and atis and even carmacks and friends sides) to get an only near to good looking image could be over. on raytracing sides, rather scalable full working solutions for everything imaginable (in newtonian space, that is.. nobody wants quantum effects in his games.. yet:D) in terms of graphics.

yeah...complex effects done using rasterization are essentially approximations...granted the results may be arguably acceptable, but the effort, time and learning curve needed to get there just snowballs year after year...can this be the right way of doing things? And the novelty of eye-popping graphics will wear down year after year...and there're tons of more pressing challenges ahead - full volumetric rendering, volumetric-based physics, smarter AI, biomechanics...but I'm digressing.

Quote

just look at the whole shadow issue. there is no simple 100% working, fast, and scalable solution on gpu's yet.. and gpu's are old today.. isn't that depressing?

couldn't agree more on that...tons of elaborate tricks have been invented by enterprising folks just to do some decent shadows...deep shadow maps for translucent shadows, elaborate schemes for soft shadows(and then only just approximations), perspective shadowing mapping for antialiased shadows etc etc....then imagine having to pull all of these complicated techniques together to create an even more complicated universal shadowing scheme...and all while raytracing simply traces out completely natural shadows as it renders, quietly and efficiently....I can't imagine going into the future of 3D rendering without such ease and power.
heck, just getting something as basic as transparency right is such a drag in rasterization...with raytracing, the issue becomes elegantly moot...so too, the issue with pixel overdraw...occlusion culling is inherent!

Quote

raytracing can handle in a clean and natural manner all sort of effects in direct, and indirect illumination situations. it can handle gi well.

yep...GI is its mainstay alright.

Quote

rasterisation has not yet proven it can. sure, it can get managed well for movies, but heck, they still render with about 20minutes per frame. thats FAR away from todays gpu's. if we look at saarcor, thats much more close:D its in the near-to-realtime speed for gigantic meshes, it can illuminate them with nice gi, and shaders are just a bit of hw that you could copy from gpu's today. the same parallelity would still exist, only coherence effects (texture cache comes to mind) would get issues.

it looks like you have no clue how far we are away from natural illuminated and rendered scenes.. its quite far. todays images look good, but to get closer to 'the solution', we have to add a lot of additional work onto the gpu (near to 1 render per pixel.. this is not scalable). they can (and do) this in scenarios for movie-renderings. accurate reflections get more or less raytraced with a rastericer for the intersections.

if you read enough about what gi involves, and start to look at the real world again, you notice how much just depends on reflections. every surface gets reflections, that change it's look. often its rather diffuse, and only a bit, but it mathers to detect what sort of material it is. brdfs are highly complex for all sort of materials, and they all need accurate input from the whole surroundings to get an accurate shading output. you can fake that more or less. but only raytracing can give the real input values for your shaders to give the correct output.

ditto man...just take a look at PRT and the numerous caveats that come along with it...that's about the nearest rasterization can get to GI at interactive rates....but the catch is that objects have to stay close to each other for the precomputed "localised global illum transport"(kind of an oxymoron there really) to hold...again, all that hard work only to end up with crippling limitations. Is this how 3D rendering is to advance into the future?

Quote

i don't see problems in raytracers. if you finally compared the hw of saarcor to the hw of a gf6 (only hw features), and do the math, then you notice that there is a hw-speed difference of a factor 50 to 90 (depending on how you do the math..).

now scale saarcor by a factor 50 in speed (raytracers scale well, you know that yet), and take the other numbers and images on www.openrt.de and you can start imagine what a saarcor with nvidia hw technology in the back-ass would be able to do.

performance alone, raytracing as implemented by openrt is *awesome*...the jumbo jet visualization is definitive proof, as is the factory visualization! :wink:

Quote

one simple statement: the term "interactive global illumination" would not exist anymore. they could call it "realtime global illumination".

but you fail to, for one time, look at it and _CARE_ABOUT_WHAT_YOU_SEE_. (oh, you should read all the papers..).

i'm tired of saing the sam over and over again, but i got trained as i talk about it since quite long.. i feel quite lonely at my position, people are trained to believe in rasterisation and gpu's, they get trained by their jobs, by the nvidia and ati marketing, and the fact that "everyone around uses it, too..". they don't even bother to look around and 'restart thinking'.

exactly...that some inherently flawed rendering paradigm gets an early headstart to arrive first at the "accomplished" state it is today is no exhaustive proof that other ahead-of-their-time alternatives are irrelevant...raytracing might have been untenable at a time when processing power was lacking, but the time is now ripe for a new way of looking at rendering...before we waste more resources working towards some technological dead-end.

analogy: look at the way scripted "physics" has completely given way to interactive physics...I'm sure there must've been the naysayers decrying the impracticability of it, but look how far desktop physics has gone...bang-for-the-GPU-cycle-wise, raytracing represents a quantum leap over rasterization in performance and quality.

you're not alone, dave...I'm a firm believer that raytracing will rule the day pretty soon.

[Altair]

davepermen said:

its in the near-to-realtime speed for gigantic meshes, it can illuminate them with nice gi, and shaders are just a bit of hw that you could copy from gpu's today.

Like I have told you, output sensitive rendering can be brought to rasterization GPUs and that's not my idea. What I have heard, there has even been proposals to MS to extend DX to this direction (from GPU manufacturer side).

Sure you can illuminate meshes with GI in raytracing, but for what cost? You make it sound like GI (or reflections/refractions for that matter) are almost free in raytracing, so you have either no clue how it's done or are intentionally giving totally biased claims. Have you even had a thought how much data you need to access per ray to find intersections?

If you had decent understanding of GPUs you would realize that shaders take vast majority of the die size and are not just "a bit of HW". The proportional size of shader HW is nothing but increasing. If you want to have good idea how graphics HW should evolve, you need to understand how it's currently working. You should spend some time in getting into details of current GPUs so that we could have meaningful debate.

[davepermen]

have you actually READ ON OPENRT?!

because there are BENCHES and TESTS with GI SOLUTIONS BASED ON RAYTRACING, AND THEIR COST!

sorry that i cry, but i get really annoyed. they have what they call realtime raytracing, and at the same hw configuration, they can get, what they call, interactive gi.

read up on it, read those papers if you really want to discuss with me. there is the cost. yes, gi is slower, but no, not by much. more something of the sort "uh, i can play the game at 640x480 smooth with raytracing.. lets enable gi.. uhm, about smooth on 320x240.. but what the heck, now i can actually SEE something in 'doom3 openrt edition'.

the numbers are there, those are real tested live numbers (some are just old and hw got faster), they give you your questioned estimate. gi is slower, sure, but if you design right, you can make it very scalable, from no gi, up to perfect montecarlo gi with a blendfactor that scales the quality from the first to the last. this is what openrt more or less provides in the interactive gi demos, and its set to a quality level that makes it interactive.



what i mean with shaders is, they are the same bit of hw on a rasteriser as on a rt-gpu. _THATS_ what i mean. i don't say they don't cost much. but if you have to shade the intersection result of 1024x768 rays with a shader, it will be as much as rendering one fullscreen image with a shader on a rastericer. THAT PART OF THE HW IS EQUAL IN LOGIC. so it equals itself out of the whole equation.

thats what i talk about.


oh, and i know in detail how todays gpus work. thats why i don't believe in them anymore at all.

[Altair]

davepermen said:

have you actually READ ON OPENRT?!

Yes I have, but apparently you haven't. Even in the papers they say that getting adequate GI you should have budget of atleast 50 rays / pixel (I find people talking more about ~100). Now, I checked the videos they have and it looks that they are using more like 10 or so because to me what they call GI in videos looks simple soft shadowing not GI (i.e. spawning ~10 rays to the light source) in the factory example for instance. With that technique you get way more coherent memory access than for Monte Carlo type GI, so good luck with your 4 rays / pixel for GI (640x480 -> 320x240).

davepermen said:

this is what openrt more or less provides in the interactive gi demos, and its set to a quality level that makes it interactive.

Yeah, the quality level is very poor in the demos, because GI becomes really expensive in RT when you pump it up. I.e. when you move from 50 to 100 rays / pixel you probably get only like 10% increment in quality.

davepermen said:

what i mean with shaders is, they are the same bit of hw on a rasteriser as on a rt-gpu. _THATS_ what i mean.

I guess _THATS_ what you mean _NOW_ :rolleyes: Up until this moment you have been talking about reusing the HW resources of GPUs like nv40 to scale the raytracing HW. But I'm glad you did learn something :tongue:

davepermen said:

but if you have to shade the intersection result of 1024x768 rays with a shader, it will be as much as rendering one fullscreen image with a shader on a rastericer. THAT PART OF THE HW IS EQUAL IN LOGIC. so it equals itself out of the whole equation.

Okay, so I guess you haven't heard of the de facto way of rendering with expensive shaders nowdays. You first lay down the Z for opaque objects (pre Z-pass) and run another pass for shading, so you end up shading each opaque pixel once. When you disable color writes for pre Z-pass you end up processing 32 pixels in a single clock with nv40.

davepermen said:

oh, and i know in detail how todays gpus work. thats why i don't believe in them anymore at all.

According to what you have been talking about, it doesn't seem to be the case. But ignorancy is a bliss I guess.

edit: Oh, and almost forgot. Since you are big fan of scalability and output sensitive rendering, check out Hybrid dPVS. It's an output sensitive visibility system that you can use with GPUs. It doesn't rely on GPU visibility support so it does bunch of redundant work on CPU AFAIK.

[Melvin]

One should not also forget about the issue of escalating development complexity inherent in rasterization techniques.
Rasterization techniques at best lend themselves adequately to simplified local lighting models eg. per-pixel direct diffuse/specular lighting.
Global effects like reflection, refraction, caustics, inter-reflected diffuse, soft shadows with translucency etc require elaborate schemes just to obtain approximate results, often with varying degrees of restrictions.
Raytracing takes care of these effects in a most intuitive, straightforward manner...freeing developers to concentrate on other more pressing challenges in an increasingly complex development environment.
One could also ask the question "at what price?" to the assertion that rasterization can also approximate, albeit with limitations and substantial computational costs, complex global effects...how much monstrous computing capacity must rasterization consume in order to come close to the interactivity and fidelity of complex effects of which raytracing only exacts a fraction? and how many more research papers need be churned out expounding yet more ways to fake/approximate certain aspects of visual effects in isolation from the full gamut of all the global factors?

[Altair]

Those are good points Melvin.

Probably the largest contributor to the performance of this generation GPUs is the coherency or locality they exploit. If you take for instance huge memory bandwidth GPUs nowdays have, this is possible for the most part because of coherent memory access pattern. IIRC, memory in GPUs is nowdays fetched in 128 byte blocks and introducing incoherency to the memory access pattern will bring the bandwidth to its knees. Another benefit of coherency is that caches for pipelines can also be kept minimal which in turns makes adding more pipelines adequate. If you think how much effort has been put into increasing coherency even with current generation GPUs which utilize already inherently coherent technique, rasterization, it's amazing. Only place where raytracing inherently beats rasterization in memory coherency is the way it accesses framebuffer, and even for that GPU designers have went great lenghts to improve it (z-cull, swizzling, quad pipes, etc.)

Now, on top of memory coherency, there is also coherency in shaders (GPUs can be setup with only single shader at once), shading (quad pipes rendering adjacent pixels with similar interpolated shader parameters which therefore can share computations), textures (TMU setup & memory access), vertices (vertex cache), triangles (triangle setup) and what not, which in turn makes monsterous throughput of GPUs possible.

With raytracing you sure can exploit some coherency (IIRC, SaarCOR chip does this by tracing 2x2 block of rays at once), but as I see it, it's WAY more difficult, because raytracing is inherently incoherent way of rendering. Even the seemingly simple tracing of 2x2 rays has its fair share of problems alone (diverging rays in the traversal of spatial data structure). I'm sure there are many other ways to improve coherency in raytracing than what SaarCOR does, but trying to exploit it in turn makes the hardware much more complex.

I sure find those inherent global effects of raytracing attractive and it's quite elegant how they are handled, but when faced all those potential problems, I'm not convinced at all that it's good way to go. Most of the effects raytracing solves are also quite subtle in common cases where cheap approximations do work just fine, so I don't find it well justified to invest loads of processing power for that. At very least it should be optional, but in that case you would need to bring those expensive shaders (in terms of transistors) to the raytracing HW.

You also mentioned how rasterization tries to solve those global effects and which are restricted in a way or another, but raytracing is also very specific in the way it skins the cat. Raytracing requires the higher level knowledge of the rendered environment, whose representation in rasterization is completely free. You can, for instance, with rasterization GPUs generate and render the scene in the way it's most appropriate.

[davepermen]

Altair said:

davepermen said:

what i mean with shaders is, they are the same bit of hw on a rasteriser as on a rt-gpu. _THATS_ what i mean.

I guess _THATS_ what you mean _NOW_ :rolleyes: Up until this moment you have been talking about reusing the HW resources of GPUs like nv40 to scale the raytracing HW. But I'm glad you did learn something :tongue:

i ment that all the time. just you never got it.

[Altair]

davepermen said:

i ment that all the time. just you never got it.

How should I understand comment like:

davepermen said:

if you finally compared the hw of saarcor to the hw of a gf6 (only hw features), and do the math, then you notice that there is a hw-speed difference of a factor 50 to 90 (depending on how you do the math..).

now scale saarcor by a factor 50 in speed (raytracers scale well, you know that yet), and take the other numbers and images on www.openrt.de and you can start imagine what a saarcor with nvidia hw technology in the back-ass would be able to do.

Care to elaborate how you get the factor of 50-90?

[Melvin]

We've been comparing realtime raytracing technology against rasterization as if the 2 are on the same level playing field.
To be fair, SaarCOR is not even out of its prototyping diapers yet...while rasterization clearly has had the benefit of relentless and exclusive development in the mainstream realtime 3D industry all these years. But by any standards, SaarCOR is already showing precocious signs of promise.
We should only really start comparing the 2 in earnest when SaarCOR debuts...the issues SaarCOR faces now could well become moot in time, who knows?

Anyway, the point I was trying to make isn't so much on rasterization performance vs raytracing performance but the sheer complexity of development on rasterization platforms vs that of raytracing.
Even for something as basic as transparency, the rasterization approach throws up sorting issues, which despite the standard back-to-front tactic, is generally not robust(eg. intersecting polys between transparent objects or intersecting polys within a transparent object). Then there's the sorting overhead when you run up to hundreds, even thousands or more objects. There's depth peeling for order-independent rendering, but that's 1 heck of a complicated approach just to render transparent polys, notwithstanding the hefty processing overheads.
Speaking of reflections, if 1 object requires 1 cube map, then 100 objects require 100 cube maps....that's of course assuming we care about "reasonably approximate"(but not accurate) reflections on all 100 objects. Suppose we don't, then we just use a single cube map to represent the reflections of all the 100 objects...which would not look even half decent since they'd all look the same. So we use 100 cube maps to get "reasonably approximate"(but not accurate) reflections on all 100 objects, and blow our texture budget and frame rate....to make things worse, for serious apps like product visualization, walkthroughs and what not, these reflections might not even pass muster. Oh and don't forget refractions, per-pixel lighting, shadows and a few other million things we have to "tack" on. Development complexity and processing overheads quickly go up the roof...and you start racking your brain to decide which to compromise over what and by how much.
Precomputed radiance transfer comes to the rescue with fancy tricks like inter-reflection, soft shadows, caustics, scattering...but wait, the caveats list is just as long - only valid if objects don't stray too far from each other, only valid for distant environmental lighting, require lengthy preprocessing of transfer vectors...in a nutshell, it's not truly an interactive approach to global effects. Nevermind whether one actually understands the complex maths behind it.
Shadows have an impressive literature of their own...suffice to say that soft-edged, translucent, alias-free shadows in realtime still remain elusive.
One can certainly spend an inordinate amount of development effort in cheap cheats for these effects, but this effort just gets bigger and bigger with rising expectations each year, and reusability becomes more and more difficult, resulting in the familiar "this engine's rendering pipeline has been rewritten from ground up to take advantage of the latest advances in hardware" claim of pride by engine programmers.
In contrast, the raytracing approach to these challenges is as intuitive as can be, simply because it mimics the way light works in real life.
Devoting ever increasing chunks of developer effort on faking ever more impressive visual effects on rasterization hardware is not unlike faking/scripting elaborate physics behavior back when the CPU wasn't up to it...now it seems silly to do it in this day and age of realtime physics engines.
There comes a point when it makes more sense to do things the correct though inherently more computationally expensive way when the hardware is finally there to make it viable, than doggedly sticking with cheaper/limited approximations that just keep getting increasingly complicated and consequently putting pressure on what initially started out as "economical" rendering hardware to evolve into the gigaflops processing behemoths they are today.
Today, it seems a raytracing prototype with just a fraction of the processing capacity of modern day rasterization hardware can easily produce results that rasterization engines will have to resort to tons of approximations/hacks just to come close to.
Going by what the SaarCOR prototype has already shown it is capable of and will be capable of when it debuts, and the elegant ease with which to implement accurate global effects, I'm not at all convinced that rasterization-based engines is the way forward into the future.

[Altair]

Melvin said:

We've been comparing realtime raytracing technology against rasterization as if the 2 are on the same level playing field.
To be fair, SaarCOR is not even out of its prototyping diapers yet...while rasterization clearly has had the benefit of relentless and exclusive development in the mainstream realtime 3D industry all these years. But by any standards, SaarCOR is already showing precocious signs of promise.
We should only really start comparing the 2 in earnest when SaarCOR debuts...the issues SaarCOR faces now could well become moot in time, who knows?

But to be fair to rasterization, the technique has went through extensive testing in production over a decade and many issues with it has already been surfaced. Same can't be said about raytracing since it, like you said, hasn't even got out of its prototyping diapers yet. Only thing we can do is to make well educated guesses and try to be objective about known and speculative pros and cons both techniques have, and with the raytracing cons I have brought up I believe I have only scratched the surface a bit.

Melvin said:

Anyway, the point I was trying to make isn't so much on rasterization performance vs raytracing performance but the sheer complexity of development on rasterization platforms vs that of raytracing.

It's all about performance :cool:

[Melvin]

Altair said:

But to be fair to rasterization, the technique has went through extensive testing in production over a decade and many issues with it has already been surfaced. Same can't be said about raytracing since it, like you said, hasn't even got out of its prototyping diapers yet. Only thing we can do is to make well educated guesses and try to be objective about known and speculative pros and cons both techniques have, and with the raytracing cons I have brought up I believe I have only scratched the surface a bit.

>> just as you've pointed out how rasterization has had the benefit of dedicated research/development by the mainstream real-time graphics industry to evolve to the state it is today, do note that raytracing has traditionally only received the niche attention of academics, offline rendering developers and the occasional gung-ho raytracer coder...it's hardly any wonder then why rasterization is more "established" and has had more of its inner demons "exorcised" compared to raytracing, which is only recently beginning to attract mainstream attention given increasing processing power nowadays. Not surprising then is it that only the tip of the iceberg has been scratched. My argument is, just because rasterization is now looking good(albeit with limitations, and IMHO a heck lot of it) with tons of processing power thrown at it plus clever optimization techniques, doesn't mean we should sit pretty on our laurels and stop looking elsewhere for a potentially better solution because we don't want to venture outside our comfort zone. Rasterization may look "good enough"(and that is subjective, not forgetting that graphics isn't just for games but also other more serious apps like product visualization, walkthrus etc) now, but it may not be the best solution to bring us into the future. Should reflections still be done the way it is today, say 5 years from now? What with all those clumsy memory-hungry reflection cube maps, tedious setting up for rendering, expensive multi-pass rendering into not 1 but 6 targets...only to get at best approximate results, worst case completely wrong results? And let's not get started on those other myriad effects we also have to consider, which all have to be integrated together somehow to produce the final rendered result. Surely we should've long outgrown that phase of hacking and fudging, and left it up to the renderer(incidentally a raytracer naturally) to simply and elegantly generate the accurate results that we can all take for granted, while we move on to other bigger more deserving challenges?

Altair said:

Melvin said:

Anyway, the point I was trying to make isn't so much on rasterization performance vs raytracing performance but the sheer complexity of development on rasterization platforms vs that of raytracing.

It's all about performance :cool:

>> even so, I'd say the SaarCOR prototype makes a pretty good statement about performance, if not the last word...

[Altair]

Don't worry Melvin, I can tell you that many game developers can think out of the box and don't just sit pretty on their laurels. I think game developers contributing to this discussion is fair example of it :) It's just very common to see people, particularly with academic and hobbyist background, to lullaby themselves to over optimistic dream and totally forget, or not even be aware of practical issues about different techniques. I see people constantly, when talking about their favourite technique, to bring up only the positive things about their beloved pet, but that doesn't give me impression they got comprehensive understanding of it.

About cubemapping, yes, I'm well aware that it's not perfect solution but it's good, simple and efficient approximation which fits the purpose in most of the cases, in other words, it's practical. If you want to deal with dynamic cubemapping, which isn't actually needed that often to give believable impression of interreflectance, you need memory only for a single cubemap since you can recycle the memory for different objects. There are also solutions coming to shortcomings of rendering to a cubemap.