From: Aaron Gaudio <icy_manipulator@mindless.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 5 Feb 1999 23:37:19 -0500 (EST)

Re: libggi3d

Hello all, well I haven't written in a while about GGI3D and I thought
that was a tragedy <smirk>. Anyways, some messages to me were bouncing on
Mon. and Tues. and I got taken off this mailing list and then I just
didn't get the time to catch up. So, below I'm replying to several
messages.

BTW, Jon, I did read one of your messages that I missed, from the archives.
I wouldn't mind helping work on GGI3D, although I must warn that (1) I have
exremely little experience with CVS and (2) I'm not a 3D programmer...what
I know is from a computer graphics class I took last quarter, and most of
that was 2D. I am interested in GGI3D from a design approach though, and
honestly, I think that's where most of the uniqueness will come.

In other words, you can give me CVS write access, but I may not know what
to do with it until I get some more experience with CVS (which I'll be
doing soon).

Also, are you looking to use IDL for most of this stuff? My opinion is
that IDL would make a good interface layer at the high-end, but that
API and low-level developers are not going to want to deal with the
overhead (for instance, will CORBA be beneficial to someone implementing
OpenGL on GGI3D?). Perhaps you know more about CORBA than I...is there
a way of using the interfaces defined without going through any form
of GIOP? Nonetheless, I'm still not sure it's suited for the primarily
low-level stuff GGI3D will be dealing with. Personally I'd prefer
vanilla C++ (although I was going with the assumption of C).


<Bryan>

Below I mention the list (or map) of modules by function with input and
output interfaces specified using ints. Text is all very nice but int
compares are faster.
I am a little fuzzy on how this would limit developers to 'standard'
interfaces. For the modules to be pluggable in an arbitrary position
(even if this doesn't make sense), the 'standard interfaces' have to be
there - unless, of course, you are developing a totally custom pipeline
which does not interface with any existing modules. This would lead to a
large (dare I say bloated) registry of standard interfaces. However, I
would expect the interface types to settle at some point. No way 32 bits
worth though ;-)

<Me>

The problem I always have with integer ID systems is not that they are
limited (although theoretically they are) but rather that they are
overwhelmingly confusing. Even worse, there is rarely a standard for
numbers outside the range of the pre-defined ones, so there is nothing
preventing two different authors from defining the same interfaces
with the same ids.

As for efficiency, as someone else pointed out (I think), these comparisons
are not done very often; only when adding or removing modules from the
different parts of the pipeline. Usually, this will done at initialization
time based on the stored configuration. Therefore, to worry about the
efficiency of string (or memory) comparison versus int comparison, IMO,
is not warranted.

<Bryan>

However, runtime pipeline construction will need to know what they are
in order to do the connecting.

<Me>

Not really. It'll be up whatever is driving the construction to do
the connecting. In the case of the configuration, the connections will
really be done already, it'll just be a case of resurrecting the stored
connections. In the case of runtime-alteration, the client code will have
to be wise enough to do this. Perhaps there could be some utility classes
which can provide a little (automatic) logic to the process, but this
will, by necessity, be very limited (for instance, it may be able to 
tell generally that modules in a certain branch of the type hierarchy
go before/after those of a different branch).



<Me>

> 
> > For example:
> > Module A has an input type of ggi3d_coord3 <three dimensional coordinate,
> > standard type> and and output type of ggi3d_coord2 <2 dimensional coordinate,
> > standard type>, then it becomes obvious that for a module to be chained
> > after Module A, it has to have an input type of ggi3d_coord2. But you are
> > not limited to standard types. You could just as easily have this (pardon
> > any C++isms):
> 

<Bryan>

Is my English that crap???
I thought that I had also said this???

<Me>

Not quite the same as you said. My example used strings based on the
names of the types, whether those types were of standard types
(such as ggi3d_coord3 or something) or user-defined (such as myRGBColor).

<Jon>

>         I expect that the bulk of high-level GGI3D work will be done in
> OOP languages via CORBA anyway.  It is the natural way to do things using
> the GGI3D approach.  Only the stock LibGGI3D modules which need speed
> above all else will be written in C and assembly language and bound
> together with lower-level IDLs and ORBs.  Actually, you could say that at
> the low levels LibGGI3D is its own ORB.
> 

