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.)