Realtime Modeling

(or the art of building stuff that look good and don't kill FPS)

Realtime vs. Pre-rendered

A common confusion encountered by persons not into game design is toward the differences between pre-rendered 3D and realtime 3D.

What realtime 3D is for: games, live applications, realtime simulations
What pre-rendered 3D is for: movies, animations, illustrations

Definitions

frame: one single image composing an animation that will be played on the screen
rendering: the processing needed by the computer to create a frame
fps (frames per second): how many frames can be rendered in a single second

Pre-rendered 3D Facts

- It can take several minutes to hours to render a single frame (most movies run at 25 frames per second).
- The rendering time depend of the quality of the picture wanted
- The available rendering time depend of the rendering machine power and the amount of machines dedicated to it. (The term "render farm" is used to designate a group of computers used to render 3D frames.)
- machines from a render farm are dedicated to the sole task of rendering frames.

Realtime 3D Facts

- The rendering time cannot exceed a fraction of a second.
- The available rendering time is limited as we need to render at least 25 frames per second to give an illusion of movement
- The machine used to render is usually not of a professional level and usually a single computer.
- The machine is usually NOT dedicated to the image rendering as several other processes are running in the background (sound, AI, networking, physics).

Optimizing work for Second Life

Now that this is known, what is wanted, basically, is to get as much detail as possible while keeping the framerate higher than 25 FPS (the minimal framerate to keep a smooth feeling of movement).

In game design, the key of success is to take as many shortcuts and tricks as possible to speed up the rendering process. Commercial games like Doom 3 use BSP culling, normal mapping, and zoning, that are good tricks to determinate what can and cannot be seen and add a lot of details on low polygon objects.

Most of these tricks cannot be used in Second Life; due to it's ever changing nature, a list can't be prebuilt of what can be seen and what cannot from every point in the grid|world. So the only way to improve the global experience is to learn how to build the smart way.

LOD: level of detail

Some shapes that have curves usually use what is called a LOD (level of detail) that allows making an object less detailed as the camera is far from it and more detailed as the camera approaches. As an example of LOD, the SL cylinder looks more round when close and seems to look more like a 5-sided prism when seen from a distance. This allow to spare some triangles from far objects. Second Life's LOD, according to my observations, scales objects from 5 to 24 subdivisions, so a cylinder seen from very close will have 24 sides and seen from a great distance will have 5 sides.

Polygons & Primitives

The common measurement in object complexity in Second Life is the primitive count (not polygons). However, it is very inaccurate as each primitive does not weigh equally on the rendering engine.

Each primitive, avatar, tree, and terrain is composed of triangles for the 3D engine behind Second Life. Every shape is constructed using triangles of various size that are fitted like pieces of puzzle. As stated, each primitive does not "cost" the same number of triangles. Thus, some primitives will dramatically increase the number of triangles to render while some will cost almost nothing.

Here is a rough classification of the different prims sorted from low triangle (tri) count to high triangle count:
(Note: the values do not take in account the twist/cut/hollow operations as they make things worse.)

updated the 28 of july 2006

Prim Type	Far LOD	Close LOD	-180 +180 Twist
prism	8 tri	8 tri
cube	12 tri	108 tri	1350 tri
cone	15 tri	168 tri
cylinder	20 tri	192 tri
ring	30 tri	144 tri
half sphere	22 tri	600 tri
tube	60 tri	144 tri
sphere	25 tri	576 tri
torus	50 tri	1152 tri

To compare:
-SL's average torus-based hair: ~48000 tri (one attachment)
-Alyx (detailed main character) from Half-Life 2: ~15000tri (complete character)
-Combine soldier from Half-Life 2: ~9000tri (complete character)

As is understandable, a good builder in SL, on top of trying to use as less shapes as possible, will prefer the use of pyramid prisms and cubes compared to toruses and tubes, and a judicious choice of textures to bring some details (nuts, bolts, cables) without using primitives.

a usefull trick is that if a cube is tapered of at least .01 it snap back to its lowest lod (12 triangles) thus will cost 9 time less triangles than untapered

When a primitive is twisted, some of its sides will start subdividing to compensate the rotation. For example, a cube, twisted by:
- 0-29 degrees: length sliced in 2
- 30-44 degrees: length sliced in 3
- 45-58 degrees: length sliced in 4
- 59-72 degrees: length sliced in 5

Textures & Memory

Another problem is related to textures and graphic cards. When a computer is rendering a frame, it will delay a lot of the work to the graphics card, like putting textures on triangles. This mean the textures must be loaded into the graphics card memory.

An average graphic card is shipped with 128MB to 512MB of memory onboard. Most picture formats are compressed to save disk space. However, in the graphics card memory, the textures MUST be uncompressed which means that what will determine the size a texture's use in graphics card memory is not dependent on file size but on picture resolution. Second Life (and games) work with textures sized as multiples of 2 (like 256x256 or 512x512--but they don't need to be of a square size).

Here is "roughly" the amount of memory a texture uses in graphics card memory based on it's resolution. The memory-use formula for textures is: width*height*4 bytes. If there is alpha|transparency in the texture, the memory used is doubled and add 50% for mipmapping. This means:

256x256 texture = 0.39MB (656 in a 256MB card)
512x512 texture = 1.56MB (164 in a 256MB card)
1024x1024 texture = 6.3MB (40 in a 256MB card)

256x256 texture+alpha = 0,78MB (328 in a 256MB card)
512x512 texture+alpha = 3.13MB (81 in a 256MB card)
1024x1024 texture+alpha = 12.6MB (20 in a 256MB card)

As shown, it seems there isn't a LOT of room to store all textures, so once memory is used up in a graphics card, what happens? Well, the used up textures are unloaded from graphics card memory back to system memory and the textures still needed to process are loaded into graphics memory--it's called "swapping", and even if it's fast it still adds more and more to the time needed to render a single frame (don't forget, 25 frames per seconds is needed!)

So, on top of keeping the triangle count low, using large and detailed textures is not a compensation or the cure will be worse than the disease.

Alpha & Rendering

Every now and then the terrible alpha flickering/sorting bug comes up. This happens usually when two transparent textures are too close or seen from a weird angle.

The heart of the problem is that the alpha textures are rendered separately. Usually the engine starts to draw the closest triangles and proceeds slowly to the furthest one, but since the transparent textures are, well, transparent, the 3D engine renders them AFTER the others and in reverse order. Sometimes the ordering isn't right and one texture appears on top of the other when it shouldn't. There are methods to prevent this problem but they usually slow down the rendering and do not correct the next problem.

The fact the alpha textures need a separate "pass", and has to make pixel value additions to simulate the transparency, considerably slow down the rendering when there are a lot of passes. So, two reasons to limit the number of transparent textures are to:
-prevent the alpha flickering/sorting bug
-lighten the load on the 3D engine

A common rule of game designers when creating game levels is to avoid (as often as possible) that the player sees at the same moment more than two alpha textures overlapping (like seeing through no more than two lenses at a time).

---

Polygon | Camera