For our final chapter, we'll look at specific areas of the Web Driver API that deserve some caution. These areas include:
- Collision detection
- Other objects
As mentioned in the previous chapter, having lots of lights can be expensive- you should use only as many lights as you need, and
set the light ranges to an appropriate distance.
- If you really do need lots of lights
for complicated scenes, but you don't need them to affect world geometry, consider using dynamic lights in WTStudio- Static lights affect
the level's lightmap, which will either mean a longer download time or level load time, depending on if you are using dynamic lightmaps.
- Spotlights are also expensive compared to point
lights; you should only use spotlights if you really need the spotlight's
The collision engine in the Web Driver saves you as a 3d application developer from one of the most difficult aspects of 3d programming;
but, if used improperly, you can inadvertently bog your app down by using collision checks that you don't need. Some ways to improve
collision efficiency include:
- Avoid polygon-accurate collision if you don't need it: Polygon accurate collision is a powerful feature, and it's necessary
in some instances (such as interacting with world geometry), but in other instances, you don't really need it. Using bounding
boxes for collisions can be a real time saver.
- Use collision masks: With masks, you can reduce the number of collision checks that have to be made for each render, so you aren't performing any
more checks than you need. It's also important to take advantage of hierarchical collision masks: If you have a large
number of objects that are children of one group (such as with a particle effect), and you don't need to check collision with
each of the objects, set a collision mask for the parent group- this will speed up collision checks immensely, as each object's
collision mask won't need to be read.
- Set your collision masks in WTStudio: Not only is it convenient to do so, setting your collision masks in WTStudio will
save you API calls.
- Don't expect collision to work after the fact: If two
objects are already intersecting, no collision will be detected when the objects move;
if an object goes outside the bounds of BSP geometry, collisions will stop
working. In general, always test collision distance for the distance your object is about to move.
- Mask off collisions for any objects you don't need to check: All objects in WTStudio have collision masks, even ones that don't
have geometry and will never produce collisions, such as lights and sounds. The reason that these objects have masks is that
subobjects can be attached to them; but, if you're not using sub-objects of these objects, you should set their masks to zero.
- Check collision stats: You can test your collision efficiency by monitoring the data in the Stats overlay (accessed through
the debug window). This is a good way to check if changes you make are for the better.
- Don't use the collision API if you don't need it:
While the collision API might make some operations faster to write, collision
checks are very high-budget from a processing point of view. If you are
performing an operation that you could figure out a way to code without the
collision API, you probably should. As an example, if you're writing some sort
of race game, and you want to detect when your player reaches the
finish line, it would be much more efficient to check the player's position,
and compare it to where you know the finish line is, rather than to check for
the player's collision with the finish line object.
Actors give you access to the latest features of the Web Driver, such as mesh deformation, LOD optimization, and material effects.
But, as with all flashy features, they are also resource-intensive, and are a point to watch when creating an efficient application.
- Actor motions: When using
blendMotion() with actors, avoid using looping animations- even when an animation is
blended down to zero, it will still be loaded in memory. Use non-looping animations and control flow of them yourself if
you are going to be blending between them.
- Creating Actors: Since actor files tend to be large,
if you can get away with using the same geometry for several actors, this will
improve your load times. If you need multiple actors, you should create them
all at once, as this will give the engine a chance to optimize the process.
Some other particulars of the Web Driver API that you can use to economize your application include:
- When using planes, use the optional parameter to reduce the polycount of the plane if you don't need complex lighting effects.
- With visualizers, there are two methods that can get data from the audio player,
getBinDataAsString(); experiment with both
of these to see which is more efficient (But, be careful using too much Java
string manipulation, as mentioned in chapter 5).
- With Patches, if you need to update the position of a lot of points at once, use
instead of lots of calls to
setPatchPointHeight(). If you use
string manipulation efficiently, you will be able to speed up patch
deformation this way.
This tutorial has covered a lot of ground, and has gone over both general and specific
ways you can write a better Web Driver application. There have been a lot
of warnings about what's expensive in Java and the Web Driver API here; the intention
was not to tell you not to use these features, but to give you an idea of
how to use them more efficiently, so as to write an application that's not too
slow or unstable, but still be able to take advantage of the best features that
Java and the Web Driver have to offer.
©2000 WildTangent Inc. All Rights Reserved.
Website Terms & Privacy Statement