From: Paul Sargent <Paul.Sargent@3dlabs.com>
  To  : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
  Date: Wed, 19 Aug 1998 06:00:49 -0700

RE: LibGGI3D RFC

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.

> * It is slow(er).

This is a Myth. There is no reason that API1 should be slower than API2,
they are just interfaces. 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. 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.

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

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

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.

That way things can grow if people actually want to write them and it
would give us a well defined API that people already know (Application
writers) and like.

It will also make it easier to bolt things on the back of Mesa, as we
gradually consume it from the graphics hardware end.

> * 3D world modeling.  We don't need it, and it can be implemented on top
> of LibGGI3D if needed.  Our job is to do 3D drawing, not model worlds. 

Fine, don't implement it.

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

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

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.

-----

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. 
It sounds to me that you want libGGI3D to be a rasterizer only lib.
That's good, that is the part which can gain from the most acceleration.
So lets implement just the rasterizer functions to the OpenGL API. This
is basically what people like 3Dfx did for Windows with their MiniGL
drivers.

Paul

P.S. I'd like to be on any list that was started up for this.
--
Paul Sargent, 
3Dlabs Inc. Ltd,