Shading Instructions and Rasterizer !

[DavidGraham]

Hi guys , first I would like to tell you about how much I appreciate this forum , it is full of experts and good chunk of info .

I am an amateur to the computer and 3D world , I am interested in both , as such I have a few mysterious questions I would like to be answered , most of them are targeted at the very basics :

1-The Shading instruction , or any kind of instructions for that matter , are just Copy or Move or Go To instructions ? from what I know , computer instructions are no more than this , it is called instructions because it redirects memory information to specific locations to get them processed in a process , for example if the data is to be added the instruction is called 'Add' . Or to get them saved in another memory location (which would be called "Store Instruction" , am I right ?

2-In the Graphics Pipeline , I see a piece of Hardware called the Rasterizer ! from the every little that I know Vertex Setup happens first , where the GPU receives a good chunk of vertices , do matrix calculations on them by the shader cores , and then starts Interpolating colors in the process known as Rasterization , which -I assume- is handled by that Rasterizer , the thing here is that this bugger is only capable of Rasterizing one triangle per clock cycle , which is very low !

My Question here :
-Does Rasterizing occurs after Vertex Setup or before it ?
-Rasterizing a triangle means interpolating colors between it's vertices to generate pixels .. right ?
-If so , then the very low output of the Rasterizer will prevent the use of many shaders , as we will -have a limited amount of Pixels to perform lighting calculations on by the shader cores ..

3-About the Texture Mapping Units , I understand they are a different kind of hardware , completely different from Shader Cores , I also know that they are composed of texture filtering unit and a hardware for fetching addresses , I also understand that they do their filtering by means of interpolation , so the Component of TMUs is a hardware interpolator and a fetch address unit ?

Then what is the difference between them and the Special Function Units , they are able to interpolation too , why not share resources between the too ?

I am sorry if my questions are too long , I would appreciate getting the answers , as a general rule , I would really like the answer to start simple at first and then build up from that .

Thanks a ton !

[MDolenc]

1. I don't know what exactly do you mean but instructions are divided into several groups: arithmetic, input output and control flow. Since we're talking shading an example of IO instruction would be texture fetch. Note that graphics pipeline currently doesn't really allow you to arbitrary output stuff to memory.

2. I think that by "vertex setup" you actually mean triangle setup right? Vertex setup would IMO describe loading vertices onto the GPU which however is part of the pipeline called input assembly. So triangle setup is actually part of rasterization process and it is actually the first thing that happens. Generally triangle setup will first generate a list of pixels which fall inside a given triangle and for those pixels texture coordinates and such will be interpolated and pixel shaders executed.
One triangle per clock might seem low, however you should also realize that current high end hardware is able to draw 10M triangles per frame (and reject even more) with fairly high frame rates. And since triangles are usually larger then one pixel you'll be able to feed quite a few (pixel) shader cores.
To rasterize more then one triangle per clock you will need to figure out what to do when two triangles that are being rasterized in parallel overlap.

3. There are two kinds of interpolation happening in TMU. One is texture coordinate interpolation. This part is already done in general purpose shader core on ATI DX11 generation of GPUs. Filtering is second use of interpolation but this one still has dedicated hardware. Reason for this is that it rarely needs full precision and is very critical to performance.
And special functions unit is more or less a TMU.

[bridgman]

DavidGraham, if you download the R6xx_R7xx_3D.pdf document from http://www.x.org/docs/AMD/ that might give you a better picture of the overall flow. Look at the picture on page 8 and read page 7 as a start.

The process starts when the driver sends a list of vertices and information about how those vertices should be grouped to form triangles. The connectivity information can either be implicit (eg the driver sends groups of three vertices, each forming a triangle) or explicit (the driver sends a list of vertices plus a separate list of indices saying, for example, "the first triangle uses vertex #3, #9 and #5".

There are normally at least two different shader programs loaded into the GPU for each drawing operation - vertex shader and pixel shader.

The GPU runs a copy of the vertex shader program on each vertex independently, although many copies of the program run at the same time to get decent performance. The vertex shader program usually includes a lot of vector multiplies & adds to perform transformation, scaling, lighting etc...

The output of the vertex shader program is usually position information plus a heap of vertex attributes. The GPU then combines the processed vertices with the original connectivity information to form primitives (this step is called Primitive Assembly) and then breaks those primitives (usually triangles) up into groups of pixels for further processing. This is what the diagram on page 8 calls Scan Conversion.

The next step is to interpolate vertex parameters across the triangle (dedicated hardware on 6xx/7xx, done in the shader core on Evergreen) and then run a copy of the pixel shader program on each pixel, giving each copy of the shader program the appropriate interpolated values including texture addresses for each active texture along with depth information.

The pixel shader program then runs instructions like texture fetches and various math operations and outputs the result to the rest of the hardware pipeline (DB/CB on a 6xx/7xx part).

[DavidGraham]

I don't know what exactly do you mean but instructions are divided into several groups: arithmetic, input output and control flow. Since we're talking shading an example of IO instruction would be texture fetch. Note that graphics pipeline currently doesn't really allow you to arbitrary output stuff to memory.


I got it now :
-Arithmetic is like Add or Multiply , which means that the hardware does the actual processing on the data.
-Input/Output are like Load/Store ,which means that data is copied to a memory location from a previous location , the locations could be of any kind :RAM , Cache , Registers .
-Control Flow is like branching and conditional jump , also interrupting execution and hating .

Right ?

3. There are two kinds of interpolation happening in TMU. One is texture coordinate interpolation. This part is already done in general purpose shader core on ATI DX11 generation of GPUs. Filtering is second use of interpolation but this one still has dedicated hardware. Reason for this is that it rarely needs full precision and is very critical to performance.
And special functions unit is more or less a TMU.

Then what is the purpose of texture coordinate interpolation , isn't it a form filtering too ?

I know that filtering involves Bi-linear or Tri-linear interpolation or even Linear , it's purpose is to scale textures to fit the variable sizes of 3D objects , it is to my understanding that when interpolation is made , it works on both coordinates and colors .

If so , then why texture coordinates is done , to be specific why is it a separate process and for what purpose ?

[DavidGraham]

The output of the vertex shader program is usually position information plus a heap of vertex attributes. The GPU then combines the processed vertices with the original connectivity information to form primitives (this step is called Primitive Assembly) and then breaks those primitives (usually triangles) up into groups of pixels for further processing. This is what the diagram on page 8 calls Scan Conversion.


Since You mentioned vertex attributes and position , I would like to know about the reason for using the extra w parameter , I understand that location can be specified by X Y Z values , why add a fourth one ?

Also concerning lighting : what is the most common method used nowadays : Vertex or Pixel Lighting ? , by that I mean whether the GPU performs lighting on vertices or pixels , or both ?

The process of Lighting itself is a little confusing , it involves something called normal , what is normal exactly , by definition it means a perpendicular vector , but what really annoys me here is that vectors is a hard concept to grasp , not from the mathematical view , but from the hardware view . I know vertices are stored in a 4-way system inside the memory , using 32-bit or more , they go through the shader cores and undergo several processing to change the 4-way values into new ones , which in turn change the vertex screen position and attributes .

If so , how does a vector fit through the previous description , and how does all of this relate to the concept of "normal" ?

The pixel shader program then runs instructions like texture fetches and various math operations and outputs the result to the rest of the hardware pipeline (DB/CB on a 6xx/7xx part).
You summed this part perfectly , Thanks a lot :happy2:.

[Bob]

I understand that location can be specified by X Y Z values , why add a fourth one ?
Surprisingly, it makes the math easier(!). It lets you express most transforms using simple matrix multiplication. 4 is also a much nicer number for computers than 3 is.

Also concerning lighting : what is the most common method used nowadays : Vertex or Pixel Lighting ? , by that I mean whether the GPU performs lighting on vertices or pixels , or both ?
Usually, there's a combination of both being used: the VS computes part of the lighting equation, and the PS/FS evaluates it per-fragment.

it involves something called normal , what is normal exactly
The object rendered is rarely matches the polygonal representation. For example, to draw a sphere, you'd render a lot of little triangles. However, lots of little triangles are not the same as a sphere. The lighting would be all wrong if you rendered a lot of little triangles. It would look like those cheap Christmas ornaments (http://www.made-in-china.com/image/4f0j00gvOQbRcCYtqLM/Heat-Alarm-Christmas-Tree-Ball-KD-110.jpg).

So in addition to representing the sphere with a bunch of little triangles, surface normals are provided. However, the normals are computed such that they would really be normals from the original sphere model, and not just the mesh of triangles. With the real normal information, lighting for the sphere can be computed much more accurately.

Note that normals are not always generated from the original geometry. Sometimes, they are generated from the triangle meshes themselves ssome weighted averaging of the triangle's actual normals. This is not how normals should be computed, but the differences are usually very hard to spot.

[bridgman]

One of your questions was about how vectors are handled; they just get represented as a set of 3 or 4 numbers as well. The shader program or hardware knows the context of each set of numbers it gets, so it can treat the numbers as part of a vector, part of a vertex, part of a pixel, or just a number as appropriate.

If you think of a modern GPU as "something that does math really fast on short vectors", plus some dedicated hardware for things like scan conversion/rasterization and texture filtering, where shader programs provide a lot of the graphics-specific behaviour, that gives you a pretty good idea of how they work and why things like GPGPU are interesting.

re: texture coordinate interpolation vs filtering, the interpolation of texture coordinates is what lets each pixel pick up a different value from the texture. The application usually provides texture coordinates for each vertex, then the hardware interpolates those values and provides a different set of coordinates for each pixel to the pixel shader program. That is an example of how identical copies of a pixel shader program can produce different results for each pixel.

[Simon F]

Since You mentioned vertex attributes and position , I would like to know about the reason for using the extra w parameter , I understand that location can be specified by X Y Z values , why add a fourth one ?

Surprisingly, it makes the math easier(!). It lets you express most transforms using simple matrix multiplication. 4 is also a much nicer number for computers than 3 is.

"4 is a much nice number..." has got to be the worst explanation ever.:???: (The sphere as a triangle mesh explanation was good though)

@David: The 4 dimensional vectors are because the system will use "Homegeneous coordinates (http://www.unchainedgeometry.com/jbloom/pdf/homog-coords.pdf)". (Hmm that link was a perhaps too heavy - maybe try here for a nicer intro (http://www.teamten.com/lawrence/graphics/homogeneous/)) You'll encounter them in a standard course on Linear Algebra.

In essence, these allow you to combine all the many arbitrary rotations, scales, and translations needed to animate objects into a single transformation matrix. They also allow you to do most of the operations needed to for the 3D to 2D projection efficiently.

[Bob]

Worst ever? Oh please, you give me too much credit. I can come up with a lot of worse ones.

[Simon F]

Point taken. I stand corrected :)

[DavidGraham]

Usually, there's a combination of both being used: the VS computes part of the lighting equation, and the PS/FS evaluates it per-fragment.

You mean fragment shader ? what is the differnece between it and Pixel shader ?

The object rendered is rarely matches the polygonal representation. For example, to draw a sphere, you'd render a lot of little triangles. However, lots of little triangles are not the same as a sphere. The lighting would be all wrong if you rendered a lot of little triangles. It would look like those cheap Christmas ornaments (http://www.made-in-china.com/image/4f0j00gvOQbRcCYtqLM/Heat-Alarm-Christmas-Tree-Ball-KD-110.jpg).

So in addition to representing the sphere with a bunch of little triangles, surface normals are provided. However, the normals are computed such that they would really be normals from the original sphere model, and not just the mesh of triangles. With the real normal information, lighting for the sphere can be computed much more accurately.

Yes ! You mean the difference between Flat shading and Phong shading , right ?

[DavidGraham]

One of your questions was about how vectors are handled; they just get represented as a set of 3 or 4 numbers as well. The shader program or hardware knows the context of each set of numbers it gets, so it can treat the numbers as part of a vector, part of a vertex, part of a pixel, or just a number as appropriate.

You nailed it man , such a relieve , my pain can finally rest knowing that vectors have the same representation as vertices . :grin:

Question : Since the GPU handles many vertices position values , these values must relate to a fixed values on an axis (ie, the X or Y or Z axis) does the GPU need a global coordinates that are stored in memory , ot it just prcoess values and then compare them to Screen coordinates ?

re: texture coordinate interpolation vs filtering, the interpolation of texture coordinates is what lets each pixel pick up a different value from the texture. The application usually provides texture coordinates for each vertex, then the hardware interpolates those values and provides a different set of coordinates for each pixel to the pixel shader program. That is an example of how identical copies of a pixel shader program can produce different results for each pixel.
I get it now , :smile:

Another question concerning interpolation , supposedly we have a big triangle , whose 3 vertices have the color of Red , during color interpolation for the pixels inside that trinagle , the pixel in the middle would have a color of faint red , (due to the process of interpolation) , which is wrong ! wouldn't it just be easier if the vertices color was copied over to all the pixels inside the triangle ?

[DavidGraham]

@David: The 4 dimensional vectors are because the system will use "Homegeneous coordinates (http://www.unchainedgeometry.com/jbloom/pdf/homog-coords.pdf)". (Hmm that link was a perhaps too heavy - maybe try here for a nicer intro (http://www.teamten.com/lawrence/graphics/homogeneous/)) You'll encounter them in a standard course on Linear Algebra.

I tried to grasp the concept , but failed :cry: , must be due to my limited knowledge in mathematics (I am a biology student) , (and yes I am on the organic side not the synthetics :razz:) ..but all I could understand is that homogeneous coordinates help alleviate the problem of vectors that have the value of Zero (which could mess up matrix multiplication operations) , by introducing a fourth axis (w) which always have a value bigger than 0 .

[rpg.314]

You mean fragment shader ? what is the differnece between it and Pixel shader ?

The difference between a skedyule and shidule.

IOW, DX calls "this same thing" as pixel shader and OGL calls them fragment shaders.


Yes ! You mean the difference between Flat shading and Phong shading , right ?

Sort of, but not really.

Flat shading and Phong shading are shading models. Shading models tell you how to calculate the color of pixels/fragments. What was alluded to in that post was how doing more math can give you more accurate visuals. You can have more accurate models applied more coarsely, (say once per vertex instead of once per pixel) giving less accurate results overall.

[rpg.314]

I tried to grasp the concept , but failed :cry: , must be due to my limited knowledge in mathematics (I am a biology student) , (and yes I am on the organic side not the synthetics :razz:) ..but all I could understand is that homogeneous coordinates help alleviate the problem of vectors that have the value of Zero (which could mess up matrix multiplication operations) , by introducing a fourth axis (w) which always have a value bigger than 0 .

It seems you are trying to have a go at both 3D hardware and 3D software/rendering at the same time. Commendable goal, indeed. Assuming you are equally interested in both, I'd however suggest understanding 3D rendering/software/APIs first as then you will be able to understand 3D hardware and more importantly the "why" of 3D hardware.

The point of going to 4D vectors to represent 3D data is so that

1) 3D matrix-vector multiplication (for eg. rotation), 3D vector addition (for eg. translation) and perspective correction (ie, farther objects looking smaller) can be combined into 4D matrix-vector multiplication

2) this combination is useful as doing 1 'generic' thing many times is often simpler in hardware over doing many specialized things.

Initially, there was no 3D hardware and all this was done in highly optimized software. Slowly, more involved bit of the overall process began to migrate to hardware (aka evolution of gpu's) to increase overall speed. This process was complete by the time of Geforce 256, when it became possible to implement (almost?) the entire graphics pipeline in hardware.

At this time GPU's could do one and only one thing. 3D graphics. And on top of that, they could pretty much do it in only one way. (ie, they were fixed function)

From this point onwards, GPU's started becoming more flexible and allowed programmers to specify certain sequence of instructions (sugarcoated in nice shading languages like GLSL and HLSL) and started dropping the older fixed function hardware. This process was complete by the time of Geforce 6 series, which did all the "present day shading work" in software, but this time on GPUs.

HTH.

[DavidGraham]

The difference between a skedyule and shidule.
IOW, DX calls "this same thing" as pixel shader and OGL calls them fragment shaders.


Thanks for the clarification .

Flat shading and Phong shading are shading models. Shading models tell you how to calculate the color of pixels/fragments. What was alluded to in that post was how doing more math can give you more accurate visuals. You can have more accurate models applied more coarsely, (say once per vertex instead of once per pixel) giving less accurate results overall.
aha ! I see .

1) 3D matrix-vector multiplication (for eg. rotation), 3D vector addition (for eg. translation) and perspective correction (ie, farther objects looking smaller) can be combined into 4D matrix-vector multiplication

2) this combination is useful as doing 1 'generic' thing many times is often simpler in hardware over doing many specialized things.
That was truly helpful .. thanks man .
So it is just a mathematical way to combine different operations .. now I get it .

From this point onwards, GPU's started becoming more flexible and allowed programmers to specify certain sequence of instructions (sugarcoated in nice shading languages like GLSL and HLSL) and started dropping the older fixed function hardware. This process was complete by the time of Geforce 6 series, which did all the "present day shading work" in software, but this time on GPUs.

So those modern Shader cores are more flexible than the old fixed function vertex and pixel processors ?

I always thought that the old Pixel processors were small multipliers and the vertex processors were small adders .. is that true ?

If no , then how come those modern shader cores have the ability to do multiply and add operations at the same time ? is that possible in hardware ?(I mean to have small processors that contain adders and multipliers in the same die) If so .. then how this "hardware" would know if it needs to do multiply or add operations ?

also could you give it a look at these :

Question : Since the GPU handles many vertices position values , these values must relate to a fixed values on an axis (ie, the X or Y or Z axis) does the GPU need a global coordinates that are stored in memory , ot it just prcoess values and then compare them to Screen coordinates ?

Another question concerning interpolation , supposedly we have a big triangle , whose 3 vertices have the color of Red , during color interpolation for the pixels inside that trinagle , the pixel in the middle would have a color of faint red , (due to the process of interpolation) , which is wrong ! wouldn't it just be easier if the vertices color was copied over to all the pixels inside the triangle ?


I know I am asking a lot , thanks in advance ..

[Rys]

The difference between a skedyule and shidule.
IOW, DX calls "this same thing" as pixel shader and OGL calls them fragment shaders.
Technically there's a difference, since the rasterised triangle primitive might not cover the entire pixel. It's potentially a fragment, hence the name.

[MDolenc]

So those modern Shader cores are more flexible than the old fixed function vertex and pixel processors ?

I always thought that the old Pixel processors were small multipliers and the vertex processors were small adders .. is that true ?

If no , then how come those modern shader cores have the ability to do multiply and add operations at the same time ? is that possible in hardware ?(I mean to have small processors that contain adders and multipliers in the same die)

No... To do vertex transform you need both multipliers and adders (well dot products). You also need those for pixel shaders/multitexturing. The difference in old hardware was that pixel shaders/multitexturing could be lower precision while vertex shaders had to be 32 bit floating point even back then.
Another advantage of todays hardware is that it has unified shaders which means that hardware can asign shader cores for vertex shading, pixel shading,... depending on the load.


If so .. then how this "hardware" would know if it needs to do multiply or add operations ?

Well depends on what the program/shader says it wants.

[DavidGraham]

No... To do vertex transform you need both multipliers and adders (well dot products). You also need those for pixel shaders/multitexturing. The difference in old hardware was that pixel shaders/multitexturing could be lower precision while vertex shaders had to be 32 bit floating point even back then.

I see , by lower precision you mean 16 bit ?

There is something itching me though .. can each core do a single MUL or Add per clock , or is it the whole block/sub-block of cores ?

[Rys]

Depends what you call a core. On a current generation NV GPU, a core is made up of three blocks, each one running the same instruction each on a set of pixels (eight) in a given clock, in lock step. But that's three potentially different instructions in a clock per core there. Previous unified hardware was two, Fermi is two.

For ATI, the core (ATI call it a SIMD) will process 16 pixels per clock, with potentially 5 different instructions per pixel in that clock, but the same 5 instructions for each pixel, in lock step.

As for lower precision, yes, FP16 and FP24 have variously been the common floating point precision in programmable hardware in recent years for pixel shading, with FP32 mandatory in recent generations. There are various other different precisions at work across the chip depending on what's being computed (both very high and quite low), but for the generally programmable logic in a modern unified architecture is heavily 32-bit, integer or float.

[DavidGraham]

Depends what you call a core. On a current generation NV GPU, a core is made up of three blocks, each one running the same instruction each on a set of pixels (eight) in a given clock, in lock step. But that's three potentially different instructions in a clock per core there. Previous unified hardware was two, Fermi is two.

For ATI, the core (ATI call it a SIMD) will process 16 pixels per clock, with potentially 5 different instructions per pixel in that clock, but the same 5 instructions for each pixel, in lock step.

I am sorry I got a little confused ! what is lock step ?

And by cores you mean like CUDA cores (I know it sounds cheesy) , or the whole block of 8 shader processors ? I am guessing the latter .

As for lower precision, yes, FP16 and FP24 have variously been the common floating point precision in programmable hardware in recent years for pixel shading, with FP32 mandatory in recent generations. There are various other different precisions at work across the chip depending on what's being computed (both very high and quite low), but for the generally programmable logic in a modern unified architecture is heavily 32-bit, integer or float.
I got that part very well , thanks you alot sir .

[MDolenc]

Progression of precision in "pixel shaders" went from sub 8 bits per component (integer) to 8 bits per component (integer) to more then 8/10 bits per component (integer) and 16 bit floating point per component to 32 bit integer/float per component and over (double precision floating point in DX11).

And yes, each core can do a single mul, add, (4D) dot product, multiply add,... per clock. Though that's technically not entirely correct. Instructions are pipelined so results won't be immediately availible. If you were to issue a single add you'd get result back after say four clocks. However you can issue a new instruction (n) every clock and get a result of instruction (n-4) every clock.
Block/sub-block of cores (depending on what exactly you mean by that) is more or less helping to schedule everything efficiently/cheaply.

[Rys]

I am sorry I got a little confused ! what is lock step ?
It's just a different way to say "in sync". So all of the units are executing a MUL in the same clock, for different pixels, for example.

And by cores you mean like CUDA cores (I know it sounds cheesy) , or the whole block of 8 shader processors ? I am guessing the latter .
Correct, the latter. NVIDIA abuse the word core when they say CUDA core. On a GT200 for example, with 240 ALUs, 24 to a core (3 sub blocks of 8, as discussed previously), there are 10 cores. For ATI, each modern thing we'd call a core (usually) has 80 ALUs, so 20 cores for their Cypress chip.

[DavidGraham]

Progression of precision in "pixel shaders" went from sub 8 bits per component (integer) to 8 bits per component (integer) to more then 8/10 bits per component (integer) and 16 bit floating point per component to 32 bit integer/float per component and over (double precision floating point in DX11).

I see that it was very gradual .. thanks for the detail .
And yes, each core can do a single mul, add, (4D) dot product, multiply add,... per clock. Though that's technically not entirely correct. Instructions are pipelined so results won't be immediately availible. If you were to issue a single add you'd get result back after say four clocks. However you can issue a new instruction (n) every clock and get a result of instruction (n-4) every clock.

Aha , I see , now I understand that concept differently , thank you guys a lot .


Now back to those question please :
Question 1 : Since the GPU handles many vertices position values , these values must relate to a fixed values on an axis (ie, the X or Y or Z axis) does the GPU need a global coordinates that are stored in memory , ot it just prcoess values and then compare them to Screen coordinates ?

Question 2 : concerning interpolation , supposedly we have a big triangle , whose 3 vertices have the color of Red , during color interpolation for the pixels inside that trinagle , the pixel in the middle would have a color of faint red , (due to the process of interpolation) , which is wrong ! wouldn't it just be easier if the vertices color was copied over to all the pixels inside the triangle ?

Question 3 : what is "lock step" Rys was referring to ? is it the same thing as pipelining ?

[Rys]

Question 2 : concerning interpolation , supposedly we have a big triangle , whose 3 vertices have the color of Red , during color interpolation for the pixels inside that trinagle , the pixel in the middle would have a color of faint red , (due to the process of interpolation) , which is wrong ! wouldn't it just be easier if the vertices color was copied over to all the pixels inside the triangle ?
The pixel colour would be red too.

[DavidGraham]

It's just a different way to say "in sync". So all of the units are executing a MUL in the same clock, for different pixels, for example.
Aha , I get it now .
Correct, the latter. NVIDIA abuse the word core when they say CUDA core. On a GT200 for example, with 240 ALUs, 24 to a core (3 sub blocks of 8, as discussed previously), there are 10 cores. For ATI, each modern thing we'd call a core (usually) has 80 ALUs, so 20 cores for their Cypress chip
They do abuse these concepts a lot indeed, I was very confused about what's going on , until you guys came and enlightened me , I really can't express my feelings right now .. talk about pure scientific excitement !

We can ignore the Question number 3 then , and move on to number 1 and 2 : about the where about of global coordinates (does it even exist ?) and the use of color interpolation which could give unneeded results .

[DavidGraham]

The pixel colour would be red too.
How ? Interpolation is a way of finding intermediate points , and ..wait .. if the points are the same , then there wouldn't be a need for intermediate points ! that is right ! how stupid could I be ? I am sorry , you are right , I must have confused it with something else . :???:

Then what about Global Coordinates , are they necessary , I mean should they be established the first thing before rendering ?

[Rys]

If I understand you correctly with regards to question one, there's a final projection of the geometry to the screen before it's drawn, which gives you your screen-space xyz to work with during rasterisation and shading. That screen space would be your global coords.

As for question two, I guess the hardware would optimise away the calculation of the interpolant if it's not needed (vertex colour attributes are constant across the triangle in this case), but I'm not actually sure. Hardware guys, does this happen?

[MDolenc]

[I]Question 1 : Since the GPU handles many vertices position values , these values must relate to a fixed values on an axis (ie, the X or Y or Z axis) does the GPU need a global coordinates that are stored in memory , ot it just prcoess values and then compare them to Screen coordinates ?
I'm not sure what exactly do you mean here... Everything GPU needs is hidden in three matrices: "world", "view" and "projection" which gets multiplied into one matrix on CPU which then gets passed to GPU and then GPU will multiply incoming vertex positions by this matrix. Note that this is the simplest of cases and even vertex shaders can get VERY complex if you add animation and/or per vertex lighting into the mix.
However this is just "boring" linear algebra. :) When vertices come into the pipeline they are in some random local space (object space) where each object has it's origin in it's center (for example). And after they get multiplied (transformed) by this matrix they end up in screen space.
Why would some global coordinates be needed?


Question 2 : concerning interpolation , supposedly we have a big triangle , whose 3 vertices have the color of Red , during color interpolation for the pixels inside that trinagle , the pixel in the middle would have a color of faint red , (due to the process of interpolation) , which is wrong ! wouldn't it just be easier if the vertices color was copied over to all the pixels inside the triangle ?

Yeah, but how do you know that all three colors are the same? It would be expensive to check and since 90% of the time you're really dealing with different values also redundant. And as it was already pointed out the center would still be red.
The kicker here is however that that these values (vertex colors, texture coordinates) are not actually interpolated per se. Rasterizer determines how fast the value is changing (gradient) over a given triangle and simply adds this change to the starting value for each rasterized pixel when it "walks" over the triangle.

[Simon F]

@David:
For your "question 2", if you have 3 vertices of the triangle, A B & C, that have have some attribute, say, the red colour component, Ra, Rb & Rc, then at any pixel in the triangle then you will have
Rpixel = w1 * Ra + w2 * Rb + w3 *Rc
where
w1 + w2 +w3 = 1
and all ws are between 0 and 1.

[Davros]

ang on what does w represent ?

[Simon F]

The w values are, in effect, give the position on the surface of the triangle.

[DavidGraham]

If I understand you correctly with regards to question one, there's a final projection of the geometry to the screen before it's drawn, which gives you your screen-space xyz to work with during rasterisation and shading. That screen space would be your global coords.

You did understand me correctly , thanks for the answer .:smile:

Another Question :
In your article : http://www.beyond3d.com/content/reviews/51/2 , in which you reviewed GT200 archeticture you mentioned that each Cluster contains 3X8 FP32 Scalar ALU , and 3X8 FP32 Scalar Interpolator ! .. are those the Special Function Units ?

[DavidGraham]

I'm not sure what exactly do you mean here... Everything GPU needs is hidden in three matrices: "world", "view" and "projection" which gets multiplied into one matrix on CPU which then gets passed to GPU and then GPU will multiply incoming vertex positions by this matrix. Note that this is the simplest of cases and even vertex shaders can get VERY complex if you add animation and/or per vertex lighting into the mix.

So the Global Matrix (supposedly) is a combination of 3 things : World View and Projection , is that right ?

When vertices comeinto the pipeline they are in some random local space (object space) where each object has it's origin in it's center (for example). And after they get multiplied (transformed) by this matrix they end up in screen space.

So each object has it's own coordinates , after being transformed , it ends up in the screen space , which we could call it the global coordinates , right ?

If so , then are the screen coordinates the same as projection coordinates ?

The kicker here is however that that these values (vertex colors, texture coordinates) are not actually interpolated per se. Rasterizer determines how fast the value is changing (gradient) over a given triangle and simply adds this change to the starting value for each rasterized pixel when it "walks" over the triangle
I am sorry , but could you please elaborate more on this subject ? I didn't get it :sad: .

[DavidGraham]

@David:
For your "question 2", if you have 3 vertices of the triangle, A B & C, that have have some attribute, say, the red colour component, Ra, Rb & Rc, then at any pixel in the triangle then you will have
Rpixel = w1 * Ra + w2 * Rb + w3 *Rc

And since Ra = Rb = RC , then :

Rpixel = (w1 + w2 + w3) R .
but I didn't get what that is supposed to do ? what is the relation between the surface of the triangle (W) and pixel color ?

[rpg.314]

And since Ra = Rb = RC , then :

Rpixel = (w1 + w2 + w3) R .
but I didn't get what that is supposed to do ? what is the relation between the surface of the triangle (W) and pixel color ?

Ra=Rb=Rc is a very special case. It is far more common to have all three different.

[DavidGraham]

Ra=Rb=Rc is a very special case. It is far more common to have all three different.
I still don't get it , why is it such a rare case , is it that strange to have one little red triangle ?
I am serious !

[bridgman]

I guess there are two main reasons :

1. Apps rarely draw triangles in isolation - they use triangles to model real world objects which usually have varying colors across their surfaces, and those varying colors usually result in the vertices of each triangle being different as well.

2. Even if you were drawing a "solid red thing", lighting effects (performed in the vertex shader) would frequently result in having different brightness levels for each vertex.

If I may offer (repeat) some advice, you'll have a much easier time understanding the hardware once you have a bit more familiarity with the software. Picking up a decent book on OpenGL and actually running some simple programs on your PC will make all this (especially the coordinate space stuff) seem a lot more clear.

[DavidGraham]

I guess there are two main reasons :

1. Apps rarely draw triangles in isolation - they use triangles to model real world objects which usually have varying colors across their surfaces, and those varying colors usually result in the vertices of each triangle being different as well.

2. Even if you were drawing a "solid red thing", lighting effects (performed in the vertex shader) would frequently result in having different brightness levels for each vertex.

Thanks , I think I can settle with this explanation .

If I may offer (repeat) some advice, you'll have a much easier time understanding the hardware once you have a bit more familiarity with the software. Picking up a decent book on OpenGL and actually running some simple programs on your PC will make all this (especially the coordinate space stuff) seem a lot more clear.
Advice Appreciated :smile:, I am willing to do just that , but I am under the impression that being good in software (designing and writing code) doesn't necessarily mean understanding things , and by that I mean the deep-gut understanding , which gives you the ability to visualize what is going on in your mind .

[Simon F]

If I understand you correctly with regards to question one, there's a final projection of the geometry to the screen before it's drawn, which gives you your screen-space xyz to work with during rasterisation and shading. That screen space would be your global coords.
Personally, I would not describe screen space as being the same as global coordinates. To me, global coordinates are used to assemble all the models etc into the same coordinate space and for doing, say, lighting calculations and perhaps collision detection.

Screen coordinates are in pixel dimensions and are used for rasterisation.

[rpg.314]

Thanks , I think I can settle with this explanation .


Advice Appreciated :smile:, I am willing to do just that , but I am under the impression that being good in software (designing and writing code) doesn't necessarily mean understanding things , and by that I mean the deep-gut understanding , which gives you the ability to visualize what is going on in your mind .

Sure, you can understand things reasonably well without writing code. But writing/running/experimenting with lots of non-toy code is essential to have a deep-gut understanding.

[Rys]

Personally, I would not describe screen space as being the same as global coordinates. To me, global coordinates are used to assemble all the models etc into the same coordinate space and for doing, say, lighting calculations and perhaps collision detection.

Screen coordinates are in pixel dimensions and are used for rasterisation.
Agreed, I could have answered a bit better outside of the context of the question.

[DavidGraham]

Personally, I would not describe screen space as being the same as global coordinates. To me, global coordinates are used to assemble all the models etc into the same coordinate space and for doing, say, lighting calculations and perhaps collision detection.

Screen coordinates are in pixel dimensions and are used for rasterisation.
Ok , I get it , what I don't get however , is the hardware location for storage of those global coordinates ? where is it exactly ? in the memory ?

Agreed, I could have answered a bit better outside of the context of the question.
Mr.Rys , would you be kind and answer this question :
In your article : http://www.beyond3d.com/content/reviews/51/2 , in which you reviewed GT200 archeticture you mentioned that each Cluster contains 3X8 FP32 Scalar ALU , and 3X8 FP32 Scalar Interpolator ! .. are those the Special Function Units ?

[Rys]

Yeah, the SFU is responsible for interpolation for the rest of the SM in that generation of their hardware.

[DavidGraham]

Yeah, the SFU is responsible for interpolation for the rest of the SM in that generation of their hardware.
but that means there are 24 SFUs (3X8) per cluster ! I thought there were only six !

[Rys]

Throughput is 1/4 rate :)

