From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 21:56:25 -0700 (PDT)

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, Sengan Baring-Gould wrote:

> Jon M. Taylor wrote:
> 
> > > Hidden surface removal is a large and complex topic, but given the current
> > > state of hardware/sofware features/performance, the best approach is to do
> > > rough visibility calculation in host CPU (BSPs and portals are two possible
> > > schemes), but do not try to get rid of all overdraw; then let the hardware
> > > sort out the rest. This requires some sort of hidden surface removal in
> > > hardware; z-buffering is one.
> >
> >         Right.  If the layers above LibGGI3D want to do this sort of
> > thing, they can draw to a z-buffer and render from that, or they can do
> > backface culling during triangle tesselation, or they can do what you
> > suggested, or...
> 
> On this I agree: not a libggi3d issue. So basically for me the triangles
> (bits of triangles) need to be in 3d coordinates only for z-buffer
> expansion. 

	Also for triangle sets, to be able to calculate angles between
triangles for shading purposes.

> I don't believe any of that rotation hardware will take off: 
> Game developers need to differentiate their engines.  They can't beat the
> raw speed of rendering hardware, so they won't work on that.  But they can
> add all sorts of funny lighting effects. This is much more of a "WOW" 
> factor for them, and so I doubt they'll ever give that up. 

	Oh yes they will.  Within a couple of years, lighting effects will
all be done in hardware.  You'll pick your light sources and their types,
and you'll pick your object materials, and that will be that.  Game
developers != engine developers for much longer.  If one engine team
spends all its development time making flashy lighting effects and another
concentrates on a faster, more flexible engine which can be accelerated in
hardware, which do you think will be more attractive to game coders?

	I think that physics models, environmental interactivity and world
detail/size will be the engine features that will make the big differences
in the future.  Look at Tomb Raider.  Look at Unreal.  People expect
*depth* out of their 3D games these days, not more rendering glitz.  Look
at how Quake I languished until GLQuake came out.  The Quake engine was
superior to Duke Nukem 3D's but Duke had better designed levels, weapons
and environments.  Quake took off once the soft-engine backend could be
replaced by OpenGL (and hence by hardware rendering).

> Also 3DNow! or
> KNI (MMX2 provide a big boost to this code. For instance, Mesa will
> probably include 3DNow instructions for transform and lighting. Lots of
> game developpers are very interested in using it. 

	Yeah, but I'll wager that they use it through Mesa/D3d, not
directly in their engines. 

Jon

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