Level of detail - General concepts

Visual level of detail

In the context of any game, and to a large extent any form of 3D rendering, LOD is a series of techniques whose goal is to reduce the geometric complexity of distant 3D objects in order to improve rendering speed.
This usually means reducing the number of vertices in distant meshes/objects, so that less have to be processed by the rendering pipeline, GPU and the like.
Functional rationale: from a user's perspective, there is no point rendering an object, whether part of landscape, a car or a creature, that stands faraway in the virtual world, since they won't be able to discern their finer details anyway; so might as well save on those vertices and triangles which slow down the rendering to no visual benefit.

Icosphere and level of detail

As of the writing of this post, the main geometric primitive the engine makes use of is: the icosphere. This feels obvious when the virtual world is populated with stars, planets and moons. Spheres. Big balls. Heh.

From the Blender manual, an icosphere is defined as follows:

An icosphere is a polyhedral sphere made up of triangles. Icospheres are normally used to achieve a more isotropical layout of vertices than a UV sphere, in other words, they are uniform in every direction.

The most important aspect of an icosphere is subdivision, defined as:

How many recursions are used to define the sphere. At level 1 the icosphere is an icosahedron, a solid with 20 equilateral triangular faces. Each increase in the number of subdivisions splits each triangular face into four triangles.

The following table lists the number of faces that result from a desired subdivision level for an icosphere:

As one can see, the number of faces grows exponentially, and huge gaps exist between steps, resulting in what is actually a certain lack of flexibility when handling level of detail transition. This can sometimes result in visual "jumps" when transiting from one subdivision level (either up or down) to another, resulting in less than optimally smooth transitions.

Ad Lumens makes use of a slightly different type of icosphere: instead of using the usual recursive subdivisions, it uses a direct number, resulting in smaller gaps and smoother transitions between the number of faces at each subdivision level:

One can imagine easily that such a subdivision technique allows for far smoother transitions. Another huge advantage is the ability to increase spherical resolution without hitting uselessly large numbers. For example, if the rendering at 6 thousand faces looks good (subdivision 25, 6,762 faces), why pay the price of having to have 10,242 faces at recursive subdivision 5?

The five images below show what this type of icosphere can do. While the first three are 100% identical to the recursive version, the fourth and fifth images are different:

• the first, second and third images use subdivision 2, 4 and 8 respectively
• the fourth image shows an icosphere whose initial sides have been subdivided 15 times
• and the fifth one 20 times
• 15 and 20 subdivision (or 13, 17 or 113) are, to my knowledge at least, not doable with the recursive subdivision version.

While this is nice, I am still not 100% satisfied with this icosphere version - plainly because it is slow. I think it could do with some optimisations…

Icospheres will be discussed at some point in the future, when we touch on the problem of plate tectonics.

Level of detail applied to procedural data

A bit of context first: Ad Lumens is an authoritative server kind of game experiment. This means the server decides what is seen and how using rules out of reach of "clients", which, apart from UI and command handling, are pretty much just graphical feedback tools/interfaces. Pretty standard stuff.

Two main question then logically emerge:

• how much procedural data does the client see and when?
• how to strike a fine balance between immersion depth and data generation speed?

Level of detail as "quantity of information"

When applied to information, the level of detail concept can be expressed as: "what depth of information does the client have access to?".

It all comes down to efficiency: in a world where hardware resources are limited, there is no need to procedurally generate data which the client is not supposed to see. This perfectly fits the authoritative server model:

1. Only generate what is strictly necessary, without penalising functional requirements: this means that by default, only surface data is to be generated, i.e., as little as possible without degrading user experience or enjoyment.
2. On demand, apply more depth to the generated data: here, "on demand" is associated with a discrete bit of information or a single entity. Since the width/scope of the single entity is usually rather limited, the engine can afford to push and generate very accurate, in-depth data.

Balancing immersion and speed

The two points above illustrate the core conflict between user experience and the CPU/GPU/RAM resources that need expending in order to enable it. This is not a new problem: the more you want to show (either visually or from a data perspective), the more expensive it will all become.

This is the reason why I have kind of split the data LOD into two main families:

• Passive LOD
• Active LOD

Let's do a table to summarise the roles and attributes of each family:

The next post of this series describes how the upcoming 3D navigator makes use of both visual and data LODs, to try and make for an enjoyable user experience :-).