>>And I don't think any of these will be good enough. We need good tools to
>>automatically create low levels of detail and smart browsers that know not to
>>pull across huge files (= the higher levels of detail) unless the user says
>>that they are willing to wait.
I completely agree with this. A combination of well made models, gzip
compression, and caching browsers are the answer.
>That is true for VRML-as-OI, which is most files in the VRML universe right
>now, certainly most files any of us are familiar with. However, in 12
>months, things will probably look a lot like this:
>
>#VRML 1.x ASCII # imperfect example of highly tokenizable VRML
>
>Separator {
> DEF OBJECT_ONE {
> LOD { blah, blah, blah
. . .
>
> # and so forth, until the entire scene is defined...
>}
>
>There aren't many numbers in this file at all, but there are lots of keywords.
Yup and gzip compressed this segment by 82.9%.
>This file could be at least 10x more compact with a token/compression scheme
>- even leaving fixed-point math out of the equation - and would still be
>more compact than compression alone, probably significantly so. The
>difference between 60 and 90 seconds is highly important, as far as the user
>is concerned.
Nope. gzip compressed this file by 83% to less than 250 bytes. Tokenizing
this would have led to very minimal reductions.
I also believe that these minimal savings are out weighed by the
complexities introduced by the binary format. A binary format would have
the following problems:
- machine dependant issues such as byte sizes and byte ordering (endian-ness).
- makes it much more difficult to change the spec. in the future
- limits the number of node types we can have and the number of object
you can have in an environment -- granted not really a serious problem.
- not human readable.
Keeping it in ascii gives us compression which is nearly as good, and keeps
several useful advantages.
Len Wanger
Interactive Simulations, Inc. Email: [email protected]
5330 Carroll Canyon Rd, Suite #203 Phone: (619) 658-9783
San Diego, CA 92121 FAX: (619) 658-9463
http://www.intsim.com/~isigen