From: Tristan Wibberley <bloater@ps.cus.umist.ac.uk>
  To  : ggi-develop@eskimo.com
  Date: Wed, 3 Feb 1999 11:43:58 +0000 (GMT)

Re: libggi3d non-clarity

On Tue, 2 Feb 1999, Aaron Gaudio wrote:

> And lo, the chronicles report that Xavier Bouchoux spake thusly unto the masses:

[snippage]

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

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

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

What if you're on a processor that's really good, and the video card
isn't. You want to do SW rendering all the way - but the app can't know
that.

> > 
> > 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 think both would be good. Let the app choose with #defines whether the
pipeline should be built at runtime or compiletime.

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

How is radiosity typically done?

--
Tristan