3D Media Portability and Optimization For WorldForge Games
A White Paper by
Derek Gladding & Jason Oppel
Feb 2003

Introduction
Most of today’s commercial 3D game efforts only develop for a very narrow segment of hardware that the gaming population currently owns. This excludes many people from playing games that they might otherwise enjoy. The purpose of this white paper is propose a means by which a wide range of hardware can be supported by a 3D client while minimizing the amount of work to create the media required to accommodate widely differing CPU/GPU capabilities.

Goals
Players should be able to easily fine tune the amount of visual detail they experience in WorldForge games. This will allow each player to tune the game’s visual experience to a more simple or complex environment depending on the computer’s capabilities that the gamer is playing on. These settings should be easy for users to adjust via simple implements such as sliders or knobs. As our technology improves we should be able to offer a tuning process that is far superior to any commercial gaming efforts.

Artists shouldn’t be required to build multiple versions of the same models/textures from scratch to support the wide range of hardware we want our 3d games to run on. In fact the burden on our artists should be kept to the barest minimum, as artists are usually hard to find in Free Software projects.

Supported Hardware Platforms
Below is a proposed list of various levels of support, their hardware specifications, texture/poly budgets and the accompanying frame rates. You’ll also find how we arrived at these figures and where bottlenecks and trouble spots are likely to occur for each spec.

Minimum Spec - This combination of hardware is the absolute minimum that we require to even play a WorldForge game in a 3D client. At this level of support your game play experience probably won't be pretty but it will work minimally. You should expect very low frame rates while displaying very high poly scenes (12 fps or perhaps even lower depending on the scene) from time to time. Artists may choose to provide media targeted toward for this spec although they are not required to do so. It is assumed that client and API coders will use clever means to shoehorn "Recommended Spec" media into this machine (albeit in a less attractive manner than in the Recommended Spec machine). Client coders can use techniques such as poly reduction algorithms and shrinking textures to manageable sizes (or omitting them completely). Below you’ll find an example of a Minimum Spec machine.

Minimum Hardware Configuration
GPU: G200 - Voodoo2 generation 8MB PCI
CPU: P2 w/64MB RAM
Screen Resolution: 640x480x16bpp (single texturing)
Target Frame Rate: 30fps
Poly Budget (in triangles) = 3,000tri/frame
Scene Poly Budget: 6,000 triangles/frame (assuming 30fps)
Character Poly Budget: 200-300
Texture Budget: 9MBs (although only 6MBs allowed in any one scene)

Recommended Spec - Using this hardware you should get consistently playable frame rates and a fair amount of eye candy. This is the configuration we expect most of our gamers will have (at least). Artists would create media specifically for this range of machine and above. Below you’ll find an example of a Recommended Spec machine.

Recommended Hardware Configuration
GPU: Geforce 1-2 DDR/SDR - Radeon 7500 32MB cards 1-4xAGP
CPU: P3 or better 1GHz w/128MB RAM
Screen Resolution: 1024x768x32bpp (dual texturing)
Target Frame Rate: 60fps
Scene Poly Budget: 30,000 triangles/frame (assuming 60fps)
Character Poly Budget: 1,000 (give or take a few)
Texture Budget: 80MBs (all of this can be displayed in one scene)

Extreme Spec - This is all the latest and greatest hardware (and even includes hardware which has yet to be released). High frame rates and maximum eye candy which should be on par with (and hopefully better than) today’s commercial games are to be found at this level of support. Below you’ll find an example of an Extreme Spec machine. Please note that these numbers not only include data for today’s top of the line hardware but also hardware that will be released within the next year or two.

Extreme Hardware Configuration
GPU: Geforce 3 - Geforce NV30 / ATI R30 4xAGP (or better) 64MB+
CPU: P4 1.8GHz+ (or better) 256MB RAM (or higher)
Screen Resolution: 1280x1024x32bpp (quad texturing)~
Frame Rate: 100fps (or better)
Scene Poly Budget: 150,0000 triangles/frame (assuming 100fps)
Character Poly Budget: 1,500-10,000(!)
Texture Budget: 100MBs+

Texture Memory Management
The varying age of GPUs that we wish to support presents us broad range in capabilities that need to be taken into account. GPU memory is precious and swapping textures on PCs from system RAM to GPU RAM is constrained by the computer’s bus (AGP/PCI). This makes frequently swapping out textures on the GPU costly and impractical. Texture caching mechanisms is one way that a 3D client can minimize it’s texture swapping. OpenGL also provides some relatively straightforward solutions to our GPU memory management problems which we will detail a bit later. These solutions sacrifice visual richness for improved frame rates on older machines by scaling down or completely eliminating textures in some cases. The problem of texture memory usage can be tuned by adjusting the MIP level bias so that the user can very specifically choose their compromise between performance and texture quality. When adjusting MIP level bias provides poor results one can always adjust the MIP level itself to a more suitable level. This means that WorldForge artists should always work in the largest (square) size image available to them as results can always be scaled down to the required size. Textures that are 1024x1024 (or even larger) should be suitable sizes to work with. Versions of textures which are considered “Game Ready” should likely be somewhere between 12x12 - 512x512 although 1024x1024 textures are certainly possible and desirable on today’s hardware.

In order to save texture memory the time-honored tradition of UV mapping skins on to meshes should be used in order to map several textures within one image on a mesh, which naturally go together (like all the textures for a human male mesh for example). Players will naturally want their characters and items, which they possess to have a unique appearance. To facilitate a customizable appearance we should provide a number of small “decal textures” which will be overlaid on base texture sets. This will serve to differentiate player’s appearances for those whose GPUs have sufficient memory capacity. Some examples of these decals would be different selections for eyes, noses, mouths, family crests or insignias/symbols.

Polygon Count Management
The range of hardware that we aim to support has vastly differing abilities to process and push polygons. Poly counts could be tuned in the following manner. All models will have at least two meshes of the same object. These two meshes will be tuned to the Recommended and Extreme Specs respectively. The artist may optionally provide a third very low poly mesh tuned for the Min spec gamer (although only Recommended and Extreme meshes are required). For very common characters (like humanoids) the media team may provide generic, very low poly models (50-200 polys) but this again is not guaranteed. Although only two meshes are required (w/a third optional mesh) artists should keep an eye towards the future whenever designing their models. Texture artists and modelers should and make it easy to increase poly counts and texture sizes whenever new hardware is able to support it. The reason behind having multiple meshes for an object is that when the client needs to perform polygon reduction on the mesh (a.k.a. mesh decimation) to obtain better frames/sec. the client will be able to tessellate between the two meshes and lose far less of the artist's original intent for the mesh's geometry. If there is no min spec model available, then the software will interpolate as best as it is able, but we don't guarantee good results for this case. This will allow players to tune the level of geometric complexity of in game meshes to their specific computer’s abilities.

Conclusion
The above strategies and budgets should serve WorldForge well as an initial guide post for further 3D media development. Also this document will hopefully serve as a metric for 3D client developers from which to judge the relative performance of their 3D clients on known pieces of hardware. Doubtlessly client developers will invent new and innovative methods for increasing the flexibility and level of optimization in their 3D clients. Whenever practical these new techniques should be added to this document. It is our hope that this document will encourage the development and collaboration of all parties needed to display compelling 3D content for the broadest range of gamers/hardware possible.