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]

Some tips for working with files :

Here are some tips for when you are working with files :

1. There is different in the way line break is stored between Windows and Unix-based [Linux,FreeBSD,etc] as a result, you must be careful when reading text files or getting input from the shell/prompt, because it might crash or worse, give incorrect information on other platforms. When the data entered has a line-break and you want to read a line, do not use scanf(“….\n“), either use filestream/cin.getline and process the line using something like sscanf(), or use multiple calls to cin (but before doing that, read tip #3 )
2. When giving the path for a file, instead of using ‘\’ , use ‘/’, so Unix-based operating systems can work with the code properly.
3. The number of accesses to the file [if it's stored on the disk] can have a critical effect on the performance of your files. Try to maintain a balance between the size of the blocks you are reading and the number of calls you are going to do in a file to get the best performance. But if the file for example has 10 integers in a single line, make sure to get the line using cin.getline (The line can be long, careful to allocate enough space for the line) and then process that string from the memory, this can bring huge speedups to your program, because the seek-time for a hard-drive is far slower than in the memory.
4. Binary formats are far faster than the text formats, when you want to keep a close eye on the data [like the early stages of the project] it is a very good idea to use Text mode, but when it is time to finalize the project and when you want to do performance improvements, add support for the binary formats [it's off-topic, but you better keep the text format capability maintained, it will be pretty useful for debugging]
5. Don’t reinvent the wheel every time you program. To store configurations and also structured text data files, it is an excellent idea to use formats like XML. From Delphi to C++ to Java, all of them have good support [using external libraries if the compiler is not shipped with XML support] for the XML and there are a good number of XML processing/editing software available too.
6. Don’t let the constantly growing files like logs become huge. Because there is a high chance that they will be heavily fragmented when stored on the hard-drive. Try splitting them up, for example if the program is constantly running, use a different log file for each day and store them appropriately [like organizing by date and using meaningful names for the log file] so consulting them would be easy.
7. Make sure to close the files after you are done with them. Also if you’re program is saving a log, make sure to flush the buffer everytime you write to the file to find out what happened before your last crash.

Well, I think that’s it for now…

iLAG

Well, guess what ? I tried to ping google and this is what I got :

Pinging google.com [72.14.207.99] with 32 bytes of data:

Reply from 72.14.207.99: bytes=32 time=2113ms TTL=242
Reply from 72.14.207.99: bytes=32 time=1867ms TTL=242
Reply from 72.14.207.99: bytes=32 time=975ms TTL=242
Reply from 72.14.207.99: bytes=32 time=1286ms TTL=242

Ping statistics for 72.14.207.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 975ms, Maximum = 2113ms, Average = 1560ms

Interested ? Here’s more info about my internets :

Tracing route to google.com [72.14.207.99]
over a maximum of 30 hops:

1     1 ms    <1 ms    <1 ms  . [192.168.2.1]
2  1618 ms  1881 ms  1863 ms  172.26.5.1
3  1648 ms  1523 ms  1863 ms  10.21.128.1
4  1506 ms  1494 ms  1729 ms  10.77.78.125
5  2064 ms  1625 ms  1793 ms  ns.kaman.azadnet.net [80.253.137.5]
6  1436 ms  1218 ms  1647 ms  int0.client.access.azadnet.net [80.253.137.14]
7  1485 ms  1359 ms  1200 ms  int0.client.access.azadnet.net [80.253.128.20]
8  1811 ms  1465 ms  1598 ms  DATA-LCT.dci.ir [80.253.145.18]
9  1930 ms  1740 ms  2074 ms  pos4-9.ar03.ldn01.pccwbtn.net [63.218.13.89]
10     *     1942 ms  1863 ms  TenGE13-3.br02.ldn01.pccwbtn.net [63.218.12.246]

11  1809 ms  2146 ms  1748 ms  195.66.224.125
12  1666 ms  2269 ms  2393 ms  209.85.252.42
13  1273 ms  1399 ms  1355 ms  64.233.175.213
14  2081 ms  1784 ms  1757 ms  72.14.233.113
15  1710 ms  1576 ms  2013 ms  66.249.94.92
16  1966 ms  2287 ms  2013 ms  72.14.236.134
17  1944 ms  1823 ms  1620 ms  google.com [72.14.207.99]

Trace complete.
Well, I don’t think you are left in any wonders for why I am having so much lag ^_^

AMD and Phenom

Well, the B3 revision that fixes the well publicized TLB erratum has finally shipped to the consumer reviewers. Techreport’s review was the first that I saw and I just saw Anand’s review. Well, to put it bluntly, in most applications the current 2.5GHz 9850 Phenom is slower than 2.4GHz while in some of the reviews it fares better. Apparently the Techreport managed to get to a stable or at least semi-stable overclock [they didn't do serious stress tests that go for hours], but the benchmarks show some hope. With some tweaking in the voltage, the Phenom hit 3.0GHz which could somehow compete with the QX6800 [2.93GHz 65nm Intel processor]. I am not going to go into a discussion about it’s overclocking power and how it stacks against Q6600 [because Q6600 can go all the way up to 3.2GHz stable at least and not many go for overclocking]. But this at least shows that Phenom can somehow compete with the Core 2 Quad is a good sign.

However, there are some problems that AMD is facing for example :

1. Intel enjoys a much higher performance in certain programs. For example, at POV Ray and Photoshop, Intel processors and specially Core 2 Duo have always been exceptionally better [sometimes 2X the performance between similar Intel and AMD offerings]. AMD should try to get the vendor of these programs to optimize the code for them. How difficult will this prove to remains to be seen, but right now, the customers that are to work seriously with these programs, will always prefer Intel processors performance-wise.
2. AMD should review some of it’s strategies for the microprocessor, or it will end up in even more problems. For example, AMD didn’t pay much attention to the fabrication technology, resulting in being more than six months behind in the 45nm node and with Intel’s current technology being superior [If we assume that they will bring out Shanghai in 08H2] and if both Intel and AMD-IBM meet the estimates, it will be behind for about 3 months for the 32nm node. AMD probably have been much better off if they hadn’t jumped on the “native quad-core” bandwagon. IMHO, they would have done much better if they had gone to optimize their 65nm K8 design in the short run [how come the maximum clock for 65nm processors is 2.8GHz while it is 3.2GHz for 90nm, this shows they could have put much more effort into the 65nm die shrink] and improve the weak parts of the architecture.

I must add that I, in no way am an Intel fanboy, I’m just trying to be fair here. The Graphics division, ATI, is back on the track nicely and with the 3870/3850 where they hit the sweet-spot for the mainstream performance/price/delivery time and availability. Also AMD seems to be on the track for releasing the 45nm Shanghai processors. Though it might face a very strong opponent which is the Nehalem [I am not sure about how accurate the slides or the ZDNet article is - though both seem to be correct - but if they are indeed correct, Shanghai will be in trouble unless it debuts with high clocks], but even if we take these predictions to be accurate, AMD’s has been performing much better lately than it was earlier [and they did admit that the native quad-core approach was wrong],  hopefully they will keep trying to eliminate the bottlenecks in the current design to recover from the current mess they are in, because it is scary to think what will happen if Intel is left without any competition…

Drumroll : There comes HavoK

HavoK is by many, considered as the best game Physics engine. Though Havok FX is probably either dead or will be neglected because of the fact that Intel has barely any solutions that can make proper use of Havok FX’s shader code [Larrabee is an array of X86 cores, so it will most likely have a different implementation to get the best performance] , but nonetheless, the news that Intel will release HavoK for non-commercial projects for free is great news for many of those free projects out there.  Though this move is most likely a marketing move for Intel to eventually drag the Open-source developers to use Larrabee or at least an Intel CPU optimized engine, it is still a very good thing for both the Open-source and freeware game developers. On the other hand, AGEIA has been bought by nVidia, that means that we will see a CUDA accelerated PhysX soon, these two events will probably leave AMD in even more trouble than it already is in unless they either find a good physics engine, or get one of the two [nVidia more likely] to support hardware acceleration through AMD GPU hardware.

OpenGL 3.0 : Hello ?

Well, as many seem to remember, at Siggraph 2007 [and at August] Khoronos announced that the specs should be finalized and they should be publicly released at September, which excited many people. After a long wait and no comments, there was a posting at OpenGL.org from Khronos, about the state of the OpenGL specs, according to them, it seems that they have been having problems with finalizing the specs and the released will be pushed back to 2008, and it seems that we have yet to run an OpenGL 3.0 program on our computers. Though a late and solid release is far better than a hasty and buggy one [as the announcement about the delay says the specification has had some improvements from the Siggraph presented version], but we wait is becoming a bit frustrating for many. Specially some that delayed some projects in hope of getting their hands on OpenGL 3.0 to prevent re-coding (*cough* *cough*).

Batman begins.

Well, everything has a start and same goes for this blog, ironically, the start of this blog is about 11 hours away from the end of the current Iranian calender year of 1386 and the start of the year 1387. Well, looking back at this year, lots of things happened but well… [This means that I am not covering them here =P]

About the title of this blog, well as many computer geeks would have guessed, this is an effect of prolonged exposure to the Pascal programming langauge, my first programming language after parting with the good ol’ Commodore 64 and it’s BASIC V2 programming langauge. Oh the good days… [Refer to the comment at the last of the latter paragraph]

Well, this weblog will cover lots subjects hopefully, ranging from Computer Graphics and Programming even to Social and Religious subjects [though politics might not get a lot of place here but well, I'm a bit too much scatter-brained to say this boldly]