🚀 go-pugleaf

In article <oodqpdc@fido.asd.sgi.com>, akin@sgi.com (Allen Akin) writes:
> I agree with most of what Rich said, but there were a few points that
> need further discussion.
> 
> In article <1992Aug18.182730.3478@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes:

[ stuff about interactivity deleted]

> | Under OpenGL, the same reformatting happens; you merely get what
> | language designers call "syntactic sugar" so that you can provide the
> | data in any datatype you wish.  However, at the core of all graphics
> | rendering today (at least the PEX/OpenGL type) is a graphics pipeline.
> | Data goes in one side and pixels come out the other (I'm
> | oversimplifying).  This pipeline is going to have its own natural data
> | format for the data that is the most efficient for its algorithms.
> | Your data will be reformatted to this internal representation.
> 
> No, the design issue here is much deeper than "syntactic sugar."
> 
> With the OpenGL API, it's possible to extract graphics data directly
> from application databases without having it travel through the CPU
> and system busses for reformatting.  With a PHIGS- or PEXlib-style API
> that defines primitives with high-level structures, or any API that
> generates a memory-resident intermediate representation like a wire
> protocol packet, this is not possible for arbitrary application
> databases.

[more stuff about tetrahedral mesh deleted to save space]

> I realize this is a subtle aspect of the OpenGL design, but it's a
> significant one.  Definitely worth thinking about.  I apologize if
> I've belabored the point.

Since I haven't seen the spec it is hard to know from this description
exactly how this all works but from your description it sounds a lot like 
the PHIGS SOFA's that are supported in PEX or the PHIGS Triangle Set that is 
likely to be supported in PEX 6.0. Could you explain the difference?


--
 ---		Gary G. Cannon
 ---		Evans & Sutherland
 ---		cannon@dsd.es.com