Decade old question reguarding the first realtime 3d implementations.

[JigenD]

I'm not sure how to best express this because I've never had anything approaching an expanation of this (in my mind). But I've wondered about it for over 10 years and I'd like to finally get an answer.

This is reguarding the techniques used in the first real-time 3d (game based) graphics. That is, some of the first arcade games using 3d (that also used texture mapping), also Saturn and Playstation 1, and possibly some previous systems.

It was a artifact you almost always saw in the graphics, what it appeared to be was 'warping' polygons. As you moved polygons all around the screen would seem to shift points, it looked worse at the 'camera' where the polygons would sometimes 'push up flat' against the camera, basically warping from their correct positions.

Everything N64 and beyond (3d acceleration) got rid of this artifact.

It's not related to point sampling (filtering), because you can run a current game with point sampling and not get the artifcat. I don't think it's due to Z-buffering, because I think that has to do more with larger distances...

Anyways, I think about this unexplained (to me) phenomenon from time to time, and I'd like to finally understand what caused this. AFAIK the techniques for realtime 3d has always been rasterization and I don't know why the early 3d games looked this way.

Thanks for any attempts to clear up this mystery for me.

[Fruitfrenzy]

I think what you are describing is perspective correct texturing that the early implementations didn't have and everything later does.

I believe it is to do with how you iterate over the texture coordinates within a polygon. The early implementations just did a linear iteration but to avoid the artefact you describe you need to iterate faster as z increases.

[JigenD]

I think what you are describing is perspective correct texturing that the early implementations didn't have and everything later does.

I believe it is to do with how you iterate over the texture coordinates within a polygon. The early implementations just did a linear iteration but to avoid the artefact you describe you need to iterate faster as z increases.

I think that's probably it. I heard a lot of that term thrown around with the first PC 3d accelerators and the N64...

Was it that the textures ignored perspective but the polygons used true perspective?

[Fruitfrenzy]

As I understand it you need to do a divide to properly convert from 3d coordinates to 2d screen coordinates. That is unavoidable for geometry but for texturing it was deemed too expensive in early implementations.

[Simon F]

Was it that the textures ignored perspective but the polygons used true perspective?
A straight line (in world coordinates) remains a straight line** in a perspective image and so, to project a triangle, you only need to compute the projected vertex positions (requiring a division per vertex) and then you can simply draw the (wireframe or flat shaded) triangle.

Once you add textures, however, you effectively need a division per pixel, aka hyperbolic*** interpolation. If you just use linear interpolation (which is cheaper to implement) you will get the warping effect because your brain is expecting things in the distance to be 'squashed'.


**Of course, if you had tick marks (as on a ruler) you would see these being progressively squashed along that line.

*** i.e.
Texture_U = (A*screen_x + B*screen_y + C)/ (P*screen_x + Q*screen_y + r);
Texture_V = (D*screen_x + E*screen_y + F)/ (P*screen_x + Q*screen_y + r);

[JHoxley]

You might want to check out the "Hyperbolic Interpolation" chapter in Jim Blinn's "A Trip Down the Graphics Pipeline" book (the first of his three-part series). I was reading it last week and it seems to describe and answer the original question perfectly :smile:

Cheers,
Jack