Unity4.3 occlusion culling: basic knowledge

http://blogs.unity3d.com/2013/12/02/occlusion-culling-in-unity-4-3-the-basics/

This blog post was written by Jasin Bushnaief of Umbra software to explain the update of Unity4.3 occlusion culling.

Unity4.3 contains a lot of improvements. One of the new subsystems includes occlusion culling. Not only simplifies the interface, but also overwrites the run itself and adds some new features to the columns.

In the three blog posts in this series, I'll show you how to use Unity4.3 's new occlusion culling system. The first one is the basic method of completing occlusion culling and using the user interface; the second one mainly focuses on the best practice of effective occlusion culling; the third part is about common problems and solutions.

Let's start with the basics. Occlusion culling is the elimination of all objects hidden in other objects. This means not wasting resources on hidden things, making the game run faster and more beautiful. In unity, occlusion culling relies on middleware components: Umbra, developed by Umbra Software. Control Umbra UI in unity, under window---Occlusion culling,bake tab.

How Umbra Works

The occlusion culling process of umbra can be divided into two different stages. In the editor, Umbra handles the game scene and the game runs so that the visible query executes in the player. So first, Umbra needs to take the game scene as input and bake it into a lightweight data structure. In the process of bake, Umbra first sets the scene solution into Voxel, and then the Voxel forms the cell and combines it with the portal. This data, in addition to some other important fragments, is called Unity's occlusion data.

At run time, the Umbra executes the software entry grille into a depth buffer, in contrast to the observable object visibility. In fact, Unity gives Umbra a camera bit and umbra back as a list of visible objects. Visibility queries are usually conservative, meaning they do not return false negatives. On the other hand, some objects are considered visible by umbra, even if they are obviously not in reality.

It is important to note that this system is similar to the previous Unity version, the whole system has been basically rewritten, and many places have become better, both internally and externally.

How to use Umbra
There are several obvious concerns about the best practices for obtaining occlusion culling. Ideally, you want to get minimal conservative results as soon as possible. However, the trade-offs are related. The more you want to be precise, the more you need to produce higher resolution data. Traversing high-resolution data at run time is slow, resulting in slower occlusion culling. This is obviously meaningless if occlusion culling requires more frame time than it takes to save. On the other hand, very fast culling is not helpful unless only a few objects are removed. So this is a trade-off problem.

The Umbra tradeoff is to define a pair of bake parameters. Parameters determine what type of input the bake process should expect, and what data is produced. At run time, using Umbra is simple, and if you have bake the occlusion data and the camera has occlusion culling enabled in inspector, unity will automatically use Umbra.

The smallest hole

The input is controlled by the smallest hole parameters. When three-dimensional pixelated occlusion geometry, the minimum hole mapping is almost directly to voxel size. This means that if the geometry contains the holes, notches, or cracks you expect, it's a good idea to use the smallest holes that are smaller than these. On the other hand, many times, geometry contains many unexpected cracks, which you do not want to see. A reasonable speed-up resolution will fix these. It may use the smallest hole as the "input resolution" for baking.

Note Setting the minimum hole to a small value means that baking is slow and unacceptable, or consumes a lot of editor memory. In some rare cases, it can even fail to bake due to insufficient baking. Using a larger value can be much faster and memory-friendly, and it can cause umbra to spot things like fireplaces or fences. So it's not always good to be bigger. In general, it is advisable to have as large a minimum hole as possible without an invisible error. In fact, we found that 5cm to 50cm worked very well for most games. The default value for unity is 25cm, which is a good starting point.

Minimum occlusion
The minimum hole mainly deals with the type of input geometry, and the minimum occlusion determines what output data is produced. Essentially, you can think of minimal occlusion as the output resolution of your data. The higher the value, the faster the runtime performs occlusion culling, but at the expense of increased conservation (false positives). Smaller values produce more accurate results, but are more CPU-intensive. Obviously high-resolution data will mean larger masking data size.

A smaller value means that a very good feature is captured in the occlusion data. Under Hood, this maps directly to how large a cell umbra is built. Many small cells mean that there are a lot of small entrances between them, naturally, which will cost more to grille a large number of small entrances, and vice versa.

The effect of changing the minimum occlusion can be seen, notice how deep buffering, which is basically what Unbra see, as the smallest occlusion increases the detail gradually loses.

In most games, keeping the minimum occlusion is slightly larger than player, so it's good to be within a few meters. So between 2-6 meters is possible, as long as the game size is not particularly small or very large. The default value for unity is 5.

Back threshold value

Perhaps the most difficult parameter to master is the back threshold, which in most cases does not need to be changed, and some situations may come in handy to help understand how it affects the production of data.

First, note that the parameter exists only for one purpose: the optimization of the occlusion data size. This means there is no problem with the data in the occupation, you just ignore the back threshold. Second, the value is translated as a percentage of the form, so 90 means 90%, and so on.

So what is the value of the back threshold? Imagine a typical scene made up of solid objects, and there may be normal upward terrain grids. Such a scene, where should the camera be? Definitely not under the terrain. You certainly don't want the camera inside the entity object. These void areas are also the back triangles that you tend to look at. So in many cases, making assumptions anywhere in the scene is safe, seeing a lot of back triangles from the camera, is void of one, meaning that the camera in the game never ends up in these positions.

The back threshold helps take advantage of this fact. By defining how many back geometric limits can be seen from any valid camera position, the umbra can strip all locations that exceed this threshold data. This is done in the event of random sampling by shooting light in all cells and then seeing how many of those lines hit the back triangle. If the threshold value is exceeded, the data discards the cell. One thing to note: Only occlusion is helpful for back testing, and occlusion surfaces do not bear any relevance. A value of 100 disables the back test completely.

So, if the back occlusion is set to 70, for example, for Umbra, which means all locations of the scene, more than 70% of the visible occlusion combined without facing the camera, will be obscured by the data stripping, because in reality the camera will never end there. Naturally, you do not need to properly perform occlusion culling from beneath the terrain, for example, the camera will not be there anyway. In some cases, this can produce fairly important data-size storage.

Stripping these locations from occlusion data means that occlusion culling is undefined in these places. Undefined, which means that the result may be correct, incorrect (very random), or return an error. In the wrong case, all objects are simple frustum culling.

In some cases, of course, there are some number of back geometries that happen to be in a valid camera position. Perhaps there is a one-sided grid, which may erroneously be marked as obscured. If it is a large, it may trigger the back test trigger in the vicinity, resulting in a culling error. This is why the default value for the back threshold in unity is 100, which means that the feature is disabled by default.

Arbitrary experimental parameters. Try to reduce the value to 90, such as discarding large amounts of data under the terrain. See if there is a noticeable effect on the size of the occlusion data. If you want, you can even set the value to a smaller one. Remember that this is just your own adventurous attempt. If you start rendering, set the value back to 100 to see if you can fix the problem.

To be Continued ...

In the next blog post, I'll give some best practices and advice on getting the best occlusion culling. Also, visit www.umbrasoftware.com for information about Umbra.

Unity4.3 occlusion culling: basic knowledge