Raytracing vs Rasterisation

Miscellaneous Forums/General Discussion/Raytracing vs Rasterisation

Raytracing vs Rasterisation

It's interesting to note the ongoing debate about Raytracing vs Rasterisation in the tech media, it seems to be as old as the hills, but the face off has become increasingly frequent with recent technology and technique advancements which seem to hold promise of enough processing power to make quality real time Raytracing possible for the masses.

I got thinking that in some ways it's similar to the Electric Car vs Fossil Fuel Car. Both go back a long way, but recent advances in electric drive systems, battery technology, ultra capacitors and hydrogen fuel cells, are making them inch ever closer to a practical solutions for all.

The analogy turns up some similarities. Fuel driven engines are a real hodgepodge of techniques trying to make the best of something that is hard to make the best of.

Conceptually you are vaporising fuel, and mixing it with air, drawing it into a confined space and compressing it, setting light to it, letting it explode, then using the force of the explosion to push another cylinder of exhaust out of the engine into the atmosphere. Noisey too! The engine requires an energy injection to start, and will stall if not kept running, even when the car is not moving. A poor implementation is very wasteful of both energy & fuel, produces lots of pollution and requires a great deal of maintenance to work reliably. Plus to get any real speed, you need complex gearing. Add to that you need fluid filled radiators to keep it from melting!

Over the years manufacturers have come up with a whole bag of tricks to make them work better. Complex engine management systems which monitor air pressure, temperature, load, engine speed, oxygen level in the exhaust, variable valve timing, complex oil formulations, ignition timing maps, the list goes on!

This has resulted in the fairly powerful cars we have today. They require regular maintenance or they break down, they still produce pollution (although much less than they used to) and are expensive to own and maintain.

Contrast that with electric vehicles. They produce no direct pollution at all, the actual engine is pretty much just an electromagnet suspended between two solid state magnets (oversimplification), and can even be incorporated into the wheels! They do not require much engine management, are relatively low maintenance and fairly quiet.

So why isn't the world filled with Electric Cars?

a) Performance - Up until recently electric cars were slow
b) Performance - Up until recently electric cars had very low range
c) Performance - They take time to charge and cannot be refuelled instantly
d) Infrastructure - The world isn't set up to use them yet, so no charging facilities etc.

As pressure with the existing fossil fuel system mounts though, a change is coming.

Ok, back to Raytracing vs Rasterisation..

Rasterisation is like the fossil fuel driven engine. It developed long ago because it was possible to make it work! It involves taking a large set of 3D vertices and transforming them into 2D points (remembering the Z as a function of distance from the viewpoint). Take three at a time, then you make a triangle. Then a set of 2D Rasterisation routines draws and fills the triangle interpolating between the 2D points and marking the interpolated Z into the Z-Buffer. As you go through all the triangles, one by one, you check each point you're drawing to make sure the Z is closer than the one in the Z Buffer, so that nearer triangles obscure the ones further away.

In its raw form, image quality is a bit lacking and is quite wasteful in writing all triangles, regardless of what can be seen, etc. You get the point..

Of course, like the car, it has seen some *serious* work over the years. Especially since the hardware people started developing it, a whole technological hodgepodge of techniques have been used to make it work ever better.

On the hardware side, Zbuffers have been joined by, stencil buffers, texture memory, mip mapping, filtering, antialiasing, shaders, backface culling, normal mapping, Z-Sorted alpha transparency <insert really long list>, etc.

On the software side LOD, visibility portals, occlusion testing, <insert realllly long list>, etc.

The result is that we have huge GPUs with 10x - 20x the processing power of the average CPU, being driven by hugely complicated multi-pass software engines utilising large & complicated APIs (DirectX for instance).

It costs an obscene amount of money to make a high end game. Much of this is due to work required by programmers, artists, level designers, who need to apply new tricks to align the needs of the game to the limitations of the technique.

Where is Raytracing then?

The technique is conceptually fairly simple, you have a list of triangles. You fire a ray for each pixel on the screen, and trace which triangle it hits. From there you trace additional rays to light sources. For transparency, you continue the trace through the object, for refraction, you adjust the direction of the ray as it passes through, for reflection, you continue the trace at an angle. Repeat for each pixel.

You don't need a Z-Buffer, since each pixel is traced indiviually.
You don't need to Z-Sort triangles since transparency is traced in order.
You don't need a stencil buffer for shadows (I know there a lots of other techniques), they're raytraced per pixel.
You don't need a LOD system, since visibility is defined per pixel rather than per triangle.
You don't need other visibility culling techniques, since triangle count is not so important as RT scenes are spatially subdivided.

So why isn't the 3D computing world filled with raytraced games and applications?