<Me>

I don't think I'd say that...ORB implies the overhead of interacting
with a name-service and a GIOP, etc. I don't think that's necessary for
GGI3D at the lower levels. However, I'm not seeing your idea very clear;
perhaps with some more explanation I'll come to.

<Bryan>

This modules map whould be read in when the system fires up. There is no
problem with an application adding entries to it in order to register
new modules. If you want more modules available without runtime
addition, update the modules map before the system fires up.

<Me>

Yes...a utility to do this will be necessary because no one will want
to have to edit the configuration itself (especially if it's stored
[in part] in binary or in something like the Berlin registry).

<Jon>

>         See my other post where I talk about a pipeline optimizer utility.
> All you have to do is make the module available by registering it with a
> global LibGGI3D module registry and re-benchmark your module set.  Your
> new module will now be made use of as best it possibly can be, given your
> current system.  Perfect optimization without any need to know what goes
> on inside the components.

I do see the usefulness of such a utility, with a caveat: such a utility
would be too limited to be relied upon as a core part of the library
(in other words, applications shouldn't try to rely on any information or
even functionality of it). I see it as a seperate utility...for the
power user to try to tweak their system; much like the video drivers
that come with modern 3D cards for Windows. No application uses them
directly, they are merely for tweaking for performance by the end user. As
such, I think such a tool, while useful, falls out of the scope of
GGI3D proper (unlike the aforementioned configuration tool) and should be
developed seperately from the GGI3D libraries.

<Bryan>

But why?
There has to be a unique identifier for the each interface. An int
provides millions.
Designed a new module type? Have a new module type identifier (again,
millions)

<Me>

But those millions may be chosen randomly (aside from the standard ones).
I have no question that the available space in theory would not be 
exhausted, but in practice there's no convienient means of establishing
namespaces. In light of the aforementioned fact that interface-comparisons
will not happen often during the running of the client, I think the
benefits of a string (either char* or char[]) based system outweigh the
costs.

<Jon>

> 
>         Yes again.  You have a really good grasp on what I am after with
> GGI3D, Aaron.  Might you be interested in getting a developer's read/write
> account for the GGI CVS tree from Emmanuel and hacking LibGGI3D a bit?
> Just to implement some of these ideas we've been throwing around here
> since it seems that a rough consensus is forming.  No need to write more
> modules than you need to develop the interface.  I'd do it myself, but I
> simply do not have any free time anymore with my new job.  If I do GGI
> work, it needs to be KGI drivers and Mesa targets right now.

<Me>

Whatever you do, make sure my soon-to-be arriving ASUS V3400 TNT will work
with any Graphics Blaster TNT drivers ;-)

<Jon>

> 
>         But if LibGGI3D was working to the point that I could write a Mesa
> target for *it* and then proceed to write a bunch of GGI3D modules for
> each KGI driver, that would set LibGGI3D on the road to consuming Mesa
> from within like I've mentioned before.  At that point I could justify
> working on it as part of my job again.  So if Aaron (or anyone else, for
> that matter) wants to see LibGGI3D succeed, pitch in and do some work on
> it.  Don't forget to keep testing LibGGI and KGI, though!  We still need
> to get LibGGI 2.0 final out the door.  I'll be ready to build GGI on my
> box at Creative probably tomorrow, so I'll be able to send lots of bug
> reports myself.

<Me>

I'm not familiar enough with KGI to know this...is KGI capable of doing
the low-level 3D accelerations which might be useful for some cards
(for instance, GGI3D may use Glide for 3dfx cards, but perhaps it could
use KGI for cards like TNT)?





<Niklas>

If I have understood things correctly libggi3d is a very small toolkit
that is meant to link modules together.  These modules all take one
struct as input, and returns another (possibly identical) struct as
output.  Two modules can be linked together if the first one returns
the struct the other one wants as input.

<Me>

That's what I've been thinking of...more or less.


<Niklas>

What is being discussed right now is how to name the modules, and how
to identify which modules can be connected to a module.

<Me>

Yes

<Niklas>

I don't see a reason for why the names should be computer readable.
It seems reasonable to me to let the module authors name their modules
however they want.

