I didn't quite say that, but yes, compressed ASCII VRML is tight.
See the new entries in my re-formatted chart below, marked with
asterisk. Obj files are about as simple an ASCII format can be,
just lists of float points and int face enums.
BirdWlk3
3D Studio 80,186
VRML fat CR/LF 166,037
VRML fat LF 159,808 * 28,925 / 159,808 = 0.1809 = 81.9%
VRML fat LF.gz 28,925 *
VRML skinny 124,337
VRML skinny.gz 26,100 *
.iv binary 94,628
.ivb.gz 23,838 23,838 / 94,628 = 0.2519 = 74.8%
LightWave 56,476
Imagine 108,056
DXF 581,458
Sense8 NFF 118,273
Wavefront 105,346
Wavefront.gz 27,115 *
So is ivb.gz's 23,838 versus VRML.gz's 28,925 bytes significant?
Incidentally, the BirdWlk3 file including the keyframe animation
sequence is 91,341 bytes. As I recall, the bird walks along and
ducks its head between its legs to look where it's been.
No editorial message intended. :-)
>If the bottleneck is file transmission speed (and
>not the time it takes to parse the input), compression works just as well as
>a binary format.
Of course, performance of VRML is going to be the sum of many things
including transmission time, decompression, parsing and display.
I've heard anecdotal stories about compilers spending a great deal
of their time skipping comments and white space. Have you ever
profiled the Inventor ASCII parser code, versus the binary .iv reader?
>And supporting compression is a whole lot easier than
>supporting a binary format, since the code for gzip is already freely
>available.
I guess that depends on whether SGI wants to hand out a QvLib
that handles the Open Inventor binary format. :-)
- John