Use inlines to load geometry that is a long way from the start position of the viewer. Specify the bounding box to display something whilst the inline is being loaded.
Inlines can also be nested so that entire portions of the scene are only loaded once their parent inline is loaded. This could be used to show a box instead of a house for example.
Performance level of detail can be used to maintain frame rate automatically, whilst distance level of detail (explicit) can be used to use less polygons for objects further away. Also you can switch from rgb texturing to a material which has the same overall colour as the object gets further away.
Developers recommend (empirically) four levels of detail per object, the last one of which is a NULL object - achieved by an empty Group node. The other levels should decrease in complexity by roughly 5-10 times each level.
E.g. 1000 polys, 500 polys, 50 polys, NULL.
LODs can be combined with inlines to force loading of inlines only once they are within a certain range (if the browser is intelligent enough).
Download time is often crucial in maintaining a good feel to your world. As geometry compression will get better as a binary format is introduced, the problem lies with loading lots of textures. Here are some ideas for reusing textures:
Very simple small pixel textures are very effective and powerful. Try to develop a library of these and DEF them in your file and then USE them often to increase the apparent detail in the scene. Here is a chequer board effect:
DEF CHECKS pixelTexture { image 2 2 1 0xff 0x00 0x00 0xff }
First, find a small seal.....er no......
You can force intelligent browsers to cull your scene in ways you decide. Don't just make a flat scene graph but use hierarchies of groups. Each group forces the browser to try culling its bounding box against the view volume. If objects which are spatially close are grouped then they can be culled in one go without having to cull each one in turn which could be computationally expensive.
The real trick is in using enough groups and levels in the scene graph to enable efficient culling without making the scene graph overly complex and use more time traversing it with little overall benefit. This is a skill in itself and not something that can be easily measured.
Using the visibilityLimit field enables the browser to cull objects that are a long way off. Unfortunately, this usually has the effect that they snap into view as some point as the user navigates toward them. To overcome this, the fog node can be used to set the fog so that objects are completely fogged over as they enter the viewable range. Then they gradually fade into vision.
Fog does have some rendering impact though and this technique really only works for a small number of very complex objects.
If you have highly detailed objects which are symmetrical about an axis, consider using a billboard to represent them instead of geometry. This works well for trees, bushes, rocks, small objects, columns, goblets and so on. Remember to counter this rendering gain with download time.
Many browsers of automatic level of detail and efficient ways to render the geometric primitives such as sphere, cone etc. Use these as often as possible.
Many nodes have solid fields which enable the browser to cull back faces intelligently. Further some nodes have a ccw or counterclockwise field. This enable browsers to assume certain things about normals on the surface. Make sure these fields are set to TRUE if possible.
Turn off collision detection where it is not necessary (remember it is on by default). Define a collision node round objects and set the collide field to FALSE. This applies to the following types of objects:
Use collision proxies that are simple shapes (a sphere is a good idea!). This alleviates doing collision detection with the complex geometry itself. You might group many objects and use one proxy for them such as a box for a whole stretch of fence.