Steve Baker (steve++at++mred.hti.com)
Mon, 21 Aug 95 09:22:17 -0500
<Begin Flame>
I really feel that the Performer community should realise a
fact that other IG users/manufacturers realised around 15
years ago:
You really need a different file format for archive and
portability between systems than you need for loading into
the IG.
It is a cardinal rule of realtime work that you do everything
you can OFFLINE. That should include conversion of the
archive format into the realtime format for database files.
VRML/FLT/DWB may or may not be a good standard for the archive/cross-system
standard - but any scheme which is not utterly Performer-specific
will never become an adequate realtime standard. The opposite also
applies. Any performer-specific format will be too machine-specific
to be general enough to represent (say) E&S databases with separating
planes in them.
The effect of people trying to make one format do two jobs is
that one group of people will be trying to make it "more efficient"
by putting more IG-specific features into the format - whilst another
group will be trying to make it more IG-independent so that the files
can be used across a range of platforms.
VRML is a cross-platform format - and to expect it to be efficient for
some specific format is asking a bit much. FLT is also (I think) supposed
to be a cross-platform format - although it grows more Performer-specific
with each new release. DWB appears to be heading in the Performer-specific
direction too - direct support for t-mesh primitives is a good example.
Now, if everyone would accept the need to convert from whatever archival/
cross-platform format makes sense into whatever machine-specific format
is efficient, then we would all make more progress.
I personally believe that the platform-specific format should (in our case)
be something that Performer supports. Non-realtime convertors from archive
formats into realtime formats are conventionally called 'database compilers'
and 'database linkers' because they convert the external, portable representation
of a database into the 'binary, executable' form that we need for efficient
realtime work. There is a close analogy with programming language compilers.
C++ is a portable language - but to run it DIRECTLY (ie with an interpreter)
on your computer would be inefficient. Instead, you COMPILE it into a
non-portable, machine specific format called machine code. You can, at the
same time, LINK it with other chunks of code - which may, or may not - have
been written in C++. The compiler does optimisations for you, so to some
degree, we don't have to worry about how efficient a representation C++ is
for our specific architecture.
Here at HTI, we have database compilers to take a number of formats and
convert them into our own proprietary 'PRF' (Performer Runtime Format)
files. The compilers can take quite a time to convert files from some
formats - but we don't much care. As for 'efficiency', all of our allowed
input formats come out equally efficient as PRF files, although the
conversion times vary considerably. Since we really don't care how long
the process takes, we can spend much more effort on things like forming
triangle meshes than do the existing Performer loaders.
When it comes to database paging (New in Performer 2.0) - you really
need an efficient binary format - there is no time to be messing
around sorting GeoStates, forming Tmeshes, calling cutesy pfuBuilder
routines.
<End Flame>
Sorry about that - I had to get it off my chest.
Steve Baker
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