In order to keep our worlds interactive and comfortable to use we need to ensure that system lag is kept to a minimum. Lag is the time it takes for a change in the virtual world to be reflected on the display. Lag can be caused by transport delays, where the system takes a while to respond to user input, or by a low frame rate. If the system is not able to update the display quick enough then the result is discomfort for the user.

In this lecture, we will be concentrating primarily on ways in which we can maintain a high frame rate, while keeping the virtual world interesting and (perhaps) attractive to look at. Before we look at a few techniques in more detail, we will discuss some general issues that affect performance.

A good general tip is that you should always start out the task of building a virtual world by deciding who your audience is and thus what is the minimum target platform is. Decide what the minimum frame rate should be for the minimum platform and do your best to achieve it. In general you will rarely want a frame rate less than 8-10 fps on the minimum targer platform.

The renderer/browser does a lot of work for us in trying to update our virtual worlds, but by giving it hints, we can dramatically increase it's ability to run smoothly.

The most obvious place to start is by looking at the geometry. In most cases we should try to use as few polygons as possible in our models (the exception to this is very large objects which should be spatially subdivided if they are typically only seen partially by the user). Models that are exported from CAD systems and some 3D modelling systems can have far more polygons than necessary and should be reduced.

Consider using textures instead of modelling lots of detail, but be aware that many large textures (256x256 or larger) will also affect performance so keep them small (ideally less than 128x128), and note that most renderers work most efficiently with textures that are equal in width and height and are powers of 2.

The structure of the scene graph itself also has a significant effect on performance. Nodes should be organised spatially and you should avoid unnecessary groups (don't make the graph deeper than necessary as it will be more work for the renderer to traverse it). Poor spatial organisation of virtual worlds is one of the most common reasons for poor performance in much of what is available on the net (and elsewhere) today. The reason for this is that the renderer tries to cull the model to improve performance and does it by examing grouping nodes. If you put two objects that are far apart in the same group then you hamper the renderers ability to cull the model efficiently. In particular, try to place objects that are high up in the scene graph as far apart as possible.

Static objects that share the same appearance and are located spatially close to each other can be merged to improve performance, although very large (as in number of faces) indexed face sets should be avoided.

You can also help the renderer manage scene complexity by actually turning on and off geometry, using proximity sensors. For example, there is little point in rendering the inside of a building if the user is outside it. Levels of detail (more on that a little later) are also very useful but will not work in cases like the one above. Other programming constructs can also be used effectively to manager the scene complexity.

Also, to improve download time, improve memory efficiency, and make authoring easier, always use DEF/USE (or equivalent) to instance geometry rather than copying it. In the case of VRML, you can also gzip files to make them smaller and faster to transfer/load.

Don't be afraid to take away some control from the user to make your work function as intended. In most cases it is a good idea to embed a VRML model in a web page in order to prevent the user from trying to view it at 1280x1024 on a 90MHz Pentium without 3D hardware acceleration. Also consider making a couple of different versions of a virtual world; one in its full glory with high-resolution textures, lots of detail, and a larger viewing window, and a "light" version so that others can also enjoy it (albeit to a lesser extent, perhaps).