[DavidGraham]

Throughput is 1/4 rate :)
Aha ! I see :smile:.
so these units are not pipelined ?
to further elaborate on my question : for example the shader cores in GT200 (8 Units per block) might have a throughput of one multiply instruction per 4 clocks , but because they are pipelined , it is countable as one instruction per cycle , is the same applicable on those SFUs ?

[Rys]

The units are pipelined, but they do take four clocks to compute the result too. If you're keen on talking more about a specific vendor's hardware, we should probably setup a new thread so this fairly pure one stays that way :smile:

[DavidGraham]

The units are pipelined, but they do take four clocks to compute the result too. If you're keen on talking more about a specific vendor's hardware, we should probably setup a new thread so this fairly pure one stays that way :smile:
Okay :grin: .. let's keep this thread as it is , I will be back with more "pure" questions once I nourish my 3D knowledge with reading .. but I will put a pin on that question , it will be brought back to light in a new thread once this one is done :cool: .

Of course I can't express my gratitude enough , thank you very much .

[DavidGraham]

Ok I came across another thing that I don't understand :
It's about texture coordinates , each texel has a 4-way coordinate system , Now I realize that each texel is in fact a 2D color , and it's color is represented using the usual RBGA System , the question is: why use a 4-way coordinate system on a 2D point ?

