Hmm, a long discussion of binary VRML without a mention of
Open Inventor's presently undocumented binary Inventor file format.
>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.
Here are some real-world file size comparisons.
I started with two 3D Studio objects, a simple cube, and the 3DS demo
file "birdwlk3". I stripped all motion from the files.
Cube has 1 object, 8 points and 12 faces and 1 surface.
Birdwlk3 has 41 objects, 1,901 points and 3,265 total faces.
3DS VRML(f) VRML(s) Inventor(b) Inv.gz
birdwlk3 80,186 166,037 124,337 94,628 23,838
cube 2,265 1,201 2,704 732 358
LightWave Imagine DXF Sense8 NFF Wavefront
birdwlk3 56,476 108,056 581,458 118,273 105,346
cube 436 676 2,312 639 557
VRML(f) means "fat" with indentation of whitespace of 8-char tabs and spaces,
MS-DOS CR/LF endings.
VRML(s) means "stripped" with no indentation, single spaces, and the same
number of Unix LF endings as (f).
3DS to VRML performed with Syndesis's InterChange, along with all other
conversions,
except VRML to Inventor 2.0 binary (b) performed with 'ivcat -b'.
See cube.wrl below.
This LightWave object has no hierarchy. The Imagine file does. Without
hierarchy,
the Imagine file is 98,280. Imagine is 16.16 fixed-point, but also
contains edge lists.
Sense8, Wavefront and DXF are ASCII formats, LightWave is binary.
DXF as 3DFACE entities, objects as layers, surfaces as pen indexes, CR/LF
endings.
Also, I'd point out that BIRDWLK3 is still regarded as a "small" scene
in terms of polygon count in the 3DS world. By comparison, a TV network
model of OJ's house is approximately 1.2 meg in 3DS format, with
31,423 points and 43,167 faces. Much larger scenes exist, of course.
My SWAG on the above numbers says that a tokenized and gzip'ed VRML would
do the job quite nicely. See Inventor binary hex dump below. Byte tokens
(with an escape for two-byte codes, natch) would make Inventor binary
even smaller, and gzip still did a good job on them.
>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 agree! I don't know if a binary format can reduce 2 meg VRML worlds
to 20K, or if it will cause people to make 2 meg worlds simply because
they can. Either way, we'll eventually arrive at discussions of the
reasonable number of polygons for scenes to be rendered on different
popular computers and VRML engines.
Enough of the hard facts, on to whining and complaining! :-)
>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?
Of course, the cynical side of me says that modem speed doesn't matter.
Instead, many people work through lousy providers who don't deliver
28.8 kbps continuous, not to mention overall net throughput. Dividing
the size of the scene by the modem speed will not equal the download time,
not to mention the rendering speed on their 486/33.
>It's beautiful, but it's a little fat. Each floor of the gallery is well
>over 1 MB - sometimes 2.5 MB.
How many ordinary Web pages do you visit that contain >1 meg of data
that must be downloaded per-page before you see anything nifty?
>The Macintosh has, in its Toolbox, the concept of fixed-point numbers.
Oh, yeah, like they invented it. :-)
>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;
In the past year or so, I've received maybe two dozen CIS/AOL/Prodigy kits
containing 1.44 meg floppies, but only one or two CDROMs. Floppy vs. CD
prices are still 1:2 or higher, not to mention the cost of product content,
which is probably 1:200 or more, depending on how many megs of content you
put on CD. The entire Avalon site, for example, is yet under 200 megs, and
that's for only several hundred unique models, not counting format-dupes.
>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.
I've already heard rumors about such forces of evil. Of course they will
attack VRML at its recognized weak points, probably using the criticisms
from this very mailing list. Or, for example, let's say they get the jump
by releasing freeware viewers for several popular PC platforms.
>>No repository or CDROM could possibly contain "enough" models of
>>"common objects" (real and imaginary, I presume). And where's the
>>originality in scenes made up of the same 3D models?
>
>Most all of the real world is made up of a few hundred basic shapes,
>endlessly repeated. Light bulbs. Stairways. Ceiling tiles. Electric
>outlet wall-plates. And so forth.
And this is precisely why you don't want to rely on standard libraries
when rendering speed is a concern or transmission speed is limited.
The "best" VRML sites will be ones that render quickly on common PCs.
Why doesn't HTML include a mechanism that says "give me a picture of
a oak tree"?
Let's say you determined that 2,000 models were needed for a decent
repository. And then you're going to create and store five variations
of each, using a decimation technique to reduce polygon counts? And
then define a descriptive language that will fetch the right model?
Perhaps the text-based "You are in a maze of twisty passages" VRML
isn't so far-fetched. Perhaps you want to describe scenes in English
and not VRML.
- John Foust
- Syndesis Corporation
Cube.wrl:
#VRML V1.0 ascii
Separator {
MaterialBinding {
value PER_FACE_INDEXED
}
NormalBinding {
value NONE
}
# 1 materials
Material {
diffuseColor [
1 1 1, # 3DS default surface (white)
]
}
# 1 object
# Object 'Object01'
Separator {
Transform {
center -77.278 -17.301 35.7555
}
Coordinate3 {
# 8 points
point [
-113.033 71.511 -53.0565,
-41.5225 71.511 -53.0565,
-41.5225 71.5109 18.4544,
-113.033 71.5109 18.4544,
-113.033 6.93526e-006 -53.0565,
-41.5225 6.93526e-006 -53.0565,
-41.5225 -2.67287e-006 18.4544,
-113.033 -2.67287e-006 18.4544
] # point
} # Coordinate3
IndexedFaceSet {
coordIndex [
0, 1, 2, -1,
0, 2, 3, -1,
0, 4, 5, -1,
0, 5, 1, -1,
1, 5, 6, -1,
1, 6, 2, -1,
2, 6, 7, -1,
2, 7, 3, -1,
3, 7, 4, -1,
3, 4, 0, -1,
4, 7, 6, -1,
4, 6, 5, -1
] # coordIndex
materialIndex [
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
] # materialIndex
} # IndexedFaceSet
} # end of object 'Object01'
} # scene Separator
Hex dump of binary Open Inventor file:
/hex cube.wbb
0000: 23496E76 656E746F 72205632 2E302062 #Inventor V2.0 b
0010: 696E6172 7920200A 00000009 53657061 inary .....Sepa
0020: 7261746F 72000000 00000000 00000004 rator...........
0030: 0000000F 4D617465 7269616C 42696E64 ....MaterialBind
0040: 696E6700 00000001 00000005 76616C75 ing.........valu
0050: 65000000 00000010 5045525F 46414345 e.......PER_FACE
0060: 5F494E44 45584544 00000000 0000000D _INDEXED........
0070: 4E6F726D 616C4269 6E64696E 67000000 NormalBinding...
0080: 00000001 00000005 76616C75 65000000 ........value...
0090: 00000004 4E4F4E45 00000000 00000008 ....NONE........
00a0: 4D617465 7269616C 00000001 0000000C Material........
00b0: 64696666 75736543 6F6C6F72 00000001 diffuseColor....
00c0: 3F800000 3F800000 3F800000 00000000 ?...?...?.......
00d0: 00000009 53657061 7261746F 72000000 ....Separator...
00e0: 00000000 00000003 00000009 5472616E ............Tran
...