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.

Change in philosophy of templates

The learning curve of Silvador is not very steep. I would visualize it like this:

It goes usually quickly at the beginning where with small effort it is possible to create some random tree that can be generated as a final model. But when one is challenged to create a particular plant with desired parameters, it takes some effort to reach level of experience that allows achieving that.
It is a frequent case among existing procedural generators that it is not that easy to master the procedural part by end users. There are various approaches how individual creators of such software deal with the problem:

• some software focuses on manual modifications and keeps the procedures to take care of less important (but dense) detail. It let's a user to draw the main branches by hand and generates smaller branches consequently upon it. It is definitely an approach that works and it provides user big level of control above the final model. It is a double-edged sword though. There is a layer in the tree topology, where human stops drawing branches and starts to rely on those that are procedurally generated. The problem is that this transition from human-drawn branches to procedurally-generated branches is usually very visible. There is nothing like this in nature where all branches big and small are created through the same algorithm. Human eye can usually quickly say there is something fishy with the tree model, artists refer to it as that they "look cartoonish". Another disadvantage is, that it is not easy to create variants from tree defined this way, to big extent it means doing it again
• another software handles it the way that it has an expert mode and a user mode. The expert mode is where most of the magic is done and this mode is sometimes even not available to end users due to its complexity. Plant models are created by experts and sold separately to end users who can then control set of basic parameters like seed or age to produce final models. Problem of this approach is obvious - end user has a limited control over the final plant model and needs to rely on a predefined library.

Silvador offers manual modifications, but in general its not based on it - it stays a bit closer to the second approach. The difference is, that it offers all the controls to end user. Even though effort was put into clarity and organization of the interface, mastering it takes some time. To help with that, Silvador comes with a gallery of complete plant models as well as set of templates.
Current templates aim at making the learning curve steeper. They are examples of how to achieve typical tree topology with as few steps as possible. This is how they look like:

Apart of simplicity their common feature is that they are quite far from a usable plant model.
There are users who can't afford to invest energy into learning the whole process, yet need to create believable plant models and they can't find exactly what they need in gallery. To address this, Silvador is now being updated with templates of a different kind - still as simple as possible, yet very close to finalized model, with typical crown shapes and branch structures. First such set comes with Silvador of version 1.49:

Ambition of these templates is less about making the learning curve steeper (yet they can still serve well for learning purposes) and more about decreasing the level of experience needed to create a usable tree. I would visualize it like this:

A side note: almost all the trees on images above were created with help of light searching described in previous post.

Light searching

Up to now, position and orientation of every branch was determined by its initial parameters like parent origin and seed, without any consideration of neighbor branches. In real world proximity of neighbor branches matters a lot and it is one of the main driving factors forming a tree crown. In version 1.49 there is introduced a basic light searching model. It considers 3 factors:

• proximity of closest neighbor (heading away from it)
• position of crown center (heading away from it)
• ground layer (heading away from it when close to it)

These factors are controlled through 3 new tropisms introduced to Branch3 component: "crownAwayFromNeighbourTropAngle", "crownAwayFromCenterTropAngle" and "crownAwayFromGroundTropAngle" respectively. Surprisingly even light searching model as simple as this has a significant influence on forming a crown. Consider example on the following 2 images. In both cases we see identical plant topology made of 2 components - a stem with bigger number of side branches spawned under the same angle. Even as simple tree structure as this, that looks extremely artificial like on the left image, can after applying just these 3 tropisms change to believable tree crown shape like on the right image.

The direct benefit is that we are now able to create more natural looking regular tree crowns with less effort.

But there is also indirect benefit: Because branches are now distributed more evenly over the plant volume, we need less amount of branches to represent a compact crown - we save polygons in the final model.

Manual modifications

It is a common pain (or advantage from other point of view) of procedurally generated content that you can't (or don't have to) control exact properties of every created individual. Sometimes it can be useful, though, to have ability to control individual branches of given plant:

• to introduce modifications that are not result of natural plant growth (manual cut or a result of damage)
• to allow creation of custom shapes (f.i. branches forming a letter)
• to give user ability to reach desired plant shape manually, if he struggles to reach it procedurally

Version 1.47 of Silvador comes with a new feature - ability to modify plant by hand. It is realized through list of exceptions that are incorporated during generation. Important aspect is, what is used to reference individual branch we want to alter. After various less or more crazy considerations the system was set to use branch position in 3D space as a reference. Consequence of this approach is, that if the plant is modified, usually no branch ends at captured position anymore and typically all modifications are no longer visible. Therefore it is needed to do the modifications at the very end of plant design.
Now how to control modifications in Silvador. First it is needed to select a branch we want to modify. It can be done by pointing at it with mouse cursor and double-click while holding Ctrl button. The selected branch will be highlighted with yellow color like on this image:

At this moment there is in the clipboard in text form identification of the location with syntax of simplest modification - cut. It is possible to past it into textfield of new attribute common to all visualizers and exporters - "Modifications". Like this:

The letter C at the end identifies the type of modification. There are currently 4 of them:

• C - cut (generation will stop at that point, closing geometry will be generated)
• M - modification (angle of branch will be modified)
• R - replacement (branch will continue growing there, but through newly specified component. Suitable f.i. for stubs or dry branches)
• A - add (new branch will be created at that location)

The exact syntax is described in detail in built-in help of "Modifications" attribute. The above image after cut looks like this:

And that's it.

Here are few examples of what is possible to do through modifications. Sources of these samples can be found in Silvador\gallery\modifications.

About Silvador

This blog is going to track development of product called Silvador - a procedural tree model generator. There are more products on the market with similar goal. The main features of Silvador and perhaps points where it differentiates from other products are:

• it can generate whole range of visual LODs from millions down to units of triangles
• output is prepared the way so that it is optimized for real-time environments without a need of manual post-processing, namely:
• output texture data are organized in UV atlases of user defined parameters
• shading is applied to output
• focus is put on making individual LODs to have a similar shape for smooth transition between them
• generated output is relatively tightly coupled with VBS3 and ArmA real-time environments (P3D file format), but generation to industry standard FBX file format is supported as well
• plant structure can be described through interconnection and configuration of range of components. No programming or botanical skills are required, but it is useful to understand basic programming principles like recursion and knowing how plants are organized in a real world

Ambition of this blog is to share thoughts relevant to Silvador development in both directions: show more important moments during development and gather feedback from readers.

Silvador is a commercial product available in 2 versions:

• Pro version supporting full range of capabilities, it can be purchased and downloaded here: https://store.bisimulations.com/products/Silvador-Pro
• Lite version supporting all but exporting functionality, it can be downloaded for free here: https://store.bisimulations.com/products/Silvador-LITE

Following images show what Silvador is about: