Polyplanes and rendering performance

Polyplanes allow us to have an absolute control over final number of triangles of generated model. In other words, we can choose arbitrary number and create model with number of triangles that doesn't cross that number, thanks to polyplanes. But performance of real-time application is determined also by other factors than number of triangles, like the number of drawn pixels.
Number of drawn pixels of model depends on many parameters irrelevant to the actual model, like its orientation on screen, distance from camera if perspective is used or screen resolution. For simplification, instead of number of drawn pixels let's start talking about surface area of model from now on. It can be proven that in case of a mesh soup they are linearly dependent.

Problem

One might think that if we reduce the number of final triangles to half, we also reduce its surface area to half, right? Well, not exactly. Look at the following table that shows on particular example of Quercus tree dependency of surface area on number of triangles.

This table brings rather bad news. We decrease the number of triangles from 10k to 5k, but we still draw 85% of original pixels instead of expected 50%. To draw 50% of original pixels, we'd need to decrease number of triangles from 10k to 1k. Reason for that is, that while number of polyplanes is decreasing with number of triangles roughly linearly, their size is increasing, keeping the total surface area still high.
But problem is not only with the ratio the surface area is decreasing, but with the total surface area in finer and medium LODs. It was tested that even on not too old GPU like GeForce GTX 560 the performance of tree models with more than 20000m² is questionable.
The surface area heavily depends on tree shape and we don't have to solve this issue for every tree model. The following images illustrate two very different kinds of tree. Note that while the first fine model has 10 times more triangles than the second coarse one, its surface area is about 5 times smaller. And indeed, the rendering performance of the first one is significantly better on modern HW than the second one.

We basically need a mechanism that allows us to decrease the surface area. Most of the pixels on tree go to polyplanes, let's focus on those.
Small intermezzo: surface area is not the only problem of polyplanes. As we try to reduce number of unique polyplanes (it was described in previous blog post), it often happens, that we see polyplanes of the same shape very close to each other. It looks like this:

This is because they start shortly after branching, and as they have similar properties, the polyplane manager decides to give them the same texture. Obviously this doesn't bring any good for the final result and it would be better if this duplication is not there.

Solution

In version 1.49 of Silvador there comes tool, that can help with both problems described above at once. We can limit the total number of polyplanes. It is being controlled by new attribute VisualizerLOD2.polyplaneReductionTotalWantedCount. We obviously need to use this mechanism carefully, the polyplane reduction makes the crown thinner. Either we can accept it, or we need to compensate it f.i. by making tips of branches denser when describing given LOD, see Branch3.branchDensity and VisualizerLOD2.modify.
The following sequence shows result of polyplane reduction and in the end compensation for thinner crown. Bottom images show corresponding heat-map visualizing overdraw. First image shows original model. You can see it has surface of more than 28000m² and 571 polyplanes. You can also see visual artefact described earlier at its botom branches. Second and third image show polyplane reduction to 400 and 200 with surface area reduction to 20000m² and 10000m². You can observe the crown of the third image is already visibly thinner comparing to first image. On fourth image we compensate the thinner crown by increasing density in branch tips - through controller Branch3.branchDensity. Note the surface area of model increased to 17000m², because the density increase described in previous step leads to increasing size of polyplanes. However, in total we decreased the surface area from 28000m² to 17000m² while keeping the same tree density and as a bonus we removed the visual artefact.

When configuring exporter, it is definitely worth watching surface area of model to be generated. If there is higher number like 15000, 20000 or more, consider taking steps that can reduce the total surface area. (the numbers need to be biased with the engine the trees are used in - some engines can have more, others less complex pixel shaders. Provided numbers are relevant to VBS3.)

Polyplanes and visual quality

Geometry of tree model prepared for real-time rendering is split between original geometry (usually trunk area) and polyplanes (usually leaf area). Polyplane is a simple geometry approximation of original tree structure with help of texture where is projected original tree structure. Polyplanes are one of the most important ways how to simplify geometry between individual levels of detail in Silvador - the rougher the LOD, the closer to root its polyplanes start.

While polyplanes are a powerful tool for geometry simplification, there are few aspect we need to be aware of, for getting the best possible result. In this blog post let's focus on visual quality of polyplanes.

Model statistics

But first let's look at meaning of tree model statistics. Statistics is positioned in bottom right corner of the preview window and looks like this:

This is what individual entries tell us about plant model:

• heig - Height of the geometry of the tree model in meters. Note that it is really the geometry what is measured, not what is in the textures. This means that f.i. the tree model on the image above reports higher number than what is actually visible - it reports corner of the polyplane geometry, not area where alpha of polyplane texture is non-zero.
• surf - Surface area of geometry, in square meters.
• tris - Number of triangles the model consists of.
• poly - Number of unique polyplanes. / Total number of polyplanes.

Texture quality vs Crown shape fidelity

Very important counter for the final model visual quality is the number of unique polyplanes. It can be well controlled through VisualizerLOD.polyplaneReductionWantedCount controller. In usual cases it corresponds to minimum value between polyplaneReductionWantedCount and total number of polyplanes. In special cases where polyplanes are generated from components of different kind, the final number of unique polyplanes can be higher than polyplaneReductionWantedCount. For the best quality of the final model it is important to find the balance between final texture resolution and geometry fidelity. Consider the following sequence of images demonstrating various setting of polyplaneReductionWantedCount for the same model:

On the first image we chosen to have only 2 unique polyplanes. Note the geometry is degraded a lot from the desired result (bottom image). On the other hand the generated texture (on the right side) is very detailed. On the last image we have the opposite, the best possible polyplanes - each one is unique. On the other hand each one occupies space in the final UV atlas texture. Therefore we now have a worse quality of textures as more textures need to fit in. On the middle image we chosen something in between - 3 target unique polyplanes. Its clearly the winner in this particular case - the shape of tree is very close to the last image while detail of texture is very close to the first image.

When configuring exporter, it is definitely worth spending few moments with polyplaneReductionWantedCount controller and find smallest possible number when you are still happy with the tree shape.