From: Kostya Vasilyev <kostik@verio.com>
  To  : ggi-develop@eskimo.com
  Date: Tue, 18 Aug 1998 21:38:33 -0700

RE: LibGGI3D RFC

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].

: > 	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, 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.

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

~kostik