a) Performance - Up until recently, raytracing was strictly an 'Offline' thing. Too slow!
b) Performance - Up until (relatively) recently, raytracing had little in the way of acceleration techniques available to them.
c) Performance - Up until recently, processors (and memory speeds) have not been powerful enough to handle the load of tracing millions of rays per frame!
d) Performance - With many core processors on the GPU and now CPU, things are finally falling into place.

The most encouraging thing about Raytracing though, is that it employs one technique, and uses it in increasing quantities to do more and more.

You want polygons with LOD = 1 Ray
You want Per Pixel Lighting + 1 Ray per light source
You want Hard Shadows + 1 Ray per light source
You want Soft Shadows + n Rays for sampling
You want Antialiasing + n Rays for adaptive supersampling
You want Radiosity + n Rays fired at random for environment sampling
You want per pixel collision detection + n Rays each object.
You want Subsuface Scattering + n Rays per hit.

Couple that with the fact that raytracing can handle large loads of Triangles with relative ease, and you can see why it is a desirable upcoming technology.

Now there's no doubt that all those rays add up! But the potential is there from the start.

It is quite possible that a Raytracing API could be created that gives the option to use enable of these image quality settings (even if it would be a 10 second per frame slideshow to use them all). Then as new hardware to accelerate it becomes available, even older games would begin to take on a new life. You see, all they needed was more power, not new techniques!

Imagine playing something like Oblivion with no LOD popping in your face, a significantly higher polycount, perfect shadows and reflections, proper refraction one year. Then upgrading your GFX card later in the year and when you load up the same game, being able to enable cool Global Illumination effects, then upgrading perhaps the next year, and being able to enable subsurface scattering to improve the skin and other textures.

Rather than making games to target a specific performance group, you could make one that covers from mainstream to extreme simply by increasing or decreasing the number of rays it can use.

Then the engine you use to program the game will not be so significant, since the software engine will not be the all singing, all dancing bag of magic tricks it now is, but all the magic can be in the API, but essentially latent, until the advancement of processing power unlocks their use.

What else could be done to make raytracing faster? How about upscaling, like video? Rendering at a little lower resolution, then interpolating this to a larger one with a powerful upscaling filter.

Rasterisation has wads of long term investment on its' side, but I believe it may not hold the crown forever.

Let the Flaming commence ;)

I can't see raytracing replacing rasterization in the forseeable future. It's just too many orders of magnitude more computationally intensive, not to mention the masses of data movement.

However, I can see it used for certain visual effects as part of a larger system. And there can be beneficial spinoffs. The same technology can be used for physics, since both involve moving particles around and interacting with the environment.

This makes your electric car analogy even more apt. Improved battery technology, ultra capacitors and hydrogen fuel cells are useful developments. But they address only part of the problem, storing power in a portable form. That still leaves the fundamental problem of generating that power in the first place.

This makes your electric car analogy even more apt. Improved battery technology, ultra capacitors and hydrogen fuel cells are useful developments.

I agree, which is why Hybrid vehicles are much more viable in the current climate than pure electric.

I do think though, that if Raytracing had as much investment in terms of hardware acceleration as rasterisation currently does, it would be a viable technique for a lot more than it is currently. We're likelu to enter a period of co-existence rather than replacement, since the prior investment is just too much to throw away in the short term.

Market forces will be the driving agent behind any changeover to raytracing.

I understand your idea of older games incrementally increasing their visuall appearance when run on ever more powerful hardware, but I think you've overlooked a point; artists will have to intially define all the parameters (the subsurface scattering, for instance) even though no current hardware will be able to represent it.

That being the case, nobody is going to 'waste' time creating visual effects which nobody will be able to see within the next 6 months (let alone 12!). Games generally lag behind the capabilities of current-gen graphics hardware. To do anything else limits the target market, or increases production time (which again misses vital sales potential).

It's a good job that this happens. New graphics hardware generally enables smoother framrates of current games. New games then make use of more advanced features of that graphics hardware, dropping framerates again, which then drives purchases of graphics hardware upgrades.

Not so much a vicious cycle, as a prospering market!

..I think that some kind of mixture between raytracing and rasterisation can be realistic solution in near future...pure raytracing, in some near future..hmmm...I dont think so..

But what about making a realtime-raytracer in CUDA? If you assume that the GPU's is much faster than the CPU, why not write the raytracer on the GPU then? ;-)

I understand your idea of older games incrementally increasing their visuall appearance when run on ever more powerful hardware, but I think you've overlooked a point; artists will have to intially define all the parameters (the subsurface scattering, for instance) even though no current hardware will be able to represent it.

I think the point is that many surface types could be part of the API, skin being a perfect example. We're so used to having to define *how* we get certain effects, that we forget that 'settings' for sub surface scattering would be much easier to define than writing the multi pass rasterisation routines that we currently see in use. In fact, having it part of the API gives more scope for innovation by vendors, making 'skin' for instance more realistic for a given set of parameters.