[Simon F]

Personally, I would not describe screen space as being the same as global coordinates. To me, global coordinates are used to assemble all the models etc into the same coordinate space and for doing, say, lighting calculations and perhaps collision detection.

Screen coordinates are in pixel dimensions and are used for rasterisation.
Ok , I get it , what I don't get however , is the hardware location for storage of those global coordinates ? where is it exactly ? in the memory ?
Global coordinates might not be "stored" anywhere. They might only exist temporarily in a shader program.

[DavidGraham]

Global coordinates might not be "stored" anywhere. They might only exist temporarily in a shader program.
I see , but that would still count as being in "memory " , whether it is System RAM or registers , right?
What about this question then :
It's about texture coordinates , each texel has a 4-way coordinate system , Now I realize that each texel is in fact a 2D color , and it's color is represented using the usual RBGA System , the question is: why use a 4-way coordinate system on a 2D point ?

[MDolenc]

I see , but that would still count as being in "memory " , whether it is System RAM or registers , right?
What exactly do you mean by "global coordinates"? If you talk about transform matrices then they will usually be stored in "constant" buffers which reside somewhere in memory (either CPU or GPU) and get uploaded to GPU cache when used.

It's about texture coordinates , each texel has a 4-way coordinate system , Now I realize that each texel is in fact a 2D color , and it's color is represented using the usual RBGA System , the question is: why use a 4-way coordinate system on a 2D point ?
You don't always deal with just 2D coordinates. You can have 3D textures, projected 2D textures, cube maps,... Not to mention that this is the only way for vertex shaders to talk to pixel shaders and any data you want to pass over has to go through here. These are also quite limited resources. SM 3.0 can pass 10 4D vectors, SM 4.0 16 4D vectors and SM 4.1/5.0 32 4D vectors. Of course hardware might deal faster with 2D vectors then it does with 4D vectors.

