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

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.

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

Well, this is becoming a big subject of debate and even flamewar even on a CEO scale [remember Intel and nVidia ? ]. Well, being involved with this stuff for a good time [I have been programming on OpenGL for some years and have programmed a primitive Raytracer at the least], I hope I will be able to explain a bit of this stuff here.

Rasterizer

Well, rasterizer has been around for a LONG time and has been the prime method of producing 3D Graphics on home computers. To put it easily, a rasterizer first starts by associating spacial [as in space] information with the vistuals [vertices and surfaces] – part that is done by the vertex shader, throws up or cuts the data according to the viewing and camera information [clipping and viewing transformation], and then converting the visual parts to pixels [rasterization] and doing some shading/coloring on them [pixel or fragment shader]. Now to explain this stuff in further detail :

The shapes and “meshes” and it’s associated information like texture [the image you put as a skin on the object] enter what is called “the rendering pipeline”, each vertex is associated with a position, a color and some other information we don’t care about at the moment. Now each of the vertices is fed to the “Vertex Shader”, they set the final position and the color and some other information, either by the code [if the shader is programmed], or the “fixed functionality”. The “Geometry shader” the recent part introduced by the infamous DirectX 10, deals with how these objects are connected to each other [for example three vertices can form a triangle] and can output a number of shapes depending on how it is configured. All the shapes will be broken down to triangles before entering the rasterization section in the current implementation. In rasterization, the triangle’s surface is broken down to the would-be-pixels/fragments, the closest one is kept and interpolated values [For example if two of the vertices marking a triangle is red and one is blue, you will see a kind of gradient thing between them] from the Vertex/Geometry shading is passed to the Pixel Shader, and the pixel is colored, with the Pixel Shader Code or the fixed functionality, and is finally outputted to the framebuffer.

This is pretty much the main skeleton of that is being done on the shader.

Now this system can be implemented [and has already been] on the hardware, and we have hundreds of Rasterizers around us (start from home PC’s to even those mobile phones that have 3D Games on them). However things get trickier when the lighting is involved. For example the main method of Rasterization, has no way to calculate shadows, and we have to use various techniques to do it, and lots of extra work if we want to make it look better. Overall, let’s say efficient and easy as the Rasterizer might be, it is not a very good approximation of what we see in the real world.

To be continued… Hopefully.

Big Rigs: Over the Road Racing

A friend, pointed me to the video review of the game here [Though I can't believe someone to get a tantrum and emotional breakdown from a computer game like that, it is is still fun to watch]. But well, I am not going to spend time on bashing the game, if you want to see bashing, you can go to the Wikipedia article for the game and visit the history section, for various forms of vandalism. But I think there are untold things about the game, as a remove section from the Wikipedia article pointed out to. From my point of view, who has spent a good amount of time learning about the game development, the game is just a very very early beta, that by a disastrous project management decision, was shipped to customers. Problems such as infinite reverse acceleration can be solved by a few lines of code and the fact that the truck passes through various terrain, shows that only heightfield collision has been finished and the mesh/primitive [like Box/Sphere/Etc] collision, and the required Physical model info that relies heavily on the DCC tools [DDC = Digital Content Creation], are not done at all. Looking at the talk and debate section on the Wikipedia article, you can see that a game, with many similarities with the Midnight Race Club : Supercharged game [From similar bugs, to shared resources in the packs] which further implies that the Big Rigs game is either a very early beta, or a fork from the Midnight Race Club project.

But well, this is not the first terrible game, nor the last one. In fact, games made by the developer, Stellar Stone are meant to be B-Games [Yeah, I just created the term] in the first place, with a low price tag [Though Big Rigs does not deserved to be even called a game]. But, in my opinion , games like this one, deserve to be buried rather than being brought up constantly and I think, when big and famous companies, who have access to far more superior development tools and equipment, and who, with a huge advertising campaign, claim to be shipping a superb game to customers, only to release a subpar game, deserve a greater and more long-lasting criticism. [On a side-note, I have seem some pretty horrible Iranian made games with Rippid off development tools - from HavoK engine to every leaked commercial graphics engine, that in the end, ship a game that wouldn't get more than 2.0 in GameSpot. But that's another story]