First, a meta-question:
>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.
Which reminds me of something I've been starting to wonder. Over the
past several months, there has been a tendency to refer to "1.x" and
"2.0". I'm just curious -- do people have opinions about what these
are going to mean? We've got a *huge* wishlist of features stacked up;
obviously, not all of them are going to get into the next release. I'm
just wondering whether anyone has given any coherent thought to when
we're going to declare a "major release" of the language, as opposed
to a "minor" one. Not critical; just food for thought...
>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.
Check; this makes plenty of sense. However, a suggestion: let's make
sure we leave room for an expanded keyword set. We're well under 255
keywords now, but I'm not confident that we will remain so forever.
I'd suggest a one-or-two byte format, with the high-order bit indicating
whether it's a one or two byte token. Put the 128 most common keywords
into 1-byte tokens, and we've got nigh-infinite expansion space for more
later. We get most of the benefit, with *far* less risk later.
(Okay, so I'm overdesigning a bit. I think it's better to address these
things now, while it's easy, rather than have a crisis two years down
the line. Binary formats are especially persnickity, and harder to
patch later.)
Also -- while we will need a token equivalent to "}" (or something to
indicate the end of scope of a node), do we need anything for "{"? Or
can we simply assume that "{" is folded into the node name?
(I will admit that there's a real temptation to do something like
Huffman coding here -- a few keywords, like "}" and "Separator {",
are going to be so common it almost might be worth keeping them down
to four bits. Probably more hassle than it's worth, though...)
And we should bear expansion in mind. Extension nodes will (by
definition) not be part of the standard, so they won't have
predefined tokens. We should chew on how to handle them. We
could run them in full ASCII, or have some kind of prelude that
defines (for the duration of the file) the token for that
keyword, or maybe something else. There are numerous ways we
could deal, but we will need to choose one.
>2) Fixed-point Arithmetic
> [...]
>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.
Theory and practice war within me. The purist positively shrieks at the
concept of using such a coarse grain for numbers. The pragmatist points
out that this is (assuming 1 unit == 1 meter) about 4-millimeter precision
and a really big range, and may well be good enough for many objects.
Okay, given that we'll still have the full-precision floats, I guess I
don't mind too much. I might suggest, though, sacrificing two more bits
from the integer portion (giving us a maximum range of 32 meters) and
putting them into the fractional portion (giving us millimeter precision).
I think that we're likely to want the precision more often than the size,
especially in object descriptions (which is, I suspect, where the
considerable bulk of numbers will be used)...
>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.
Again, the purist in me finds it inelegant, but it's probably efficient,
so I'll stifle the argument. Question, though -- how do we translate this
into our data stream? Is it conceptually a node? (Everything else is, so it's
probably easier if we remain consistent.) If so, is it a container like
a Separator (everything in me is FIXED) or does it affect everything after
it like a Transform (everything after me is FLOAT)? Probably the latter,
but let's get it clear.
>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.
Amusing. This one hadn't occurred to me, but you're probably right --
it matches the way the big companies are thinking these days, quite
well. And distributing a CD-ROM of objects for a particular application
is *much* easier than doing so for general purpose...
>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'm not quite *that* hot on it -- I think we need rudimentary behaviours
just as much, to make cyberspace *interesting* enough to be worth it.
(And probably some mechanism for connecting worlds better, be it portals,
CP, both or neither, to make the whole thing *feel* more natural.) But
yes, it's at least *one* of the key things to deal with next...
-- Justin
Random Quote du Jour:
"You can END asparagus in your lifetime."
-- John Woods