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

Re: LibGGI3D RFC

On Thu, 20 Aug 1998, teunis wrote:

> On Fri, 21 Aug 1998, Rodolphe Ortalo wrote:
> > On Thu, 20 Aug 1998, teunis wrote:
> > > Does this message help any?  Are we communicating or arguing about
> > > completely different topics thinking they're the same? :)
> > 
> > We are communicating, don't worry... ;-) In fact, your 3d_tridata
> > example showed me how we could pass more things through a single
> > function (hence clarifying the objective of using display targets...)
> > 
> > You know, even if I play the devil's advocate, I would really _like_
> > to be able to use ggi3dDrawTriangle _only, and then have some
> > setup function where I can (possibly dynamically) reconfigure the
> > engine so that it uses gouraud, textured, etc.
> 
> Actually - that's why I said at the end of the message there was problems
> with that approach....
> 
> Truely here OpenGL is a -good- model!  Rather than sending a triangle,
> sending a small(!) list of instructions on what those triangles should be
> (yes - handle lists of triangles).  So you could attach additional info to
> a triangle such as texture data, multitexture info, ....

	*Exactly* what I am proposing with triangle sets.  Each one can
have arbitrary metadata associated with it, describing the object that
triangle set represents (polyhedra, strips, fans, surface patches, etc). 
If triangle sets weren't enough, maybe we could have triangle set lists or
whatever. 

> PS: All non-constructive responses to this will be ignored.  I'm not
> expecting anyone to agree or back me on this.  I'll write up a spec and
> -then- post it for discussion :)

	Killer.  Sounds like you and I are on the same page.  And since
you probably know more about what triangle set subtypes will be needed as
well as what metadata needs to be associated with each type, I'll be glad
to let you handle this |->.

	I just had a thought.  Whether you are drawing one triangle or a
triangle set, you'll probably need metadata.  Maybe there should only be
triangle sets (1 or more triangles + metadata), not individual triangles
at all? 

> PPS: incidentally, one of the problems I have with embedding data that way
> was the overhead of pointer-lookups in rendering....  a cached system is
> much faster!  I had a lot of these kinds of probs with the renderer I
> coded....  (floats were too slow [486 then Cyrix-non-MMX], function calls
> were -too- expensive, -fPIC slowed everything by 50%+, any memory access
> at all was expensive, ....)

	Might want to look into caching within the display target.  You
could preload the target's cache by doing the pointer lookup once and
dumping the data into the cache at the start of rendering.  Or even
persistent caching from render op to render op, if this was appropriate. 

Jon

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