From: Aaron Gaudio <icy_manipulator@mindless.com>
  To  : ggi-develop@eskimo.com
  Date: Tue, 2 Feb 1999 19:14:47 -0500 (EST)

Re: libggi3d non-clarity

And lo, the chronicles report that Xavier Bouchoux spake thusly unto the masses:
> 
> 
> Libggi3D has to provide: (and THAT should be standardised)
> - a way to know what fonctionalities are present 
>       (in a usefuil way..  not just a unstandardised string telling
> nothing to the application.)

Depends on what you consider useful. Since GGI3D will not be limited
to a fixed feature-set, the description of the functionality of a module
will be more or less arbitrary. The standard modules should provide
"standardized" descriptions, and if the author of a non-standard module
means for that module to take the place of a standard one, he better 
give it the same description. Aside from that, I think if a hierarchy of
descriptions could be made (as a seperate registry), that would be nice
because you could do things like ask what sort of shaders are available
(although unless there is a non-standard feature module that does a new
type of shading, that sort of information is pretty static).

> - a way to know which modules are hardware accelerated
>       (actually, that doesn't means a lot.  The actual thing is more a
> way of knowing wich module is faster, and how fast they are. In order
> for the app to decide if it can use them or not.)

Hmm...I don't think there is a clean way of telling which module is
actually faster. That is heavily platform dependant and could in fact
change depending on the situation. You'd actually lose more time trying
to test which modules or groups of modules is most efficient than if you
just picked one randomly (in fact, that's provable). However, it is
often very important to know if a module will use hardware acceleration
to do its job. This will often determine whether you use that module or
not (for instance, you probably don't want unaccelerated bump-mapping to
be in the mainstream pipeline).

> - a way for the app to build new pipelines, to tweak them, and to insert
> its own modules in the pipeline.

Essential.

> - what are the standard modules. 
>       Because we speak of "yes that could be standardised", "yes that's
> possible.." .... So let's decide! (a first draft of course...)

Hmmm....I am hesitant to clamour for standard modules yet. I'm more interested
in hammering out the architecture first.

> 
> 
> I think that the pipeline should be built dynamically at run time (It
> can be computationally expensive: it is run only once!)  because that's
> one advandage of libggi3D when not using high level API (only). 
> With (as an option) configuration files, to skip this step for usual API
> (openGL has its pipeline built only once).

I would have the pipeline built during an initialization step. With 
support for multithreading and data sharing, the same GGI3D system could
be loaded by one application and used by many, so that the initialization
does not take as long.

> > > (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....)
> 
> The point here was that you can't make the lighting module indepently
> from the rasterizer module (as it should), because you do need to pass
> some data to it. So you need to know things about it.
> That's not good for modularity!

As long as lighting and rasterizing are not being done simultaneously (which
woudl require a lighting/rasterizing module), the modules themselves don't
need to know anything about one-another other. When designing the module,
the author will have to make sure its interface is compatible with the module
in the pipeline; and that's a good argument for a standard set of modules.
If module authors begin depending on non-standard modules, that's perfectly
fine, but they better know that the module in fact may not exist in a 
given environment, or that it may not interface the same as the standard
version.

> 
> 
> > 
> > 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. 
> 
> Can you explain what is exactly this "arbitrator"?  What it does, and
> how?
> I didn't quite understand.

I've been using it to describe a component which will decide along the
pipeline which module(s) to use. In other words, they will exist along the
nodes of the pipeline graph.

> 
> 
> >
> > 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.
> > 
> yes a direct acyclic graph.  =>  a tree...  ;-)
> (but you're right!)

It would not necessarily be direct (althout it would be acyclic), therefore it
is not a tree. That's because you could reach the same node from two different
pipelines (and in fact, you are very likely to if all your pipelines are
rendering to the same target-- at the least they'll all merge at the
low-level device-dependant module).

> 
> 
> > Even
> > worse, when a new feature itself is added, the API must be altered.
> You still need to alter the high level API to use it.   but that's
> fine...

Yes but the high-level API will not be a part of GGI3D, so that GGI3D will
not be limited by the API.

> > 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).
> 
> That's a difficulty.  Because to know where to put a new module, I have
> to both know where it should go in the pipeline (the logic, abstract
> pipeline), and what does the actual user "physic" pipeline looks like.
> You want to be able to say put it there. 

You make a good point here. There will have to be some sort of meta data
(possibly the afore-mentioned description or an extension to it) and when
you are altering the pipeline your program will have to examine the
current pipeline(s) and, based on the metadata it finds, alter it accordingly.
I don't think the logic for this should be left to GGI3D but rather to
the programmer. Most of the time, this will be the API developer, but if you
have a reason to go mucking about in the current pipeline then you will incur
a certain amount of complexity to be able to alter an arbitrary pipeline.

Perhaps, like modules, it would be beneficial to define "standard" pipelines,
so that your application/API can look for a standard pipeline and work with
that. Since in this case you know at the onset what the pipeline looks like
you don't have to worry about complex logic. However, the developer will need
to be aware that the standard pipeline may not be available (unlike standard
modules) because it may have been modified earlier.

> 
> Maybe some user interaction maybe need here, for difficult cases?
> (But that's not nice.)

No I don't think that's feasible. Most people are gonna want to start up
their Quake III without being asked where to insert the optimized 
tesselator.

> 
> I want my app to be able to use the module I provide with it (that is to
> say insert it), whatever the actual pipeline looks like.  And that's not
> an easy problem:
> 
> should my lighting module go after or before clipping ? (supposing that
> the in and out type of clipping are the same) And maybe I don't know
> what clipping is when I write my app....
> 
> How can this problem be solved?

It can't be, not from GGI3D. That's the sort of thing that the developer
will have to work out himself, I think. GGI3D would merely present you
with enough information to do something...what to do based on that information
is up to your application.

> > >
> > > 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.)
> > 
> >
> What I meant here is that:
> - the fact you can provide your own modules is a very good thing.
> - the fact that the user can reuse it with other apps (so that they
> benefit to the other app) is very nice from the user point of view, but
> not from the evil-commercial-society one...  (who spent a lot of money
> on build a fast raterizer, and who doesn't want others to use it...)

I guess that's tough titties for them. I don't think any sort of licensing
management belongs in GGI3D. Basically, if a company wants to release a
module for GGI3D, then the most they can physically do is to release it
binary-only. Any licensing they want to put on the module (restriction usage,
etc) is between them and you and I suspect GGI3D will keep itself out of such
issues.

-- 

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