Postproduction

Have you sat watching a world download and download and download, only to give up and go somewhere else? There is no VRML scene that you can't tweak and improve. Here's an example:

• A space station pretty much as it came from the repository, after converting it to VRML 2.0 (160K). Some VRML browsers will complain because the converter created some illegal values. So we'd have to tweak this world anyway, just to stop the complaints. Which brings us to our first lesson: never, never publish a world without running it through a syntax checker. There are some syntax checkers on our tools page. Get one and use it every time.
• Here's the same model after tweaking (18K)

Notice that the smaller model not only has nicer lighting and coloring (an essential part of every tweak), but has a more realistic looking truss, and has twice as many modules. It's hard to beat smaller and nicer.

Most of the tips below have to do with making your world smaller and faster, but there are a few that have to do with good design and common problems that need to be fixed at this stage.

There was a day-long course on this subject at VRML 97 in Monterey conducted by David Story, Delle Maxwell and David Marsland, and during the general sessions Sam Chen from SGI held forth on the subject for a while (in fact, his talk was so popular that when the session ran short, he was called back to talk some more).

Here are a few nuggets of wisdom from VRML 97:

• There are two parameters you need to worry about: download time (minimize that) and frame rate (maximize that). Frame rate in turn is due to two factors: polygon rendering (minimize it) and sensors (turn them on only when they're needed).
• Modelers and converters are evil. That's a quote from Sam Chen. Don't believe him? Check out these comparisons John Nikkel (Ragtimer) did. Use modelers only when you absolutely have to, and do what you can to reduce the polygon count. Don't use the modeler to extrude objects; use the Extrusion node.
• Start inside a building. That way, you can load the inside of the room pretty quickly and while the visitor is wandering around, you can be loading the outside.
• Use ProximitySensors and VisibilitySensors and LODs liberally. There is no excuse for making your visitor wait 5 minutes while something he can't see downloads. Likewise, you don't need to be scanning for mouse clicks on objects that are off the screen (have VisibilitySensors enable your TouchSensors, etc.).
• Reduce polygon count. A program called LODESTAR is available at http://www.cg.tuwien.ac.at/research/vr/lodestar/ that not only generates LODs, but it can be used to extract a given LOD (wonderful for polygon reduction) and combine IndexedFaceSets. However, LODESTAR will mess with your geometry at high LOD numbers, and it assumes that your surfaces are already sparsely tessellated. This isn't always true. A new tool called Flamingo Optimizer does a terrific job on mesh decimation.
• The overhead of HTTP for Inlines and external textures may be excessive. Put everything into one file and see if it makes a difference.
• Substitute textures for object detail. Sam Chen showed some palm trees whose branches were a single 4-point IndexedFaceSet with a Billboarded transparent GIF. You need to experiment. Sometimes texture images load and render slower than equivalent geometry.
• Trade study the advantages and disadvantages of combining several IndexedFaceSets into one (provided the Appearance is the same). On the one hand, separate objects make a larger scene graph. On the other hand, many browsers can't cull out invisible faces unless there are separate IndexedFaceSets for the backfaces.
• Get rid of the data fat. Many modelers will generate 8 digits of precision, which is absurd; a difference in the third significant digit translates to slightly more than one pixel at 1024x768 -- though you'll need to think about each of your scenes where the visitor is likely to look close up, and provide more precision there if it's called for. James Waldrop has a VRML datafat munger at http://www.construct.net/vrmltools/datafat.html.

Here are some more tips, courtesy of Hallee Wachsmuth <hwachsmu@gmu.edu>, robert.free@graphcomp.com (grafman), and The VRML Sourcebook:

• Minimize the use of lights
• Minimize the use of texture mapping
• Use only convex faces
• Use the fewest coordinates possible
• Reduce the detail of distant shapes
• Break up big objects into smaller ones
• Re-use nodes
• Stylize/simplify forms when possible
• Use VRML primitives when possible
• Minimize intersecting nodes

And a few of my own:

• Use indentation, blank lines, and comments while you're building your world to help you debug it. Add DEF names to all your nodes to help you find them in a scene editor. Once you've got your world nailed down, get rid of all the comments, unused DEFs, blank lines, and extra spaces.
• Windows and DOS machines end each line with both a carriage return and a linefeed. Transfer your files to your ISP in ASCII mode (assuming their machine runs Unix) or use a vi editor, and you'll save one byte per line; this can add up when your visitors are downloading over a slow connection.
• It's usually worthwhile to replace IndexedFaceSets that represent spheres, cones, boxes, and cylinders with their equivalent basic nodes. On the one hand, it makes the file much smaller; on the other hand, the browser may slow down because it renders the basic geometry nodes with more points than you would have.
• Comment out one node at a time and see how it affects your scene. Modelers often generate duplicate objects or objects that are inside other objects and thus invisible.
• The truism in engineering is "break down big things into smaller things". As we've seen from the comments above, too many Inlines may be a bad thing for browsers that take a long time to download. But some things can be very profitably be broken down into smaller things, particularly when you can DEF and USE them.
• Although the spec says the PixelTexture node requires its arguments to be in hex, all browsers I know of accept '0' in place of "0x00".
• Use USE as much as you can. Here's a tip borrowed from SGI's VRML 1.0 to 2.0 converter:

       Shape {
         appearance DEF RED Appearance {
           material Material {
             diffuseColor 1 0 0
           }
         }
         geometry IndexedFaceSet {
       ...
  
       Shape {
         appearance USE RED
         geometry IndexedFaceSet {
       ...

• Another USE trick: if you ROUTE to a node, say, to animate it, all the copies of the node you create with USE will animate, too. Imagine all the petals of a rose opening with one ROUTE!
• Flashing surfaces are caused by the Z-buffering used in many rendering libraries. Very often playing with the scale factor can make the flashing go away (or appear somewhere else!). Steve Hollasch at Microsoft has a paper on the subject, Jim Dunn pointed out an interesting way to cure it with some objects, and Jed Hartman posted a way to minimize it to www-vrml.
• Since I first wrote these notes, a number of VRML post-production tools have appeared. Check the tools page for details. Why do it by hand?
• I collected a few more thoughts on scene tweaking and post-production in an article for InterActivity magazine.

Know some other tips about tweaking your scene? Let me know.