I see a possible Raytracing API as having the possibility of advanced materials applied to objects which, due to the ray based nature, can have a lot more in-built functionality than the current raster 'materials'. (look at the Lightwave 9 Node editor as an example). In fact, if they're modelling their charactes in something like lightwave, they could export all that information into the game without much translation.

It would be nice to simply set transparency, translucency, refraction index, reflectivity, specularity, diffuse as surface settings with the option to use a texture map for each setting.

But what about making a realtime-raytracer in CUDA? If you assume that the GPU's is much faster than the CPU, why not write the raytracer on the GPU then? ;-)

GPU-RT has been done, but the performance is not that good, since the hardware architecture is not set up to handle it properly. The load is applied in a different way and branches too much. Plus GPUs don't lend themselves very well to things like KdTrees.

The most promising GPU for this at the moment is INTEL's upcoming Larrabee.

Actually since this likely to heat up even more in coming months, I suppose the best catalyst for development would be to have an implementation agnostic standard RayTracing API (free for all to use), (like OpenGL) which allows all vendors to come up with their own implementation of it.

That way if Intel believes they have the best, they could implement a driver for it, conversely, if Nvidia thinks it's GPU tracing is so easy, they can do and implementation driver for it too.

As a base it could do an 'old OpenGL' and do a normal RT in software render.

As far as I see, raytracing won't be replacing rasterization any time soon, maybe if they get cold fusion working or an affordable quantum PC (some day...sigh) it would be a realistic approach, but as for now, our computers just arent powerful enough to handle 1+ million raytraces 60 times per second...

TBH I think TeraBit has a point take into consideration that loads of programs have per-pixel lighting already that generates stuff on each pixel on the screen. Raytracing just takes everything you would ever see and combines it into each pixel on the screen so as it progresses you would see performance improvements as if it works at 60fps at maximum resolutions you can guarantee that it will work at least at 60fps on lower resolutions too.

As far as I see, raytracing won't be replacing rasterization any time soon, maybe if they get cold fusion working or an affordable quantum PC (some day...sigh) it would be a realistic approach, but as for now, our computers just arent powerful enough to handle 1+ million raytraces 60 times per second...

It's probably a good time to be formulating a generic RT API then, since I expect that when OpenGL first came about, there wasn't enough power in the average computer to do 3D graphics either. These things will take a bit of time, perhaps neither will win, maybe something else we've not thought of yet will 8D

