A look into the whole Rasterizer VS Raytracer story – part 2

By unknownidentifier

Raytracer :

A raytracer, uses a different model than rasterizerization. In a raytracer, for each pixel, a ray [or more] is generated, raytracer traces the ray through the scene, generating more rays at collision with objects if needed [for example when a ray hits a glass, some of the light goes through the glass [refraction] and some of it is reflected, so a single ray is turned into two rays], and different formula’s would indicate the final color that the ray will return. The more rays are casted [more rays for pixels, more rays for a greater resolution and extra rays for collision,etc] and the greater the depth that they go to [because the recusion can't go forever] the more realistic the scene would look like, but it will take more time to render, and raytracer as it is, is far slower than Rasterization. As you can see, the raytracer is a better approximation of the real world optics, so getting a realistic result is easier and you don’t have to resort to many tricks and hacks to get it to work [for example, by casting one or more shadow rays, you can generate very realistic shadows, far better than those generated by rasterization and the load of hacks you have to use]. And you can actually achieve global illumination by casting lots and lots of rays, but it is extremely slow and completely out of the question for a real-time rendering with the current hardware right now. [Though techniques such as photon mapping is something far easier to do]. However, it should be noted that OpenGL and DirectX cannot be rendered in a raytracer engine or at the very least all of most of the effects will be broken [if you are unsure about this, re-read the description for rasterizer here again - though you can use rasterization hardware to accelerate raytracing using GPGPU, or even use Rasterization for casting rays when you can]. As I said before, the biggest compromise of Raytracing is the overhead involved with it and the difficulty to design an efficent hardware, against rasterization, these are the main things that have held it back and will probably hold it for some time. [IIRC, Raytracing was first introduced back at 1968]

There have been some efforts of making a Raytracer hardware, though it must be noted that due to the nature of Raytracing, you will need a lot of random accesses to the memory, so even using caches cannot do much to reduce the impact of a large scene like a terrian being rendered using raytracing. Raytracing is also different in the sense that we need to use a space partitioning technique such as kd-tree’s or BSP’s [So we trace the rays through paritions and each time check the ray intersection with the objects that are inside the current partition we are in], and it is even more difficult to deal with if you want to support dynamic scenes.  Implementing all this stuff on hardware is a real hassle, currently some projects like SaarCOR and RPU exist, but they are far from being complete, the most powerful one will probably be the Intel Larrabee which is being heavily hyped by Intel [yet very little info has been disclosed about it, we know that it is supposed to be a poly-core chip with vector processing capabilites though].

To be continued.

Tags: , , ,

Leave a Reply