[DavidGraham]

What exactly do you mean by "global coordinates"? If you talk about transform matrices then they will usually be stored in "constant" buffers which reside somewhere in memory (either CPU or GPU) and get uploaded to GPU cache when used.

Yes , (sigh) I meant the transform matrix , thanks for the fulfilling answer .:runaway:

You don't always deal with just 2D coordinates. You can have 3D textures, projected 2D textures, cube maps,... Not to mention that this is the only way for vertex shaders to talk to pixel shaders and any data you want to pass over has to go through here. These are also quite limited resources. SM 3.0 can pass 10 4D vectors, SM 4.0 16 4D vectors and SM 4.1/5.0 32 4D vectors. Of course hardware might deal faster with 2D vectors then it does with 4D vectors
Thanks again for the excellent answer .

[DavidGraham]

Alright I am back !

I have been reading about Lighting for a while now , the problem is that I gathered most of my knowledge from different sporadic sources , without a consistent organized supply of info , so my understanding of the concept still has massive holes , I plan to fill them by asking you guys .

First , as I understand it , objects that need to be lit has some pre-defined characteristics , like Ambient , Emissive , Specular .. etc , these factors are like colors , they are used to alter the interaction between the light and the object .

To put it simply , they are like certain color modifiers , if an object has a value of 4 in it's Ambient criteria , then it behaves in a certain way when exposed to light , for example , when exposed to a green light , the object would always gain a dark color .

