> VRML is about delivering 3D worlds over the Internet...
Why is that? I have trouble seeing why VRML should be focused on the
interenet. That is why I have problems with such specific keywords as
WWWAnchor and WWWInline. IMO, this same functionality could have been
provided without making it "Internet" specific. Now that it is there, it is
fine, but I don't see why we should regulate the utility of VRML to the
internet. Just as companies may have hoards of related content on their
local volumes in HTML format, one should be able to do the same with VRML.
As I see it, VRML is an ODL, nothing more and the more specific you make it,
the less general its uses become.
>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.
>
Absolutely, and well said.
>
>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?
>
Certainly not, but those problems should be able to be resolved without
adding transport information to the ODL. For what it is worth, however, I
don't see things like a binary formats (although I don't know if VRML lends
itself to anything other than compression, its not exactly BNR friendly), to
be out of character for an ODL or ODL compiler.
>
>1) Tokenization of keywords
>
This sounds good to me.
>
>2) Fixed-point Arithmetic
>
This sounds *really* good to me. One could actually create a pretty precise
virtual float by going as far as using DWORD(s) for a scaled float class. I
don't know how much this would decrease file size, but with an appropriate
engine, it would dramatically increase the rendering speed and therefore the
speed at which a user can interact with a world. By playing around with
ranges, magnitudes, conversion to LONGs and what not, I think one would be
suprised by what you *wouldn't* lose. However, I know that VRML is closely
coupled to the OpenGL library and that may be too much for people to let go
of. Of course, the user doesn't care whether it is rendered by OpenGL or not.
>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.
Okay, now I can see that what I have suggested is much more radical than
what you have presented here. Maybe what I am envisioning is impossible, but
it may be worthy of some research and I know that a lot of 3D modeling
languages and libraries have recently switched to floats and fixed
represented by integers.. As for your suggestion, It certainly seems doable
though I am somewhat worried about representing different numeric types
contemporaneously. It may create confusion or bottlenecks.
>
>3) File Compression
>
Sure, anything would be fine here.
>
>5) Universal Resource Names * Caching * CD-ROM
>
I guess I don't see why this can't be done now?
>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.
I'm not sure I can agree with this categorically, but I hold this same
belief in general.
>
>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 think rendering speed is a big deal as well. Possibly, as big.
Robert