Best Practices Tutorial

chapter 1 | chapter 2 | chapter 3
chapter 4 | chapter 5
chapter 6 | chapter 7

home | developer central

Chapter 6 - Building your 3d Environment

previous chapter | next chapter

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:

Colorkey and Alpha

If 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 of order.

Materials and flashy visual effects

The 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 size

    Level 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.

    Performance testing

    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:

    In the final chapter, we'll look at specific areas of the Web Driver API.

    previous chapter | next chapter

    �2000 WildTangent Inc. All Rights Reserved. Website Terms & Privacy Statement