Index: [thread] [date] [subject] [author]
  From: Sengan Baring-Gould <sengan@seqnet.net>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 21:06:41 -0600

Re: LibGGI3D RFC

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

Sengan

Index: [thread] [date] [subject] [author]