Gamebryo Element Continued

In addition to those features outlined on the previous page, the following are worth considering too:

• It’s possible to share animation data among different characters in the game, and transition/layer the animations in real-time. We wanted to confirm that meant you could reuse animations with models using the same skeleton (which means you could have all human models moving the same way, to save animation time, for example), so check out the interview for that.
• Any particle system from 3ds Max (or Maya) is fully supported, and reacts as in the modeling package; you can emit particles from anywhere on your mesh or inside a volume, and they’ll obey gravity if needed to do so, etc. – we asked the performance characteristics of this in the interview.
• Misc. other effects, including vertex morphing

Besides that, let us not forget the parts of an engine which are dedicated to improving performance in various ways. The most obvious of all are culling mechanisms; if something is invisible, it’s obviously better not to bother even sending it to the GPU; at the same time, you want to keep CPU overhead to a minimum. For this, Gamebryo uses two fairly traditional algorithms: cone frustum culling and portal-based visibility.

The former is used in, well, every single game out there (although some actually try to first cull objects in blocks to reduce CPU overhead, and that’s called hierarchical culling) – basically, the field of view can be abstracted to a cone that has been cut on both sides, and it is fairly easy to cull a bounding volume based on that. Portal culling is a bit more involved; it tends to be a good and cheaper replacement for BSPs indoors, but that goes beyond the scope of this article; it’s extremely easy to find material on the subject though.

Here are a couple of the other fundamental performance points:

• Draw call batching: Direct3D9 (and console APIs to a much lesser extent) is extremely CPU intensive if you don’t take care. Every state (usually material and object) change takes CPU cycles, so you want to “batch” things to make objects similar to each other render after each other, and batch things into fewer calls if possible
• Selective update: We really had no clue what this meant, so we asked obviously. Emergent described it merely as a way to reduce computations on non-moving objects
• Levels of detail (LOD) for all objects, so that distant objects are rendered with less polygons; this forces the artist to create the LODs himself, but that’s a necessity nowadays and the automatic alternatives don’t tend to look that great
• Bone LOD for animated objects. The CPU has a certain amount of overhead for every bone that has to be animated, so bone LOD (which here is combining multiple bones into one) can reduce visual quality but will make sure that’s never a bottleneck with many characters on screen. Some GPUs will be less efficient for animation when many bones are used, too