Q1 : Is my understanding of that concept here correct ?

Secondly , the process of calculating light boils down to two basic operations : determining distance and angles .

it starts with creating a normal for the triangle needed to be lit , then the distance between that triangle and the light source is calculated , and since lighting occurs after Rasterization , it is basically done in 2D mode , and the distance is calculated simply by subtraction , for example , the distance between point 9 and point 3 is 6 ! , 9-3=6 .

The value of the distance is then treated as a Vector , and the angle between that vector and surface normal is calculated by the Cosine law .

kinda like this picture :
http://www.c-h-i.org/images/technology/ptm/normals_02.gif

Finally , the color of the triangle is calculated from the equation : L(luminance of light source)X Angle .

Q2 : Is my understanding of this concept correct ?

Q3 : Tf it is correct , then where the (emissive , specular , ambient ) criteria fit in ? after or before the luminance equation ?

thanks in advance .

[MDolenc]

That's a bit complex subject but here it goes:
What you are describing is called Lambertian reflectance. It comes from observation that a ray of light hitting an object will be alot more spread out if it hits an object at a shallow angle (so angle between N and L is high => N.L is close to zero) compared to that same ray hitting an object at right angle (angle between N and L is near 0 => N.L is close to one). This is also independent of observer position. This is called diffuse term.