<Me>

Exactly.

<Niklas>

For how to decide if two modules can connect, ints and strings as
identifiers have been suggested. The disadvantage of ints is that with
them one have to be careful so that two different game companies, for
example, don't use the same value for two different structs.  As
pipeline construction always is done during program initialization,
the slightly higher cost of a string compare is extremely small
compared to the actual loading of the module from disk.

<Me>

Yes exactly.

<Niklas>

I like the idea of a benchmarker that can automatically choose the
most efficient pipeline.  It's a neat idea.  I see some problems with
it, though.  The efficiency of different pipelines may highly depend
on factors that are difficult to measure, such as:

1. System load
   
   - May affects weather to use a slow hardware-accelrated modules or
     faster software algorithms.  (Probably not a very common one, but
     with slow hardware on a multiprocessor machine it would
     certainly, and also when doing strange things with very
     specialized software modules where hardware accelration have to
     be made in a very inefficient way.)


2. Scene complexity

   - Different algorithms are good for different cases.


<Me>

Yes, these were the issues I was concerned about.

<Niklas>

3. Visual quality of the result.


<Me>

This one escaped me, but thanks, it's probably the strongest argument against
dependance on such a utility. How will the utility decide what is more
important to the user...and how would it measure visual quality even if it
could?

<Niklas>

The optimizer isn't neccessary to use libggi3d, though.  It's nice if
someone makes it.  A demo where one can switch pipelines on the fly to
see the difference in framerates would probably do just as fine.  With
that one could also easily see how some modules that make the result
look better slow down the rendering.


<Me>

This is what I had in mind, only less specifically so. A tool for the end
user to toy around to try to tweak performance/visual quality; much like
GLQuakers turn on and off OpenGL options from the Quake console to try
to tune their system. There's no sane way for Quake itself to do this;
similarly there's no sane way for GGI3D to do such things itself.


<Me>

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

> > An install time test can do this, put the results into a file. If the app
> > asks to know about the performances, load the file. The file would have to
> > store data about the system (CPU info, RAM, Video Board - one file for
> > each system and a utility to clean up the unneeded data).
> 

<Me>

> Basically you are asking GGI3D to benchmark every module and pipeline.

<Tristan>

No, but provide a simple key/value pair API to use those files. Put in a
simple fallback (ie, what ever GGI3D would do otherwise) if the data isn't
available. Let someone else make the benchmark files :)

<Me>

