Efficient code is all well and good, but you'll also want to make sure that your 3d scene is constructed to render as fast as it
can, and be good looking in the process. Some ways that you can ensure this are:
- Manage colorkey and alpha properly
- Be careful with materials and flashy visual effects
- Watch polycount
- Know how to optimize your WTStudio level
- Watch level size
- Draw drops efficiently
- Do some performance testing
Colorkey and Alpha
you need to use texture transparency of any kind, you should use Colorkeying rather than
Alpha mapping if you can
get away with it; Alpha is impressive, but it's also expensive to render. Alpha polygons are added after your scene is rendered, using their
own sorting mechanism that's separate from your scene's Z-buffer. Also note that colorkey values should never be absolute black or white,
due to incompatibilities on some video cards. When using alpha maps or color keys, it's a good idea to
use PNG files and avoid JPGs- JPG files are good for photographs, but they will actually change the color of pixels
during compression, so your colorkey
and alpha values will be thrown off. Also be careful of intersecting objects that use alpha. Alpha
polygons are sorted first by object, and
second by comparison to other polygons in the same object, so having objects intersect can cause alpha polygons to be displayed out
Materials and flashy visual effectsThe more layers
your materials have, the more work your user's video card will have to do to
render your scene. If you need to improve the render times on your scene, consider reducing material complexity. If you need to
use environment mapping on your materials, stick to the Reflection and ReflectionFast UV mappers; the Refraction UV mappers are much slower. Other effects that are costly
from a render standpoint are mirrors and specular highlights.
There aren't any hard and fast guidelines as to what the maximum
polycount for a level should be; there are just too many variables that
affect performance, and polycount is only one of them. For a rough guideline, though,
first determine what the target market is for your application- You should
decide if you want your content to be able to run on lowend machines, or if you
want to take advantage of the capabilities of the latest hardware. For lowend
machines, you should stick to about 5,000 polygons for the vis sections of your
level. For mid-range machines, 10,000 polygons is a good standard.
For high-end machines, you can get away with as many as 50,000, but this means requiring a GeForce or better to run your application. As
mentioned in chapter 4, actors for any sort of interactive content should be
kept to below 1000 polygons.
Optimizing your WTStudio level
The following concerns apply to creating your levels in WTStudio:
The first thing you'll want to do in optimizing your
level is to use vis portals; see the WTStudio documentation on how to use
them. Be sure to add your vis portals as the last step in creating your
BSP geometry so that they get used to the fullest extent.
Another area to optimize is use of lights; if one powerful light would do
the job of several smaller ones, you should go with the one large one. Watch
the radius of the light though- you don't want to just set it to some
arbitrarily high value, since the more objects a light affects, the slower it is- you
should keep the radius only as wide as you need. For actors embedded in WTStudio levels,
you can set the number of lights that affect the actor to zero if you don't care how an actor
is shaded (and then set an ambient light value to get it to show up).
Set light map scale to be as high as you can live with; this controls the resolution of your shadows.
The more detailed the shadows, the more information needs to be stored in the lightmap,
and the longer it takes to download or generate it. Remember that lightmap scale is
per face, not per brush- if you need a crisp shadow for one particular
spot, you can adjust the lightmap scale of that face, and leave the rest of
the lightmap values on the brush low. This is especially important when using dynamic lights- if you have lights that need to move or turn on and off,
adjusting lightmap scale will definitely improve your performance.
When constructing your level, be sure to use cut brushes for hallways rooms- it might be tempting to create a gigantic cut brush, and build your level out of normal brushes, but
this will make your level less efficient.
Instead of using a large open area for your sky, use a skybox instead. This will actually look more realistic, and will be more efficient to render.
To optimize the number of polygons in adjacent brushes, be sure to use Snap To Grid- this will allow the brushes to line up with one another so the in-between polygons can be removed when the level is built.
When adding actors to your level, be sure to check "use collision box", so that when you run collision checks, you won't be testing every polygon of the actor (Unless of course you need to do this, such as
when the actor is very large or is being used for terrain or buildings).
If you need to add a number of similar actors, you can use a single actor file, and adjust the materials, time scale, and scale for them. This way you only need one actor file.
WTStudio level sizeLevel size is also important
for performance- ideally, your level should be at most 2000 units across.
This is important for two reasons; first, the accuracy of Z sorting breaks
down beyond this point. You can adjust the Z sorting properties of your
level by adjusting the camera's front clipping plane; the default is 1 unit, but
it can be set to 5 or 10 units to increase Z sorting accuracy. The other
reason for keeping level sizes down is collision detection; collision tolerances
are set to 0.1 units, so if your level is especially large, collision detection
will become very inefficient.
To make your drops more efficient, try to avoid overdraw as much as possible- If you have several drops that take up the whole
screen, and are using colorkeys to cut out areas to make the other sections and the 3d scene visible, trim the drops
down to smaller sizes, and only draw the areas that you need- you can use
setPosition() on a smaller drop
to position it where you want it.
You may be wondering how much efficiency is enough when designing your application. The best way to determine
if your application will run well is to run it yourself and check its performance. In building a test machine, figure that the typical user
has (at the time of this writing) a 450 MHz processor, 64 MB of RAM, and an 8 MB video card. You can design your content for
a faster machine, or a more robust video card, but you should specify this in the system requirements for your application, and
remember that the faster a machine you require, the smaller your target audience will be. When testing performance, here are some
things to watch:
- Render and event times: This should be the best indicator of the efficiency of your scene. You can view these times in
the Debug window of the web driver; the Render time is the amount of time that each render takes, and the Event time is the
amount of time that it takes to run all of your code between renders. A good target figure for these times is 25 ms for the
render time, and 10 ms for the event time.
- Object count: This is also viewable in the debug window. If your object count is steadily rising, you are probably
creating objects without destroying them; watch for this in your code.
- Download speed: Difficult as it is to imagine, many
people are still using an analog connection to the Internet. Test your game on
an analog modem connection to see what it's like for these people; if you are
getting bored waiting for the game to load, turn back to Chapter 4 to look
into ways you can optimize your download times.
In the final chapter, we'll look at specific areas of the Web Driver API.
©2000 WildTangent Inc. All Rights Reserved.
Website Terms & Privacy Statement