It's pretty crazy now days with the newer GPUs. For example, the new ATI 48xx series can execute 800 native commands per clock cycle!!! That is massivery fast!!! I can't imagine realtime raytracing not possible on this GPU on a decent resolution (considering it's massive parallelism scale). Realtime raytracing is bound to happen in the near future since it already happened 10 years ago on the demo scene ;)

Cheers.

One impressive demo of what can be done even now with no special hardware or GPU help is here

This one caught me off guard: Pretty spiffing!

http://www.tgdaily.com/content/view/38145/135/

http://www.tomshardware.co.uk/Larrabee-Ray-Tracing,news-28603.html

I don't think it even is about performance, performance, performance. The aim is to make things look good and sometimes that means doing things in a completely inaccurate way. Focusing on raytracing means everything else falls by the wayside. Focusing on general rasterization means everything benefits, and that includes raytracing. There's nothing stopping you from raytracing in a pixel shader ( more or less ) and because pixel shaders are run entirely on the GPU, they're automatically threaded to take advantage of every core you've got.

Bottom line, if you raytrace and I rasterize - and assuming we're of equal ability - I'm going to be able to produce something which looks 95% as good with 50% of the processing power. Unless the entire architecture of DirectX, OpenGL, GPU design is thrown out and started again. And good luck getting Microsoft to throw something out and start again.

I don't think it even is about performance, performance, performance. The aim is to make things look good and sometimes that means doing things in a completely inaccurate way.

I don't mind that so much, but multi layered multi pass techniques (and the odd hack) to make something look good is hard going. If we had enough processing power, it would make sense to do it the straight forward way.

It's like if I were Mr. Incredible, I'd knock down a building by kicking it. But since I'm not, I need to hire a wrecking crew, get trained on how to operate the machinery and then knock it down.

The result might be the same, but the only reason it was so complicated to achieve was that I didn't have the power to do it the straight forward way. This is fair enough. But if the power became available, I don't think people would stick to the old techniques. The Rasterisation people have held most of the aces until now, but it may not always be so.

Another recent development: Intel converts ET: Quake Wars to ray-tracing...

And to support this thread:
http://www.techpowerup.com/64104/Radeon_HD4800_Series_Supports_a_100_Ray-Traced_Pipeline.html

Hmm...very interesting, except someone will have to come up with a butt-kicking not-so-slow game before anyone is convinced to actually put some energy into shifting from rasterizing to raytracing.

I agree with the sentiment in the original post wherein the API's and techniques and hoops we have to go through these days are more or less all made necessary by the underlying fundamental flaws in the system. It's like we have these various benefits to rasterizing, but they always come with some kind of issue or detriment, which we then need another technique to try to make up for it, and then that technique has side effects which require further flawed techniques to make up for it. It's all like constantly patching things up and trying to react to problems in ways that create more problems.

What really is needed is to go back to the foundation and the roots of the system and rethink it, which is where raytracing can be seen to be a superior paradigm. It might at present be subjectively slower or relatively slower than rasterizing, but in terms perhaps of design or artistic freedom or versatility or quality it far exceeds what rasterizing can do. It's is very much akin to ditching the old clunky problematic engine and opting for a fresh new more intelligent approach. There will be plenty of people who continue to opt for rasterized graphics and plenty of people trying to make those graphics even more realistic, but I think ray-tracing is ultimately the better and purer approach and will establish itself slowly but surely.

Also let's not forget that just because we're working with triangles now does not mean that ray-tracing has to use triangles. Consider the constructive solid geometry ray-tracers, like Real3D for example. Triangles are easy and simple but they are not the most elegant. And what about modelling with pixel-perfect splines and no de-resolution of triangles appearing near to the camera? Triangles are ugly. I think we will move towards more advanced mathematical modelling where the GPU/CPU computes objects based on formula's internally and the user and developer interface with it at a higher, less programmatical level. Pretty soon the hardware will be managing spacial partitioning and all the lower level stuff for you and you'll have a really simple elegant interface to it.

Movies are pretty much the forefront of cutting-edge graphics these days and more and more that ray-traced quality is going to seep down into every-day platforms and games machines.

I think it's interesting that CUDA for example now lets you write regular programs on the GPU. So what is the GPU turning into now - it's becoming basically a general purpose multi-core CPU system. Pretty soon you'll have a supercomputer on a chip, like multiple Cells for example, and then you'll be back to writing whatever graphics system you like - rasterizing, ray-tracing, fractals, whatever, and then `software rendering` will merge with `hardware rendering`. Highly programmable hardware is the future, probably moreso than any specific graphics approach.

Nice analogy

I don't mind that so much, but multi layered multi pass techniques (and the odd hack) to make something look good is hard going. If we had enough processing power, it would make sense to do it the straight forward way.

I think you're coming at this from entirely the wrong direction. You're looking at this in terms of DirectX7 architecture and how things worked when Blitz3D was cutting-edge. Things have already progressed so far past what you think is the current state of play that most of what you're talking about is already there, and perfectly viable, but doesn't need the kind of massive architecture conversion that you think it does.

As ImaginaryHuman already pointed out, GPU architecture and the API's for it, are so general-purpose now that you can have it do anything you want. You're arguing for something you've already got, and you're arguing against something which is no threat to you. The danger in that is you may actually hurt the cause by trying to change a system which is already better for you than the one you imagine is required would be.

I still don't necessarily accept that doing things the physically accurate way is better, but the system you need to do it is already in place.

You're looking at this in terms of DirectX7 architecture and how things worked when Blitz3D was cutting-edge. Things have already progressed so far past what you think is the current state of play that most of what you're talking about is already there, and perfectly viable, but doesn't need the kind of massive architecture conversion that you think it does.

I do try to keep up with the newer developments in rasterisation and I tend to agree that things have changed a lot in some areas. However, I'm not so sure that most things have changed as much as you infer. You still send a stream of vertices to the API which will draw them in order of sending. You still AFAIK, have to Z-Sort your polys to get transparency to work without artifacting. You still have to do multiple cubemap render passes to get reflections. You still have to do multiple render passes to do decent shadows (shadow mapping). However there is not one size fits all technique. Shadows are a particular area of contention, as there are so many techniques for doing shadows and it often depends on what you are doing as to which one is most appropriate.

If you have to do several multiple renders to texture to do these 'basic' things, it's fair to say that there are issues with the current model. Listening the development commentry on Portal brought it home to me.

Nobody is saying that Rasterisation is not impressive, it is very much one of the coolest things I've ever played with. Vertex, Pixel and Geometry Shaders now give you a great deal of flexibility, per-pixel lighting and normal mapping just to name two. You can trace some rays in shaders to enable some interesting effects, but the issue is not just what can be acheived, but how much micromanagement is required to do so.

Going back to the analogy at the start of the thread. Fuel driven engines have developed into hugely complicated things as new tech has been bolted on top to make them better. Similarly your computer can go faster and faster as you upgrade the components attached to it, but there comes a point where you need to upgrade the motherboard to get any further.