From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Tue, 18 Aug 1998 22:49:14 -0700 (PDT)

RE: LibGGI3D RFC

On Tue, 18 Aug 1998, Kostya Vasilyev wrote:

> More comments below:
> 
> : > 	The first feature is the notion of a camera.  This is just two
> : > sets of 3D coordinates which specify a viewpoint and a
> : direction.  This is
> : > necessary to map the 3D coordinate space onto the 2D coordinate space of
> : > the display.
> :
> : Umm hangon...the notion of a camera is directly related to the concept
> : of a model space which we have decided we are not going to deal with.
> : The triangle drawing code doesnt care where the triangles are in space,
> : only what the screen coordinates & Z value are so it can fill the screen
> : scanlines whilst applying perspective correction on textures etc (and
> : Z-buffering).
> 
> Doing texture map perspective correction requires an additional (compared to
> x,y,z) value: W, the homogenious coordinate. It is usually derived from
> vertex's Z in camera space, but depends on fov and window size. If LibGGI3D
> does not concern itself with these, then the triangle functions need to
> accept W in addition to [x,y,z].

	It will probably do the former.

> : > 	That's all for now.  Take a look and let me know what you think.
> :
> : OK enough complaining, this is what I think :)
> 
> : 2. LibGGI3D should NOT concern itself with object->world->window space
> :    coordinate conversions. If hardware becomes available which can
> :    accellerate this through hardware matrix multiplication of vertices or
> :    something then this could be incorperated into a separate library.
> :    This seems to be the biggest point of confusion regarding libGGI3D
> :    at the moment and I think its important to make a clear distinction
> :    between 3D primitive rendering and 3D object
> : management/transformations.
> 
> IMHO, LibGGI3D _should_ concern itself with object->window space conversion
> for two reasons:
> 
> 1. so it can take advantage of geometry acceleration in HW if/when it
> becomes available. However, this is a moot point: given that we have AMD
> 3DNow and will soon have MMX2, 

	As well as iVec or whatever that MMX-like thing on PPC processor
is called.

> the host CPU is becoming more capable of
> doing transformation and projection... which brings me to next reason:
> 
> 2. LibGGI3D code can contain special code for these processors. Taking
> advantage of 3DNow or MMX2 will then be transparent to the application, and
> result in significant performance boost.

	Right.  This is also a good point.

> Having said this, the transformation can easily fit in the next layer up, be
> it OpenGL or MesaGL, Direct3D compatible APIs, or anything else.

	It would be a lot simpler if LibGGI3D didn't need to worry about
doing coordinate transforms other than 3D->2D.

Jon 

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed