Well I first thought this too:
Quote: "
If the graphics card had to wait for all of the triangles to be sent before it started rendering then it'd spend a lot of time twiddling its thumbs waiting. Once it's recieved a set of triangles it tries to render them as soon as it can so it always keeps busy.
"
But I think there is a simple solution to this, namely pipelining:
While we retrieve the next set of triangles, we render the current set. or vice versa said: while rendering the current full set of triangles, we recieve the next full set of triangles... its quite the same as your description, and its using the same time, but does render everything in one go. after all there have to be calculated all triangles...
The use of the z buffer just makes the calculation smaller, I guess one could think of it as a "pre-result" that is stored and used for further computation. its easier math to project triangles and compare z buffer than to REALLY render a couple of triangles and determine the resulting POLYgon (note; poly can have more edges than just 3).
Still, I see no reason why z-buffering should prevent the card from correctly draw transparency. Why? well, if the pixel is transparent (meaning that at this rendered point the texture is black, or whatever color is set to be transparent) then it is just not drawn.
OK, you might say now, but you forget that the rendered triangle is not rendered 1:1, which means that the pixels on screen may represent several pixels on the texture (because of stretching, meaning the triangle is smaller, and / or not facing directly to the screen.
Well then, I answer, so I just store a third value for each pixel, the so called stencil buffer (I am purely guessing that this is the name for what I think of now
), which indicates that this pixel is semi-transparent. the color (first value) will then NOT be mixed with the background, but left to the color that the texture has there (without mixing it with the proper amount of black / background color). Getting complicated here, I admit, what do I do when another pixel is rendered above the just calculated one? well, I create a linked_list for that pixel. At the end, when everything has been rendered, I go through all pixels that have a linked list of transparency information (alpha is it called), and compute the final result for this pixel.
BANG! there you have that long waited fully functional and perfectly implemented transparency, alpha blending, and anti-aliasing effect!!! without any blue outline.
OK possible the use of the linked_list and its time overhead does prevent the graphic card industry to implement that approach (or maybe just because I lack crucial intellect and my here presented ideas are nothing else than pure, black, bull-ssssshh..)
Yea, but who knows that for sure
Btw, one year ago I was close to code a software 3d renderer, but we decided to make a Raytracer, since you get better looking result with also better render-speed... (if using mathematical describable objects, and not using 2 many triangles)
here you can have a look:
http://www.buss.org
it was a project-contest that was part of our course, and well, yea, we won the contest
now enough credits for me, I already talked too much, maybe too much nonsence too, so I go away and learn for my exams
greets,
Barnski
*edit: hmmm btw, do the movies in the cookies section on the page for you also look wrong/comic stylish?? or is it just that I need to get the latest wmv decoder for my mediaplayer
*
**edit2: no the files are OK, its just my win media player
**
-- I just started with DarkSDK, by translating DBP Projects. --
