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

RE: LibGGI3D RFC

On Wed, 19 Aug 1998, Paul Sargent wrote:

> Hi John,
> 
> A couple of points:
> 
> On Wednesday, August 19, 1998 3:54 AM, Jon M. Taylor
> [SMTP:taylorj@ecs.csus.edu] wrote:
> 
> > 	There are, however, some downsides to using Mesa/OpenGL:
> > 
> > * It is huge.  OpenGL is a full object representation system, rendering
> > pipeline and display management system.  Not all of these features are
> > needed by all users.  For example, a widget set that used phong shading to
> > give its widgets a nice 3D look might want to be able to accelerate that
> > shading in hardware if it could do so, but if OpenGL is the only way to do
> > 3D it will have to base the whole widget set on OpenGL.
> 
> Agreed it is a big job.

	And it is a job worth doing.  But for many cases it is overkill.

> > * It is slow(er).
> 
> This is a Myth. There is no reason that API1 should be slower than API2,
> they are just interfaces. 

	In principle, yes.  However in practice,

> The reason GL is normally slower than some of
> it's competitors is it's size. Optimising every code path in a GL driver
> is a huge job. 

	Right.  And until that work is done, your OpenGL will be slower
than bypassing it would be. 

> Driver developers normally wait for a killer app to
> optimise for and then optimise that path. Unfortunately this means that
> only specific paths are optimised and sometimes at the expense of other
> areas.

	Right.  It's too much work to optimize every possible code path in
one go.  This sort of general, overall optimization emerges out of the sum
of all the sepcific code path optimizations that take place over time.

> > * It is too inflexible in places.  OpenGL 1.1's inability to expose the
> > geometry part of the graphics rendering pipeline means that video hardware
> > which can accelerate some geometry itself cannot just plug in to that part
> > of OpenGL and say "use me to do this stuff".  
> 
> I don't understand this. Take Glint Gamma (3Dlabs's Geometry and
> Lighting Chip). It accelerates any OpenGL geometry and lighting calls.
> It's done by having the driver use the chip when every the relevant call
> is made by the app. Direct X can't do this because the API doesn't
> include geometry and lighting, therefore no acceleration.
> 
> Anything outside of what the GL spec say can be added in the form of
> extensions. These can be added by any driver writer without having to
> get them approved by the OpenGL committee. There already exists loads of
> them on the OpenGL site.

	It appears from what people have been saying that I am a bit
under-informed about OpenGL and geometry acceleration.  Mea Culpa.  But
you still have to use OpenGL extensions, though, right?  Pluggable
geometry acceleration isn't part of the base OpenGL spec? 

> > 	OpenGL is quite good, and for most purposes it gets the job done. 
> > But not for every purpose.  For those who need a few simple 3D features,
> > those who want to be able to develop a 3D KGI driver without having to
> > deal with the whole OpenGL API, for those who just want to render a
> > gouraud shaded, texture mapped triangle, we need a simpler API.  That API 
> > is LibGGI3D.
> > 
> > II. Overall design
> > 
> > 	So the keyword here is "simple".  If OpenGL is too complex, then
> > let's look at what parts of OpenGL we *don't* need: 
> 
> I've got no problem with this, but let's not recreate the wheel.

	You have a dump truck tire.  I want a racing slick.  Although they
are both "wheels", the one cannot be used in place of the other (very
well, anyway). 

> The OpenGL API is too complex. Fine. Let's implement only the parts we
> want. Forget the glTransform, glRotate, glLight, glFeedback calls.
> Forget the Matrix manipulation. GL has the flexibility to be used as
> just a rasterizer lib, so let's implement that part of it.

	But I don't even want rasterization!  All I want from LibGGI3D is
a standard triangle representation system, abstract triangle drawing
functions, and the concept of pluggable shaders.  I don't want a graphics
pipeline, I want a set of hooks into any hardware or software pipelines or
pipeline subsections.  LibGGI3D *targets* may (will, really) do all kinds
of representational transforms, coordinate transforms, geometry
manipulation, rasterization, vectorization, clipping, shading, and
whatever else you can think of.  But LibGGI3D *itself* will just draw
shaded triangles.

	It has to be this way, otherwise we are on a slippery slope and we
will get sucked into reinventing OpenGL.  I don't want that, or I wouldn't
be pushing a LibGGI3D in the first place.  I want a simple, basic,
flexible shaded triangle drawing (not rendering, drawing) API.

> > * Complex object representational schemes (polyhedra, surfaces,
> > constructive solid geometry).  Again, this is a job for a higher-level
> > API.  All of that stuff is tesselated down before rendering anyway, so
> > LibGGI3D can be designed with the assumption that such tesellation has
> > already been done.
> 
> These things don't exist in OpenGL. Approximations can be made, but GL
> just draws quads (i.e. two triangles), triangles, lines & points. GL
> works with the same assumption.
> GLU is the utility library that allows drawing of Polyhedra & Surfaces,
> but that just calls OpenGL. So you could take the Mesa implementation
> and use it with any GL library.

	Or with LibGGI3D. 

> > * Lighting, shading, texture mapping, or any other such algorithms. 
> 
> I believe shading (as in interpolating colours across a triangle) and
> texture mapping _have_ to be included. Otherwise they can't be
> accelerated by hardware. (see my OpenGL vs. DX comment above). This goes
> for Z buffer as well.

	Shading and texture mapping is included with the pluggable
shaders. 

> I one final point...
> 
> > 	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.
> 
> ermmm...you can't have a camera without having transformations. So
> either I've lost you completely, or you've made a contradiction.

	Where did I say I din't want transformations?

> I guess you can see my standpoint. Yes, GL is a beast, but it's Open (in
> some senses of the word), it's cross platform, and developers like it.
> So why not use it as a final target, and start on the road towards it. 

	LibGGI3D does not exclude the possibility of using OpenGL.  A lot
of code developed for it can be scavenged for use with Mesa, too.

> It sounds to me that you want libGGI3D to be a rasterizer only lib.

	No, I want it to be a triangle drawing and shading lib.

> P.S. I'd like to be on any list that was started up for this.

	I have contacted Irish and he says he's looking into the matter of
getting us a new list. 

Jon

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