This of course is just an approximation and actual lighting is far far more complicated then that. The first obvious problem is that some materials (plastics, metalic colors on cars,...) reflect far more light in one direction, so material tends to shine when you look at it from correct angle. This is called specular term and is obviously dependant observer location (so it's view dependant). This is again just an simplification and far more complicated materials can be found (such as CD and DVD media for example).

Probably the most complicated (or evil if you will) of all is the ambient term. This simulates lighting that came from the environment. If you park your car into a garage without any windows or lights on a sunny day you'll still see your car just fine even though none of the photons comming from the sun hit your car directly. They hit you car indirectly (hence the name indirect lighting). They might have bounced of you neighbours house and then of your car and into your eye. This is what global illumination algorithms are trying to solve. Generally this is to complicated for real time and it is just replaced by a constant color.

So your pixel will be something like: color = ambientcolor + diffusecolor + specularcolor

it starts with creating a normal for the triangle needed to be lit , then the distance between that triangle and the light source is calculated , and since lighting occurs after Rasterization , it is basically done in 2D mode , and the distance is calculated simply by subtraction , for example , the distance between point 9 and point 3 is 6 ! , 6-3=9.

Not true. Lighting can be done per vertex (and intepolated) or per pixel. In both cases you need distance from your 3D sample position to your 3D light position (light direction vector). You will calculate this light direction vector + distance (sqrt(lightdir dot lightdir)) per vertex and pass it on through interpolators to pixel shader. Normals are again either per vertex or per texel (packed in texture called normal map).

[DavidGraham]

First of all thanks for your time and your highly detailed answer ..

This of course is just an approximation and actual lighting is far far more complicated then that
Of course I understand that the actual lighting in real life is far more complicated , I also understand that the values of ambient+diffuse+specular are just approximations , however , I presume that these values are pre-defined by the game developer , they might be stored in a database or something .. right ?

So your pixel will be something like: color = ambientcolor + diffusecolor + specularcolor
In this case , are you talking about color before lighting calculations are performed , or after ?

Not true. Lighting can be done per vertex (and intepolated) or per pixel.
Yes that is correct , I chose triangles for the simplicity sake

You will calculate this light direction vector + distance (sqrt(lightdir dot lightdir)) per vertex
And by distance per vertex you mean the angle ?

Normals are again either per vertex or per texel (packed in texture called normal map)
You mean that normals of texels are pre-calculated offline and stored in something called a normal map .. right ? , I don't suppose the same applies to vetices do I ?

Again , I can't thank you enough for your detailed insights .

[curious.trier]

I presume that these values are pre-defined by the game developer , they might be stored in a database or something .. right ?

It can be done both ways. IE precomputed offline and stored or computed on the fly.

In this case , are you talking about color before lighting calculations are performed , or after ?

He's saying that lighting calculations can be done either before (per vertex lighting) or after (per pixel lighting) rasterization.

Color of a pixel is always determined after lighting calculations have been done.

And by distance per vertex you mean the angle ?

No, distance means just that. Distance. As in distance bw LA and NY.

[DavidGraham]

It can be done both ways. IE precomputed offline and stored or computed on the fly.
the way I understand it , is that these values are just values to alter the outcome of lighting calcualtions , they don't need to be calculated themselves , they only need to be determined.

it's like saying that the frequency factor alters the outcome of a sound sample , by setting the value of frequency higher , the sound becomes high pitched , by tuning the value down , the sound changes accordingly .


He's saying that lighting calculations can be done either before (per vertex lighting) or after (per pixel lighting) rasterization. I know that , I am asking whether the values of Ambientcolor + diffusecolor + specular color are incorporated before or after the lighting calcualtions ?

No, distance means just that. Distance. As in distance bw LA and NYPlease elaborate on this point .. what is the use of distance per vertex ?

[curious.trier]

I know that , I am asking whether the values of Ambientcolor + diffusecolor + specular color are incorporated before or after the lighting calcualtions ?


calculating Ambient color + diffusecolor + specular color is the lighting calculation.

Please elaborate on this point .. what is the use of distance per vertex ?

The farther you go from light sources, the weaker they become. So for an accurate lighting calculation, strength of each light source at that point is also considered.

[DavidGraham]

calculating Ambient color + diffusecolor + specular color is the lighting calculation.
How ? we were just talking about distances and light vectors and all that stuff , where do these ambient+diffuse+specular values fit in ?

The farther you go from light sources, the weaker they become. So for an accurate lighting calculation, strength of each light source at that point is also considered.
Oh , I get it now , you mean the distance between the light source and a specific vertex , but isn't that the same as the light direction vector ?

[MDolenc]

How ? we were just talking about distances and light vectors and all that stuff , where do these ambient+diffuse+specular values fit in ?
This is the lighting equation! Ambient component can be as simple as a constant color (say dark red) or as complex as global illumination solution that took 2 months offline to compute. Diffuse is what you originaly came up with: normal dot lightdirection. Specular can be something like: (normal dot halfangle)^n where halfangle is a vector half way between light direction and viewer direction and n is the "shines" factor.
All of this are also multiplied by light color (diffuse and specular component), material color (diffuse, specular and ambient component for example). Diffuse and specular are also multiplied by attenuation factor (that's where the distances come in) and possibly shadow values from shadow buffers.
All this is lighting equation.

Oh , I get it now , you mean the distance between the light source and a specific vertex , but isn't that the same as the light direction vector ?
Direction is a vector, distance is a scalar. But yeah, you can calculate distance from an unnormalized light direction vector.

[DavidGraham]

Thanks MDolenc and curious.trier , you both have been of a great help .. I can't thank you guys enough :smile: .

I will be back with more questions though , don't let your guards down !:grin:

[DavidGraham]

I stumbled across something called deferred lighting , and I had a hard time understanding it completely , it has something to do with applying lighting as a 2D post process filter .

Q1 ? does that mean that in contrast to forward lighting where lighting is done with 3D coordinates , deferred lighting happens truly in 2D ? then how ?

Q2 ? Why can't we apply Anti-Aliasing in deferred lighting ?

Q3 ? what is the use of depth or normal buffer in this method ?

Q4 ? What is the definition of post processing in general ? I would like a quick overview of what is going on behind it .

[AlexV]

http://www.beyond3d.com/content/articles/19/1

[rpg.314]

I stumbled across something called deferred lighting , and I had a hard time understanding it completely , it has something to do with applying lighting as a 2D post process filter .

Q1 ? does that mean that in contrast to forward lighting where lighting is done with 3D coordinates , deferred lighting happens truly in 2D ? then how ?

Deferred lighting means visibility has been completely resolved. Here we defer lighting calculations until *all* geometry for a frame has been rendered. This way we don't do lighting for invisible fragments. It is in 2D because your frames are ultimately 2D.

Q2 ? Why can't we apply Anti-Aliasing in deferred lighting ?

Hardware limitation, resolved in DX10.1

Q3 ? what is the use of depth or normal buffer in this method ?

Normals are needed for lighting. Depth is needed to resolve visibility of objects.

Q4 ? What is the definition of post processing in general ? I would like a quick overview of what is going on behind it .

Post processing is,

a) render a frame's geometry
b) take the rendered frame as a texture and treat it like a 2D image
c) apply some 2D effects like motion blur, focal blur etc.

