From: Xavier Bouchoux <bouchoux@cs.bris.ac.uk>
  To  : ggi-develop@eskimo.com
  Date: Mon, 01 Feb 1999 21:39:41 +0000

Re: libggi3d non-clarity

Hi...

Just to give my view on the subject, as everybody ;-)

(I don't quote the other mails, sorry for my bad english, and it's quite
long)


1)
I agree with the concerns of David Joffe: the programmer should be both
given access to high level API, and also to lower level things.
The high level API doesn't know has much as the app programer about what
should be done. To continue with the example of bump mapping, let's
suppose the following:
- I want to use hardware accelerated bump mapping where available
because it looks nice.
- I don't want to use bump mapping if not hardware accelerated because
it's slow. 
(until now, no problems with high level)
- But I still want to use software bump mapping (if there's no harware
bump mapping) for some objets because it is important for the
application (maybe something written on a wall, I don't know). I even
provide a module to make software bump mapping if not availabe.
- Or I want to display the scores (in a game for example), in front of
the screen, has a mapped triangle, but of course this triangle shouldn't
go through the whole pipeline, because I provide the 2d coordinates, and
I don't want lighting, and so on..
- lot's of other weird ideas that a high level API can't provide in a
nice way (and without too much overhead for the basic use)

So for this lasts points, I think it is _really_ useful to have a direct
access to lower level. (Maybe not neccessarily the lowest level, though)

2) 
About performance:
I think we (ok, I hope you don't mind me using "we" even if I've never
done anything for the GGI project ;-) should keep in mind that modulaity
has an influence on performance on several points.
I could think of these ones:
- at very low level, all this moving around of data and of the PC (err I
mean program counter), that we have to traverse big arrays a lot of
times, isn't very good for the cache. But, well, nowaddays we can afford
that to get a better design. Just to keep it in mind.
- at a higher level, you (may) have to split calculation that could go
together (and hence be optimised), or change the order of some
calculations.  An example:
One could be tempted to write a pipeline like this (to get modularity):
tesselation-->geometric tranformations->ligthing -> back face culling ->
clipping -> projection ....
that is good because, it allows, for example, to skip tesselation, if
you have a triangle mesh to display.
but it isn't very efficient. You'd get much better performance if you
calculate the lighting, the geometric tranformation (and maybe even the
projection) on the objet before tesselating.
Of course this is an extreme example. 
An other one: doing the back face culling, and lighting at the same
traversal of the vertices, and before the tranformation can give quite a
nice performance boost. In software of course. Because that's a problem.
If you have only back face culling in hardware, you just can't do this
trick, you have to have the modules.

(Maybe these examples are irrelevant. I didn't think much about
them....)

3)
a pipeline is not neccessarily linear.
I mean that all data shouldn't go through the whole pieline:
the high level API allows to draw a texture mapped object.
the geometric data should go throught the whole pipe, whereas the
texture should go straight to the rasterizer texture manager, that can
for example cache it. 
And maybe in a sub-module, the lighting module for example, a lightmap
can be created, that should go straigth to the same place. 
(But that can be a problem, because  maybe the lighting module isn't
aware of what's going on at the other end of the pipeline, and that
there's a rasterizer. An other problem with modularity....)


4)
There was other things, but I just can't remember.



Anyway, here is how I see libggi3D: (well, they are only random
thoughs.)

The modularity is a good thing.
having a "fuzzy" API for the low levels is maybe not a so good thing. 

I think of Libggi more as a tree:
                          "View of the Pipeline"
high level API:                         render_world()

                 geometry processing                       rendering
....

low level:  lighting tranformations  ...         texture cache
management    rasteriser  ...   



and the API of all the levels should be well defined.   The modularity
is in two facts:
you can change any module by an other module providing the same
fonctionnality --> and API.
you can add/remove modules in any depth, providing that you keep the API
of the upper level. you can of course reuse the modules at the same
level, or write a completely new sub-pipeline.

Of course there still is the problem of the user that wants to access
low level, and who can't be sure of the actual implementation of a
level. But at least there is this hierachy of depths, so that he knows
that the deeper he goes, the more he as to be careful. (But that doesn't
solve the problem IMHO. how to be sure that bump mapping will be
available in the pipeline, and how/where (if it is not) add a new module
to implement that.)

Because that could be a nice feature of libggi3D:  the app programmer
can provide libggi3d modules with his app, if he needs some special
thing, or if he think he can do better than the default module. And the
other app can benefit from that.  (Maybe not such a good idea for a game
company that wants to keep some state-of-the-art secret technics off its
concurents.)

And of course it must be user configurable:  what modules to use to
build the pipeline.


An other idea (= nice feature) can be to build several pipelines
starting from different data (A sphere, a bezier patch object, a
triangle mesh, ...) and sharing modules that they have in common.
triangle rasterizer module , or surface lighting module...
If one day we add some hardware to display bezier patches, just don't
use the triangle rasterizer and the tesselator and render directly, but
still use the lighting module for example.


ok.  enough for today. Thanks for your attention.  you can wake up.


		Xavier.