From: Aaron Gaudio <icy_manipulator@mindless.com>
  To  : ggi-develop@eskimo.com
  Date: Mon, 1 Feb 1999 18:17:34 -0500 (EST)

Re: libggi3d non-clarity

And lo, the chronicles report that Xavier Bouchoux spake thusly unto the masses:
> 
> 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. 

That's not a problem, as long as a mechanism is in place to query 
what features are available (first see if bump-mapping is available,
then see if a hardware-accelerated module for it is available).

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

Not a problem. At this point, you don't care whether hw-accelerated
bump-mapping is available. As long as you pass these objects down the
proper pipeline (or otherwise earmark them somehow), which either contains
the bump-mapping module (independant of the main pipeline) or some means
of telling the pipeline to bump-map those objects, as opposed to others
(I prefer the former, but perhaps the better is more efficient in some
situations?), you're fine.

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

Same issue as above. The preferred solution would probably be to pass such
things down a different pipeline; where this pipeline splits from the main
pipeline depends on the ability to "earmark" things and what level you're
operating at (for instance, if you're at the scene description level, then
you have more need for earmarking so that lower-level arbitrators will know
to send that stuff down different pipelines, but if you're operating at
a lower level, you may have to throw them into different pipelines manually).
Split pipelines could later merge again so the end you have a single
rasterized scene, where some objects have undergone different rendering
than others.

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

Which highlights the need for a sane means of accessing the lower levels
with as little client-side processing as possible.

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

Absolutely. There is nothing stopping you from using GGI3D modules and 
meddling with the pipelines directly, even if you are using Mesa-on-GGI3D
for most of your work. Some of that may be tweaking the pipelines already
in use (by, e.g. Mesa), some of that may be setting up your own pipelines.
AFAIK, this is not possible in current systems, but it is in fact the 
guiding rationale for GGI3D (as I understand it).

> 
> 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 ;-)

Well, I don't mind...I say "we" all the time and haven't done anything
(codewise) for GGI either ;-). We're all contributing, IMO, in one way
or another.

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

Yes, this is unavoidable. If you wanted to eliminate all of it you'd talk
to the hardware directly in your application; but needs of portability
and ease of development necessitate a certain level of indirection. IMO,
indirection should be minimized only insofar as the result fits within
the design considerations. 

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

(I thought you'd want to do clipping before culling too, but anyways...)
This is the strength of GGI3D. The pipeline is not so fixed as in other
environments like OpenGL. If the current pipeline is not producing what you
want (either in terms of end-result or in performance), then you can either
adjust it or provide an alternative, more or less dynamically, but you
don't have to rewrite and recompile it.

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

This means that the pipeline(s) will be configured based on what is most
efficient at the time. A hardware module author may provide a different
default pipeline configuration; most users won't have to worry about it
much, other than to install that configuration rather than the one they've
been using. Those interested in tweaking this to their own liking may
alter the configuration, either at run-time or statically (statically meaning
via configuration files). Those more interested in speed than space (most
of us, in other words) will probably provide most things statically so that
initialization may be a little longer, but once you start you get optimum
speed (because you aren't trying to alter the pipeline all the time).

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

Yes, and when you're programming at the GGI3D level (as opposed to the
API level), you have total control as to where to send your data in the
pipeline, as long as your data is in a format which the given arbitrator
can understand. In some cases, you may want completely different 
pipelines, or you may want pipelines that do different things and then
merge together at some point. This should all be possible in GGI3D.

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

Unfortunately, GGI3D can't help you there ;-)

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

In actuality, I think GGI3D would be more of a graph. Things may branch
out as in a tree, but they may also merge in or just intersect, etc.

> 
> and the API of all the levels should be well defined.  

This defeats the purpose of GGI3D. You can't provide a well defined API which
covers features you haven't thought about yet. This is the problem with
OpenGL and D3D. As soon as a new hardware vendor introduces a hardware
acceleration for a feature previously not hardware-accelerated, the pipeline
has to have a new hook added to it, which means rewrite the pipeline. Even
worse, when a new feature itself is added, the API must be altered.

The first problem is handled by the fact that if a feature becomes hardware
accelerated, you simply insert the hardware-accelerated parts into the
pipeline (perhaps only replacing a software module with a hw one..perhaps
changing the entire path of the pipeline from that point onward, depending
on the implications of the hw-accelerated feature).

The second problem is handled by the fact that, although there may be a
standard set of "feature" modules (which would be encapsulations of 
abstract 3D algorithms), the architecture of GGI3D is not dependant on
specific features, and therefore extending the feature-set is as easy as
making available a new feature module and either constructing a new 
pipeline which makes use of that feature or, more likely, altering the
current pipeline to make us of that feature.

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

This would be inherent in GGI3D, but GGI3D would not be limited to it. Because
it does not require a fixed feature-set, adding new hw-accelerated
versions of old features is not the only way you can extend GGI3D; you can
actually add new features themselves and have them work with the current
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.)

You can't be sure that bump-mapping will be available unless its a standard
GGI3D module, and in that case you're only guaranteed there is a software
renderer for it. Where to add a new module for it is up to whoever wrote
the module, although if you wrote your own bump-mapping renderer (either in
software or via hardware), hopefully you know enough about 3D and the
rendering pipeline to know where bump-mapping should go (in fact it may
go in different places for different situations).

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

No its perfect for the game company. They can provide pre-compiled modules
which can be integrated into the pipeline without recompilation of either.
This is, IMO, a giant leap for game developers, because in the traditional
model, the game developers have three choices: use what the API driver authors
(usually the board manufacturers) wrote, go knee-deep into hardware internals,
or provide a seperate software solution. In each case you have a single 
pipeline you can use, so if you want only to tweak one thing (like say, use
accelerated bump-mapping in an API which doesn't allow for it), you have
to reimplement the rendering pipeline. In GGI3D, this is less necessary because
you can more easily use the current rendering pipeline, just adjusted to use
your new module instead of the other one. If you want to implement your own
pipeline (or sub-pipeline) this is easier too, because you can more readibly
reuse existing modules (in this case they trully are more like components
than modules).

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

Absolutely, although there should be significan means for the application
itself to alter the pipeline at run time (maybe special situations arise
in which you can use an optimized pipeline, but you don't want this to
be the default).

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

This would be inherent in the design. Since, technically, it's up to
the user/application to create the pipeline (even if that means simply
using the default configuration), there shouldn't be any limit to
how many pipelines you use. As long as the ability for pipelines to
interact (for instance, by branching and merging) you're home free.


-- 

¤--------------------------------------------------------------------¤
| Aaron Gaudio                   mailto:icy_manipulator@mindless.com |
|                    http://www.rit.edu/~adg1653/                    |
¤--------------------------------------------------------------------¤
|      "The fool finds ignorance all around him.                     |
|          The wise man finds ignorance within."                     |
¤--------------------------------------------------------------------¤

Use of any of my email addresses is subject to the terms found at
http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you
agree to be bound by the terms therein.