3D Asset Size and Impact on Scene

How to Sustain a Good Performance

When you load a slide which is composed of different types of assets, each asset has an effect on the performance since their individual polygons (meshes) need to be rendered onto each frame. If you have large system and GPU memories, you might be able to load many large assets, but eventually you could experience reduced performance as you add more assets. You might want to manage your assets properly in a slide to prevent performance degradation. But, you can reduce individual meshes by grouping objects that share the same geometry and materials in the modeling software.

Optimization

In general, how much you should optimize assets depends entirely on the scope of your project and the capabilities of the system you will be running it on. The key to making impressive real-time graphics is learning the limitations of your system and being able to work economically within them. Distributing these limitations across your scene is referred to as budgeting.

Polygon Budget

In real-time 3D applications, most of the graphics on screen are defined by a series of triangles connected together to form solid-looking objects. Modern video games are modeled so efficiently that they can display entire cities complete with vehicles and characters without the user ever seeing more than 2 million triangles on screen at any given time. The ideal scene should follow most of the same conventions.

• If a triangle doesn’t contribute to the silhouette of an object, you usually don’t need it – the extra detail should be created through texture instead. To avoid over detailing models, pick a set distance such as 2 or 4 meters as a reference, then only model details that will be noticeable from that far away.
• Get rid of internal and hidden geometry whenever possible. Any geometry that is never seen by the user still has to be processed, even if it’s behind another object. These objects should be removed. The extra detail should instead be used on things the user can see.
• Use transparent textures for plants and chain link fences. In some cases, millions of triangles are used for a small number of plants that contribute very little to the overall scene. Rather than getting rid of the plants altogether, remake them using transparent polygons that use transparency to show clusters of leafs. Ideally, study the way plant props are handled in modern video games.
• Within the area accessible to the user, geometric detail should be distributed fairly evenly. This is a bit more complex than the way textures are distributed since some surfaces need more triangles to describe the surface than others.
• Most geometric detail should be focused around the area that the user can get close to. Background areas that never get any closer than 50 meters do not need nearly as much geometric detail as props in the active area.

Texture Budget

Keeping your texture budget under control is fairly simple. Check how much memory is on your graphics card, and aim for under 75% of that. When textures are loaded onto your graphics card, they are stored in an uncompressed state. Therefore, even though you have a 2048x2048 pixel image that is only a few hundred kilobytes as a jpeg, on the graphics card it will be 12MB. If you exceed that budget, you will start having drops in frame rate as your card attempts to load and unload textures. You have three main options: Use fewer textures, use lower resolution textures, or use DXT Compression.

As a general rule, don’t worry too much about close up detail. At any given time, 95% of your scene will be at a distance. Therefore, first focus on making the scene look good as a whole, and only then add close-up detail where it’s absolutely necessary. In most cases, if a texture looks sharp from 4 meters away it has enough detail. Though this varies depending on the current field of view, this works out to be somewhere between 256 and 512 pixels stretched across every meter.

• It is easy to calculate the uncompressed file size of an image. Most textures will be 8 bits per pixel. Multiply the width in pixels by the height. Since 8 bits is 1 byte, this gives you the number of bytes for the image. Divide that number by 1024 for the number of kilobytes, and again for the number of megabytes. E.g., An uncompressed 2048x2048 image is 12MB.
• Another simple way to find the uncompressed file size is to open Photoshop, create a new image, type in the pixel size, then look at the value under “Image Size”.
• Some special cases may require higher bit-depth images. To calculate the size of a 16 bits per pixel image, multiply the number of pixels by 2 bytes. For 32 bits per pixel, multiply by 4 bytes (32 bits/pixel).
• The amount of texture detail in a scene is often described in terms of pixels per inch or pixels per centimeter. When pixels are used in a texture, they are called texels and the amount of texels per cm is referred to as the texel density. For the main area of your scene, a good density to aim for is about 2.56 pixels per cm. This means that a tiling map that is 1 meter x 1 meter wide should have a resolution of 256 x 256 pixels.
• Not all parts of the scene need the same amount of close-up detail. A building that is never seen closer than 100 meters away can get away with having a much lower texel density than a prop that the user can walk right up to.
• It’s common practice to attempt to keep your texel density consistent across all objects in the section of your environment that the user can get close to. Changes in density calls attention to differences in texture sharpness, which can be jarring for the user, affecting immersion.

Performance indicator

On the toolbar of presentation designer, there is a performance indicator which explains whether the current slide can be run without any performance issue or not in an HMD setup. That is, depending on its color, we show different tooltips to provide users with quick guidelines.

IndicatorWarningsGreenThis slide will perform well in most HMDs.YellowIf you add more assets to this slide, you may experience reduced performance in an HMD setup.RedIt’s unlikely this slide will run well in an HMD. You should reduce the number of visible components.