VRML List Members:
With the completion of the VRML 1.0 specification - and a hearty
hip-hip-hooray (3x) to Tony & Gavin for their fine work! - we can begin to
open the door on VRML 1.x issues. We have tried to hold back the
specification process for VRML 1.x until VRML 1.0 was completed, to avoid
confusion and creeping feature-itis. It looks like we've been able to do this.
VRML 1.0 is a solid foundation, but it's only just that; something upon
which we can build a house, but offering little protection from the elements
in itself.
The most fundamental of these elements is bandwidth. VRML is about
delivering 3D worlds over the Internet; this means that VRML must be as
bandwidth conservative as possible. Like a well-written algorithm, VRML
must be expressive, elegant, and concise. These may seem to be a
contradictory set of requirements - in some ways they are - but we have to
remember that the user's experience with VRML is really all that counts.
If that experience is disappointing, people will abandon VRML in search of a
better solution, and all of our hard work will be so much dust in the wind.
***
For the last 3 months, a crew of 15 people has been creating a VRML tour of
the Interactive Media Festival's gallery. The festival is next week, in Los
Angeles - but you can tour the gallery, before it opens, by going to
http://vrml.arc.org.
This is the first large-scale piece designed specifically around VRML and
its capabilities. It was completed almost entirely on PCs - there's plenty
of design information at vrml.arc.org for the interested - and, as it is
unveiled over the next week, the whole world (equipped with WebSpace or
WorldView, anyway) will be able to take a look at the future of computing,
the future of Internet.
It's beautiful, but it's a little fat. Each floor of the gallery is well
over 1 MB - sometimes 2.5 MB. That's just too big for people. How often do
you download IUMA's "Song of the Week" at 14.4 Kbps for a 4 MB file? That's
a long download, and more time than most people want to spend.
ISDN's not ubiquitous yet, and 28.8 Kbps modems, while growing inexpensive,
are hardly common. Are we going to force everyone onto a T-1 to enjoy VRML?
***
I have been thinking about a binary format for VRML since my first posting
on the subject - when we got a hint of how big the files would really be.
All of these calculations have been done in my head. It should be very easy
to subject them to numerical analysis, on real data files, but most of us
haven't the time, right now, to perform these calculations ourselves. I
look toward anyone who has the desire to perform the analysis and report
back to the list.
***
Here are the suggestions:
1) Tokenization of keywords
The VRML 1.0 keyword set is full of compound words, like PerspectiveCamera,
Translation, or IndexedFaceSet. These are human-readable keywords, but the
computer certainly doesn't care about them. We have well under 255 keywords
in VRML 1.x, so a single-byte token stream for keywords would save as much
as 90% of total file size.
2) Fixed-point Arithmetic
As has been pointed out by James Waldrop, most 3D modeling programs are
rather over-enthusiastic in the degree of accuracy with which they describe
the points in the IndexedFaceSet and IndexedLineSet operators.
These numbers are generally given as IEEE floats (perhaps even IEEE doubles,
at 64 bits a shot) which is, except for CAD, much more resolution than any
normal VRML file will ever need. Dynamic range is important, but picometer
resolution is not, in the general case.
Furthermore, as most translations take place scoped within a Separator node,
the dynamic range of any portion VRML file tends to be quite small, while
the overall range might be quite large.
The Macintosh has, in its Toolbox, the concept of fixed-point numbers.
These are generally 16 bits in length, and range +/- 128 in their integer
portion. This leaves 8 bits for the fractional portion, which can describe
objects with a resolution of 1/256th. This is quite suitable for most
applications of VRML.
Nonetheless, we shouldn't throw away our IEEE 32-bit floats. We'll still
need them. This suggests that we have a new keyword in VRML 1.x, which will
switch the interpreter stream from FIXED to FLOAT numbers, on-the-fly. This
would be analogous to the hex and dec C++ stream operators.
In this way, the VRML world creation tools can make the decision of which
numeric format to use - or VRML file optimizer tools could do it.
(I expect that when we agree to a binary format, someone will quickly write
a C++ program (using QvLib) or PERL script that will convert existing VRML
1.0 files into VRML 1.x binary format.)
This would bring the expression of most numbers in a VRML 1.x file from as
many as 10 ASCII bytes into 2 binary bytes, a savings of 80%. In the worst
case, where a number is converted into an IEEE 32-bit float, there's still a
savings of 60%.
3) File Compression
The only standard we've been able to agree to thus far, for a binary format,
has been to use GNU GZIP/GUNZIP as file compression and decompression tools.
It seems reasonable that this should continue, and will become integrated
into the browser itself. Even with the economies described above, file
compression will yield at least another 30% - 50% decrease in the overall
file size.
4) File Header
The file header for VRML 1.x binary files will have to change to read:
#VRML 1.x binary
5) Universal Resource Names * Caching * CD-ROM
This is the subject of an upcoming post, but it deserves mention here, as
well. Any caching strategy combined with CD-ROM and a universal resource
name will act as a de facto compression mechanism; you don't retrieve
objects you already have. The savings here could be as much as 99%.
It is quite likely that as commercial VRML sites become common, they will be
combined with a CD-ROM cache distribution strategy. These CD-ROMs will
become as commonplace as those AOL/Prodigy/CIS starter disks are now; pop
one into your CD-ROM drive, and you don't need to download the objects and
textures themselves, just their arrangements.
***
This is not intended to be an exhaustive list of recommendations; I believe
we should throw everything into this that is proven to be effective - and
*always* sacrifice computing time to bandwidth. The ratio between bandwidth
and MIPs is still growing asymmetrically; MIPs are cheaper by the day,
bandwidth much less so.
We can expect that as we make it possible to get more world for less bits,
designers will up the complexity of their worlds appropriately. Some things
never change.
I see this as *the* top priority for VRML 1.x; without an effective binary
format, very few people will ever care enough about VRML to use it.
I look forward to your comments on this.
Mark Pesce
VRML List Moderator
[email protected]