[DavidGraham]

Deferred lighting means visibility has been completely resolved. Here we defer lighting calculations until *all* geometry for a frame has been rendered. This way we don't do lighting for invisible fragments. It is in 2D because your frames are ultimately 2D
Thanks for the nice and straight answer .. :smile:

Post processing is,
a) render a frame's geometry
b) take the rendered frame as a texture and treat it like a 2D image
You mean this happens before Rasterization ? ie on vertices not pixels ?

[rpg.314]

You mean this happens before Rasterization ? ie on vertices not pixels ?

No, all of it happens after pixel shading has been done. Vertices are in 3D, not 2D, then how can you treat it as texture.

I really think you should start playing with 3D code. Simple Nehe Stuff will do fine, doesn't have to be too big or fancy. I can see that there are a lot of half baked concepts in your mind. Playing with code, (even a little bit) will increase your learning efficiency easily by an order of magnitude. It's simply a better way to spend your learning time.

[DavidGraham]

Thanks for the answer , really appreciate your help , I will certainly try to start some coding , the thing is , I am quite busy with studying Medicine , this thing is so damned big it doesn't leave much room for anything else , however I will do my best to make room for coding .


I really think you should start playing with 3D code. Simple Nehe Stuff will do fine, doesn't have to be too big or fancy.
Any suggestions ?