I still don't think that the information should be available in any
standard way. If an application wants to make use of such data, it should
tell you, for instance in a README, to use such a utility (one provided
if GGI3D doesn't end up providing one in the standard distrobution, which
I don't think it will, not for the initial release at least) and output
it to a file, then the application can read that file and do whatever it
wants to based on it. To such an application's developers I wish good
luck in using this comprehensively. 

I personally say lets postpone this discussion until GGI3D is in a stable
and usable state, and then any interested parties can come up with a proof
of concept.


<Me>

> I don't think this is realistic, first of all because it can't cover all
> situations,

<Tristan>

Fallback to whatever you would do otherwise in these situations.

<Me>

The problem comes when the utility *thinks* it can cover a situation, when
in actuality it botches it up, either completely (nonsense comes out on
the screen) or subtley (the balance between visual quality and speed is not
to the user's liking).


<Tristan>

> second of all because you are burdening the GGI3D developers
> with coming up with completely objective, robust and extensible benchmarks.

No, just a simple grading scheme for comparing different methods, GGI3D
just needs to return the data from files.

<Me>

That's the rub...I don't think GGI3D does need to return the data. If an
application needs to use such data, let it test stuff itself, because I
still believe quite firmly that such a system is going to be too limited
to be useful. But if it is possible, I still don't think its necessary to
be embedded into the GGI3D API (that is, the interface to handle modules
and the like); I think that, hypothetically speaking, if such a system
existed, it would work just as easily completely seperate from GGI3D itself.
Therefore, by not making allowance for such functionality in the GGI3D API,
we will not be setting ourselves up for a disappointment, but we also
will not be limiting the potentiality of such a utility being developed.


<Tristan>

I certainly think that the best method is for the app developer to just
ask for something to be drawn (in the simple case), and have it drawn by
whichever method is configured on the system. But this discussion included
app developers being able to put together a pipeline, which requires
some way of telling how fast/loaded things will be. I thought the
benchmark and grading API was best for this use. With this method,
libGGI3d would only need to provide the API and specify the file format.

<Me>

If such a utility existed, it would be useful, no doubt. But it's my
impression that (1) most pipeline configuration will be done once, at
initialization and (2) what is done from the client will be minimal
and highly scripted, that is, the client will know, more or less, what
it wants to do and what it wants to do it with. In the case of (2), 
this will usually only happen with clients working deep down into the
internals; in other words clients who want to do low-level tweaking
and therefore it stands to reason they'll want to know what they're dealing
with, more or less.

<Me>
> 
> If you are in a situation where software-rendering modules are faster
> than their hardware counterparts, then you simply wouldn't install the
> hardware counterparts into the pipeline, or maybe not even at all into
> the environment. Personally, I can't see any reason this issue would come 
> p; what is the point of hardware-acceleration if it's slower than software
> rendering?

<Tristan>

Keeping load down.

<Me>

And what is the purpose of keeping load down? Keep in mind also that most
clients concerned with 3D performance will expect to be running more or
less standalone, rather than have to compete for CPU. If your 3D app is
competing for CPU, then what are you worrying about performance for? ;-)


<Tristan>

Or libGGI3d can let the app access the data from a 3rd party test.
This, I think, is even better. And puts no real burden on libGGI3d
developers.

<Me> 

I think it's better too, although I'd go one further to say libGGI3D shouldn't
have anything to do with it. If an app wants to access data from a 3rd
party test, let it do so in its own memory space.

<Tristan>

Simply allow the app developers to get the default pipeline for that
system without thinking, or let them get the performance details from a
file which they don't need to know about.

<Me>

Bingo.

<Tristan>

I agree that libGGI3d doesn't need to handle benchmarking.

<Me>

Good...then I've won over another convert ;-)


<Me>
> I don't see how a pipeline could be built at compiletime and still fall
> within the goals of GGI3D. Basically I see two different ways of building
> pipelines (and registering modules, etc): via a configuration stored in
> non-volatile memory (for instance, in files), which is read by the GGI3D
> library (probably explictely, for instance when the client says
> ggi3D_load_default_conf() or something) and during runtime. Actually both
> are during runtime, but one method has the configuration stored before
> runtime. To GGI3D itself, both methods use the same runtime mechanisms.

<Tristan> 

An app (especially professional special effects places) will want to set
up complex pipelines which are software, but put in various features, and
have the overhead of pointer dereferencing removed, and *no* inlining
removed. I don't think it would be difficult to allow this case.

<Me>

I understand your argument; but I think to allow static (i.e. compile-time)
pipelines would require so drastic a change in the design that it would
render GGI3D ineffective. Basically, I think we can make GGI3D a good static
pipelined system, which is already done in OpenGL, we can make it a good
dynamically pipelined system, which is not done at all, AFAIK, or we can
make it a mediocre bridge between the two.

I think we should design GGI3D with the second option in mind, and if it
becomes possible to work in compile-time pipelines without altering the
GGI3D interface in any meaningful way then so be it.


<Me>

> 
> GGI3D is not supposed to replace human intelligence in forming the pipeline,
> it's merely supposed to allow the human to extend/recreate/tweak the pipeline
> easily.

<Tristan>

I'm a little confused as to what would happen when draing on a target that
can render a circle quickly itself. The app would have to just make the
pipeline as 'drawcircle -> target' rather than it's usual 'drawcircle ->
tesselate -> rasterise -> target' or whatever. Would GGI3d provide a
default pipeline that leaves out unnecessary bits?

<Me>

I think there will be different configurations for different targets;
there will have to be or else everything would render to a single target
regardless, because the target-specific modules would still be in place.
Which targets will be supported by default by GGI3D is certainly a matter for
discussion, although I suppose it'll end up being whatever targets people
write modules for.


<Joshy>

radiosity is where you divide every surface in your world up into
polygonal patches and then you figure out how much light each patch
reflects on to each other patch.  this is really really slow because if
you have N patches then you've
got N^2 compares to do. [...]

<Me>

It's worse than that, IIRC.
What happens is that each primary light source projects onto some of these
patches. Then, the patches project (via reflection) onto other patches,
and so on and so on, until every patch has been considered a light source.
Extremely time consuming and nothing you'll see hardware accelerated with
present technology, IMO.

But I don't think there's any GGI3D should be limited to only
hardware-accelerated or real-time 3D modules. Perhaps non-real-time
modules could be supplied either as part of GGI3D or as an extension
to it, for instance as a scene-rendering package of modules.


<Jon>

The optimizer would be a tool of convenience.


<Me>

Which is why I don't feel it belongs in the GGI3D API (for instance
by allowing the GGI3D runtime to gather, store or retrieve such information).


