Introduction to LOD

TrainzDev

New member
What is LOD?

LOD seems to be a confusing topic for a lot of content creators. We often see mistakes being made in LOD configuration which suggest that the author does not really understand what LOD is meant to achieve, and is attempting to apply poorly-understood "rules" instead of making informed decisions specific to their asset. This is the first in a series of blog posts which aims to improve the understanding of this subject.

LOD stands for "Level of Detail" and it usually refers to a technique where instead of creating a single mesh and calling it a day, the creator goes on to make a series of less detailed variants which can be used in place of the original in cases where performance is considered more important than visual quality. Each mesh variant, or "level of detail", provides a mesh that looks as close to the original as possible, but varies in polygon detail.

This approach is very useful in finding a suitable quality-vs-performance tradeoff, for a very simple reason: in any given scene, the majority of objects are far away from the "camera". You have a very small number of objects within 10m (about 50m^2 worth of space), a few more within 100m (~5,000m^2), a lot within 1km (~500,000m^2), and a vast number within 5km (~13,000,000m^2). Based on those numbers, we can say that 96% of the objects in a 5km scene are more than 1km away from the camera. (99.95% are more than 100m away.) Pretending for a moment that all of the performance cost in the game comes from the polygon count then if we start at a 20fps scene and halve the polygon budget of every item that is further away than 1km, we will end up with a 38fps scene. That's a massive improvement.

But what about the visuals? Surely if we halve the number of polygons in a model, it's going to look a lot worse? Not really, because of how your eyes work. If an object is twice the distance away, it's half the size in our vision- or on the screen, for that matter. This means it occupies one quarter as many pixels (half the width, half the height.) With less pixels available to resolve the object (or cones and rods, if you want to talk about the eye's biology) we are able to perceive less of the object's detail. To see this in action- try reading an open book from across the room. It's clear that when an object is further away, the object could be less detailed and we would be none the wiser.

When we're creating a new model, we have an optimum viewing distance in mind. If you're creating a small rock, the chances are that you're thinking about viewing it from the 1-50m range, and you'd like it to look best at around 10m. If you're creating a skyscraper, you might be thinking of 50-5000m and you'll be happy for it to look best at 100m. Whether you are actively conscious of this or not, you already use this thought process when deciding how much detail to put into your models. You typically "stand" at the optimum distance when testing your model in-game. It's obvious that if you get within 1m of the skyscraper, or 10cm of the rock, you're going to see some very blurry textures. But you probably don't care, because you've already defined those ranges as being inappropriate viewing distances for your model.

Let's take the skyscraper example. You're modelling for an optimum distance of 100m, and let's say that when you've got all the desired detail in place, it weighs in at 1000 polygons. (Important side note here: when we say "polygons" when talking about Trainz, we are actually referring to front-facing triangles. If your graphics tool is configured to use higher-order polygons such as quads, you should double the figure because the model will be broken into triangles when you export it. If your materials are set as double-sided, you should double the figure again because that will effectively creating one forward-facing and one backward-facing triangle when rendering.)

Given what we've learned above, we can estimate that a 75% detail drop is visually undetectable at 200m, and a total of 96% detail drop is visually undetectable at 500m. At first glance, that sounds like we should be able to use a 250-polygon mesh at 200m and a 40-polygon mesh at 500m. This is the right idea, but it's not quite correct in practice. Because the polygons are represented in 3D and not evenly distributed throughout the object, it's not possible to hit the theoretical numbers. How close we can get depends on how detailed the model was in the first place, the way the object is formed and how good you are at modelling, but it is fair to say that we can use these numbers as a rough guide. If we stick to the theoretical numbers exactly, some visual quality will be lost as the object falls into the distance, but in many cases this is quite acceptable. How much detail loss is acceptable is something you need to decide on a case-by-case basis, but it's possible to give some recommendations based on the theoretical numbers and certain practical techniques.

There are two important aspects to preserving visual quality when implementing LOD. These are based around how our eyes work and how light works. The first aspect is that you should make an effort to preserve your object's silhouette. We recognise objects by their lines, and the most distinct lines in any object are typically the edges. If the edge shape changes dramatically, our eye will see the change as motion and the effect will "draw our eye" - this is the last thing we want to happen when a LOD change occurs.

The second aspect is that you should preserve the lighting of the object. When a LOD change takes two near-coplanar polygons and collapses them into a single polygon, the resultant change to the geometry may be extremely minimal. Unfortunately, since the plane's angle affects how the surface responds to light, a small angle change can cause the surface to become brighter or darker. When the two polygons are collapsed, they potentially go from having different lighting conditions (and thus being different perceived colors) to having identical lighting conditions. This color change can be very noticeable in some cases. Thankfully, it's easily fixed by using a normal map generated from the high-detail LOD. The in-game lighting system uses the normal map to determine lighting conditions rather than using the (reduced-detail) geometry, and thus this problem does not occur at all. Long story short: if you implement LOD and are not using a normal map, you are likely doing yourself a great disservice.

Further information is available on TrainzDev Wiki pages: Level of Detail, LOD Example and Modelling Guidelines.
 
Back
Top