[rpg.314]

Head over to nehe.gamedev.org

Start following their tutorials. Great place to start for anyone. You'll need to know C/C++.

[DavidGraham]

Head over to nehe.gamedev.org

The site is not working , I don't know why ..

Start following their tutorials. Great place to start for anyone. You'll need to know C/C++
Aha ! I knew I was walking into a trap :razz: ! I know nothing of C or C++ !
Does OpenGL coding needs C++ knowledge ?

I am a complete noob in coding .. I have never done any of it before.

[rpg.314]

You will need atleast one programming language, preferably a popular one.

[rpg.314]

Sorry,
this was the right link
http://nehe.gamedev.net/

[Fusion]

Does OpenGL coding needs C++ knowledge ?
OpenGL as you know is a graphics library containing some graphics functions that help the programmer draw 2D/3D scenes. To be able to use (call) these functions, you need to learn a programming language as rpg said.

I recommend C++ (lots of resources). Online tutorials are available and you can start with MIT's Introduction to C++ (http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-096January--IAP--2009/LectureNotes/index.htm) course and/or this tutorial (http://www.cplusplus.com/files/tutorial.pdf).

Use Dev-C++ (http://www.bloodshed.net/dev/devcpp.html) free compiler to apply the codes in the tutorials. After learning the basics of C++, add the GLUT package (http://www.nigels.com/glt/devpak/) to the compiler, then follow NeHe (http://nehe.gamedev.net/) tutorials and download the codes written for Dev-C++ at the end of each lesson.

Btw, thanks for this informative topic and please keep asking :smile:

(I think I know you very well dear Dr.H :wink:)

[MrGaribaldi]

I'd recommend using FreeGLUT instead of GLUT, since it is actively maintained and will allow you to work with OpenGL 3.x, both are available from Fusions GLUT link.

Also, Dev-C++ doesn't look like it has been updated for a few years, so you might want to look at alternatives, be it Visual Studio C++ Express or Code::Blocks or similar.

Good luck!

[DavidGraham]

Thanks for the great help rpg.314 , Fusion , MrGaribaldi .. I will let you know on my progress with C++ .

@Fusion , I had my doubts about you the moment I I laid my eyes on your nickname and this thread (http://forum.beyond3d.com/showthread.php?t=55644).. now I know for sure ..:grin:

Glad I found someone that I belong to in this great community ..