Polygon and texture accuracy

Started by
3 comments, last by Krypt0n 11 years, 9 months ago
I want to undestand polygon drawing accuracy. I'm looking for examples of polygon drawing methods with varying accuracy. With advantage with sample renderings so that the reader can understand, without running the code, how the accuracy differs between methods.

If possible I'm specifically looking for the inaccurate 500–600 kp/s (compared to the accurate 100 kp/s) drawing code employed in the Nintendo 64 RCP. And the PlayStation polygon drawing code that produce the for the PS characteristic uneven surface lines and polygon sides such as in this rendering where the lines on the ground, and all lines and polygon sides, are uneven.

I already know about the contents about polygon drawing in Graphics Programming Black Book, which only discuss accurate polygon drawing (accurate compared to the low accuracy avaliable for the N64 RCP and the PS GPU), so please suggest other sources than that. Update: Regarding perspective correction the Perspective Texture Mapping texts by Chris Hecker is a good resource.

Thanks!
Advertisement
I think what you're looking for is called "perspective correct rasterization" or "perspective correct interpolation". PSX does not have perspective correction, that's why textures look "uneven". not perspective correct is also sometimes called "affine texture mapping", some details: http://en.wikipedia.org/wiki/Texture_mapping
Thanks! I now understand that N64 has hardware texture perspective correction while Saturn and PS lacks it. Also, by drawing quadrilaterals instead of triangles the Saturn has less noticeable perspective distortion as in this side by side comparison.

But what about the polygon sides? Why are the polygon sides of the wooden crate in this rendering uneven?

And how does the N64 RCP 500–600 kp/s inaccurate polygon drawing differ from the accurate 100 kp/s polygon drawing?
The PSX used integer coordinates some place in its rendering pipeline to speed it up, which would make the vertices wobble slightly as they were moved across the screen. If that box is more than just 6 sides (the places the line changes being new polygons) then that would explain it
"in some places" :)
it actually used fixed point math all the way, there was no float hardware. even the meshes were already in that fixed point and could have that "uneven" vertex distribution due to the quantization of the positions.

another problem was that there was no clipping in hardware, you had to solve it yourself, there were various ways to handle it and you see all of those, depending on the game. you can
1. do software clipping in software, which required you to do integer divisions, possibly the slowest thing you could do
2. you could subdivide the mesh a few times or adaptive, depending on the poly count and mesh size,
3. you could drop polys if they'd cut the screen

I think Formula 1 97 was using 1. for the asphalt area and 2 for the surrounding grass area, I think I can recall that if you went off the track, you saw a lot of wobbling polys, while the track was always of quite good quality.
3 was used by 3rd person games, where you rarely get close enough to polys so they actually would need clipping while you really see those. I think in tomb raider you sometimes saw some polys disappearing.

yet another reason is the low precision of the rasterizers, that's doing less of the 'uneven' stuff, but it can cause double drawn pixels (which is noticeable for transparent polys) and also those famouse empty pixels between two triangles. to have proper rasterization on nowadays hardware, you need 48 to 53bits integers. clearly out of question at that time.

This topic is closed to new replies.

Advertisement