Steve Baker (steve++at++mred.hti.com)
Tue, 22 Aug 95 12:42:59 -0500
pfPeople -- or maybe pfVictims would be preferable here :-)
> One interesting concept that the Medit folks have for the
> future is the idea of saving the graphics objects to disk inside
> of a Performer app(e.g. perfly).
Coryphaeus' DWB has a similar concept - a "Performer Writer" as
they call it - I think they give it away for free.
FYI: MultiGen Inc have some kind of legal problem with you writing
a similar thing for "Open"Flt without their permission - BEWARE.
> This might be a great time to
> bring all the different formats together after loading and writing
> them out to a specific new format that is performer specific.
This works OK for small databases - but the problems come with
large databases when it becomes impractical - or undesirable to
write out the entire database tree into a single file. The problem
is that you started out with maybe a dozen little files, you load
them into Performer and the write them out - but the Performer
loaders didn't note where the file boundaries were - so the file
writer can't recreate the original file structure.
This gets much more difficult when you want to start database paging
and stuff like trees and bushes need to be referred to by all of the
terrain tiles - but stored just once somewhere globally.
> Then, of course, the various modelling tools would need to be able to read
> this format...
Um...yes...and this format would be..."Open"FLT? DWB? VRML? Medit?
This idea suffers from the problem that Performer does not store
*ALL* of the original information. For example, with FLT, MultiGen
stores transformations both as a set of rotations, translations and scales,
and as a matrix. When you load this into Performer, all the separate
transforms are discarded and only a pfMatrix remains. Thus, if you were
(hypothetically) to use a LoadFlt() invokation to load the file and
then a SaveFlt() to write it back out again, you would lose the information
about how the original transform was modelled - you can't reproduce the
original information because there are multiple combinations of heading/pitch/roll
angles that can be formed from a single rotation matrix. This might make it hard
to go back and make a change to the transform using MultiGen.
Another problem is that some loaders do different things on different
workstations (I recollect that LoadFlt() doesn't load texture maps
on low-end workstations) - hence you might be unable to convert databases
on low end machines without losing something.
I'm sure that there are other cases of information 'leaks' whenever a loader
throws away some information from the file. Some of these are important, some
not so.
So, the idea of reading into an in-memory representation using one of a
range of available loaders - and then writing it out again - only works
if the in-memory representation is able to store absolutely everything
that the original file had within it. Performer could be made to act as that
in-memory representation if loaders were more careful about preserving non-
Performer data in pfUserData() connected into the tree. Of course, they'd
all have to agree on what that data means.
Our database 'compiler' here at HTI does use a range of loaders and a range
of writers which share a common in-memory representation - but that representation
is not Performer. This has several benefits, one of which is that our compiler
can run on non-SGI hardware (is that heresy on this email list?).
Steve
o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o
Steve Baker steve++at++mred.hti.com (Email)
Hughes Training Inc. 817-695-2478 (VoiceMail)
2200 Arlington Downs Road 817-695-2308 (Voice)
Arlington, Texas. TX 76005-6171 817-695-2555 (Fax)
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:49 PDT