From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 21 Aug 1998 17:58:18 -0700 (MST)

RE: LibGGI3D RFC

On Thu, 20 Aug 1998, Kostya Vasilyev wrote:

> : > 	That's what I had in mind.  After, all the texture is a 2D bitmap.
> : > Yes, you need u, v values, but only one u,v offset (and offset
> : angle?) per
> : > triangle patch.  Unless you want to tile more than one texture per patch
> : > or do multitexturing, in which case you need more info.  But the info is
> : > still per-patch, not per-triangle.
> 
> This is only true in case of affine texture mapping. Granted, this is most
> common case, but not 100%.
> 
> What you really need is u,v per vertex. This also makes interpolation (for
> clipping) easy -- when clipping, the primitive operation is to interolate
> and edge that intersects a clipping plane and make new vertex out of the
> intersection.

Exactly my point!

Also for gouraud-shading you end up with a colour-component at each
vertex.  (I do RGBA at each coordinate but others might differ :)

And if you do material calculations the same applies there too..
[actually it can be pretty fast to do lighting if you design the system
right :]

> : There's other ways of fixing up perspective-correction too...  I'll take a
> : peek at how the HW people do it...  Maybe basing the lib on a hw-reference
> : WOULD be the best way?
> 
> Perspective correction is done by interoplating s/z, t/z and 1/z as you walk
> the scans, and diving at each pixels to get back s and t.
> 
> This is almost irrelevant, since HW does this (only relevance is for
> clipping in Z, where you need to interpolate s/z and t/s, and not s and t).

Thanks! :)
I keep forgetting about this... this is one of the thing's that have been
bothering me about my own code :)
[I abstract perspective correction at a couple of points so it looks
pretty nice but that won't be 100% workable - this is :]

G'day, eh? :)
	- Teunis