Quote:Original post by robotichrist Like many graphics enthusiasts, I've tried out a number of methods for triangle rendering, and I strongly recommend using edge tables.
Thanks for the advice. I guess I have learned two things... 1. I am a graphics "enthusiast." 2. I should try out all the different approaches just to learn them.
Quote:Original post by chand81As Trenki has pointed out, the 3d transformations need to be correct. [...] Hope this helps.
This really helps. What I am learning as I write graphics code from scratch is this: If you do not really understand what is going on, you can not be sure that you are doing it right, and if there is a problem, and you don't really understand what you are doing, you are never going to be able to fix it.
Just knowing that the Z values after the perspective transform should be normalized helps a great deal. I did have a lot of trouble understaing that matrix code, mostly because of problems with right-hand vs left-hand systems, and then figuring out if the near and far values should be negative of positive. I think I have it working now...
OK, I have been working hard on understanding how to do the edge walking and edge tables. After studying these algorithms, it seems that no matter which one I choose, I need to be able to calculate the intersection of the polygon lines with each scan line. Which is another way of saying I need to find the intersection of two lines. I started down this path and figured out how this works.
Then I realized that in order to understand what the line drawing algorithms are doing, I needed to study them in greater detail, and so I have done that. I looked at Bresenham's, Po-Han Lin's EFLA (Extremely Fast Line Algorithm), and Gatopeich's line algorithm. Then I took everything I learned from that and created my own from scratch, which it not optimized (so it is easier to understand).
So I thought I was ready... Now I am stuck. Someone please tell me if I am on the right path here. If I just calculate the intersection of each scan line and the lines from the polygon, this does not really work. The problems is that for lines with very little distance between the y coordinates, but large distance between the x's, for example, (2,4) and (12,6), have many pixels on each scan line. Depending on which side of line is inside the polygon could change which of pixels should be the correct pixel to use for filling.
Currently, the intersections where Y is the longer side do not look the same as when X is the longer side, if all I am doing is calculation the intersection.
Also, after all of my research, it looks at thought I need to adopt a filling convention, such as leaving off the bottom and right pixels, so other polygons that share edges are not overdrawn.
If I am correct about the edges, or if I am not, please let me know.
You want to be doing scanline rendering. The active Edge Table is a method of doing scanline rendering that also incorporates visible surface determination, and also eliminates the need to pre-sort polygons.
Try getting hold of the Quake 1 source code. It does the edge stepping in fixed point.
An acceptable frame rate is perhaps 30fps which I manage to do just fine at 640x480x32, and that's only using BitBlt to put it on screen.
Quote:Original post by iMalc You want to be doing scanline rendering. The active Edge Table is a method of doing scanline rendering that also incorporates visible surface determination, and also eliminates the need to pre-sort polygons.
