ug2iv issues

[Seth Teller <seth@graphics.lcs.mit.edu>]

we three (will, sean, myself) should caucus and talk about
this asap.  there are a few versions of ug2iv in place,
and none seem to do quite what we want.  i recommend that
we back up and talk about this problem as a whole, rather
than from the corner we happen to be in at the moment.

here are a few relevant observations.

first, ug is a simple, powerful format that's had a lot
of historical (pre-BMG) use at berkeley and MIT.  there
are a number of good ug tools in our codebase, for example
for manipulating geometry in fairly sophisticated ways.
however,  most of these tools are inoperable at the moment
due to disuse of the source code, build practices, and the
current team's lack of experience with UG data structures.
see the description of the ug text format at URL
  http://graphics.lcs.mit.edu/~seth/datasets/ug.fileformat

second, inventor is a good format for inspecting geometry
on the SGI machines.  it has recently migrated into open-
source, but i doubt it will ever be widely used by others.
my sense is that inventor's a good "terminal" format -- i.e.,
a good format into which we should convert *at the end* of
the pipeline, or nearly at the, for example if the terminal
stage is to be VRML.  but inventor is not a great inter-
mediate format.  why?  because we have few if any tools
that can read inventor files and manipulate the contents.

third, the scale and scope of our current effort preclude
using "flattened," or transform-free and definition-free,
unigrafix representations.  there's so much geometry, and
there will eventually be so much *repeated* geometry 
(doors, windows, furniture), that we simply must have a
reliable method of expressing it with DEFs and USEs or
their equivalent, i.e., not by inlining it.


given these observations, here are a couple of conclusions/
opinions:

  1) we should adopt ug as our lingua franca, and write
   only ug-to-ug filters for all BMG operations.

  2) all BMG operations should operate economically and
   exploit the instancing capabilities in ug.  for example,
   a door frame (left, right, top moldings) can be 
   defined once, then instanced repeatedly "to fit" into
   any doorway.  same for doors and windows.  

  3) we should write a single, powerful version of ug2iv
   that handles any ug we produce, and generates simple,
   well-structured iv for viewing and conversion to VRML.
   at a minimum, this converter must handle color, vertex,
   wire, and face statements, as well as defs, uses, and
   file include statements (triggering conversions of the
   included file into inventor, and issuing inventor File
   include statements that refer to appropriately named
   targets).


doing this right is going to require some discussion and
thought.  so, let's forge ahead.