<Xavier>

If I am a programmer, and I want to provide a non-standard module with
my app, I have to be able to insert it where I want in the pipeline, and
the datatypes aren't enough for this!

Suppose I have something to do on geometry.
I reaaly want it to be inserted after the clipping, but the clipping
actually function doesn't appears in its entry types.

where am i wrong?


<Me>

You are not wrong at all, it's just that you are looking to the wrong
place to find the information you'll need. To find out what a module
does, you'll have to find out where in the "registry" hierarchy it falls.
GGI3D will have such a registry (even if it's integrated into native
systems like Berlin's registry), but GGI3D itself won't know what any
of the classifications mean; it'll be up to the client to know what
"clipping" is and what do to based on a module that is classified in that
category. GGI3D define the architecture of the system more than it will
define the function of any given part of it.

The complexity of doing this makes me think that there will be a minimum
of client-runtime alteration of the pipelines. Once this is conceded,
most of this problem is less critical because you'll have the time to
make more exhaustive investigations of the existing pipeline.

In fact, it may become preferable to disallow any client alteration of
the pipelines at run-time, but I'm not ready to take such an extreme
position yet.

<Or, as Jon put it...>

	Yes they are.  You can insert that module anywhere in the pipeline
that the module's interfaces allow.  That is *all* you know.  LibGGI3D does
NOT manage pipelines, it gives the programmer better ability to manage
his/her own pipeline(s).  *You* have to take care that you are managing 
your modules intelligently.

<Me>

My sentiments exactly.


<Jon>

	WOOPS!  Looks like I missed something.  I have been saying that a 
module is completely defined by its i/o interfaces, but obviously the 
*programmer* must have additional info in order to distinguish the module 
from another one that happens to have the same interfaces but does 
something totally different.  For that, you parse the module ident 
string.  Sorry for the confusion.

<Me>

Right, and more importantly, you'll need to know where the module sits
in the registry. For instance, an ident string of "Aaron's nifty clipper"
won't be useful to an application unless it's looking for my specific
clipping module. However, if it finds that my module is installed in
Geometry->Clipping->Volume (as opposed to Area which would be 2D clipping
or HSLR [Hidden surface line removal]).

Hey I just had a thought...we've been thinking of primarily 3D algorithms
here, but what about 2D? Even OpenGL can be used as a 2D API (as is done
in Berlin) and most 2D algorithms will be useful at one point or another
(for instance, rasterization) in the 3D pipeline.
 

<Xavier>

but still... I don't get it..

The programmer isn't here when the user tries to run the program.
So the programmer cannot know, when writting the program, what modules will be available to build his pipeline.
The only thing he knows is that there will be at least the standard components (or at least he can resonably count on that) in one form or an other. 
He can also require the user to get some specific modules.
But he doesn't know exactly waht modules are present.

What I want to say is that the programmer must have the ability to write a program that can manage all this. So the *program* needs to have enough info that it can understand.

(of course what enough means is left as an exercise for the reader...)

<Me>

He'll have to find it out via inspection. Again, most of this work will be
done sepeate from client execution, so there will be time to allow an indepth
examination. With composites in the picture, this process is simplified *alot*.

As for real-time manipulation of the pipeline, if that will even be allowed,
this will be minimal for exactly the same reason you mentioned, and it would
assume that the app has, one way or another, a detailed enough knowledge about
the pipeline to make such decisions.



Well I'm signing off now. Enjoy all ;-)

-- 

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