Flowers and blossoms

Version 1.53 of Silvador comes with improvements, that allow creation of complicated plant structures such as flowers or blossoms. Mainly two new structural components are behind this improvement. They are called Hydra and Urchin.

Hydra

Hydra component does not generate any geometry on its own, but is able to spawn in a controlled way generation of descendants located in a circle. With almost default parameters the component can produce a structure like this:

Apart of number of descendants and if they are spawned along the whole circle or just in an arc, it is also possible to control their type, probability and orientation with rich set of parameters. Using Hydra component it is possible to describe f.i. petals. If we play with that a bit, we can already create believable blossoms, like this:

This particular blossom we can find among templates coming with Silvador and it can be a good starting point for many types of blossoms.

Urchin

Similar to Hydra, Urchin component also spawns descendants in an organized way. This time the descendants are filling a disc in a hexagonal shape, typical in natural structures. By default Urchin component produces structures like this:

It can be used to describe inner of the blossom - florets (f.i. inner circle of the sunflower). Number of attributes come with Urchin. Apart of density and size of the disc we can also control profile of the disc itself. Note that many attributes including the profile are defined as a curve, addressed by the distance from center.

Examples

All the following examples were created in Silvador with help of the above components. Some of those are present in the gallery distributed with Silvador.

Improving normal map on billboards

To enhance lighting of objects in dynamic virtual environments, maps that contain information about normal of every texel of a surface of a model are being created. Those are called normal maps. Silvador also generates normal maps. They look like this:

If we look at the trunk, it looks fine, there is not much to be improved - it just matches the geometry the texture represents. But if we look at the crown that consist of more-or-less randomly rotated leaves, its worse - there just appears to be something that resembles a white noise. There is no structural information about the crown whatsoever. And if we use it for shading, the result corresponds to that, it is flat. If there would not be for the trunk, we couldn't say what direction a light is coming from.

In Silvador since version 1.53 there is a new option, by default on for billboards, it is called VisualizerLOD2.polyplaneCrownAwareNormalMap. It influences the way normal map is calculated. It also considers original normal of a leaf just as the original approach, but weights it by the visibility of given point from given direction. That means that normals tend to point more to direction they are visible from. We calculate the adjusted normal iteratively using this formula:

      M = normalize(sum(for x from <0, n>)(shadowCoef * max(dot(N, Lx), 0) * Lx))

, where:

      N - normal vector of the surface

      L1..Ln - individual vectors of light contribution (possibly shaded)

      M - adjusted normal, respecting visibility of given point

The difference is significant. Following 2 images demonstrate difference without and with the crown-aware normal map:

There is suddenly much more low-frequency information present in the normal map. Normals on the left side of the crown tend to point left and on the right side to the right. This is what will give the tree crown a spherical shape after lighting is applied. This is how you can see the result lit in the virtual environment of VBS Blue (original normal map, crown-aware normal map):

If we look at the tree crown on the right image, we don't have a problem to identify what direction is light coming from, unlike the left image.

Overview of generated maps

Let's recapitulate what all maps Silvador can generate at the moment:

Albedo RGB / Alpha:

 

Macro RGB / Alpha:

 

Normal:

Enhancing visual quality of billboards

For real-time rendering it is essential to be able to simplify model geometry down to units of triangles. This simplified version is either a set of perpendicular faces (we call it a polyplane), or one face rotating towards the camera position (we call it a billboard). In this article we focus on such geometry and show examples of billboards, but it applies to polyplanes too.
Quality of the billboard texture is very important: Some real-time environments render just those, even on close. Other engines use 3D models on close, but they usually want to switch to billboards as soon as possible, usually quicker than other objects. In general, plant billboards are being rendered at very close distance in most of the cases. Their quality matters.

Manual polyplanes

Let's take a small detour: In Silvador, if we don't want to rely on automated geometry simplification (automated polyplanes), we don't have to. We can model one or more types of branch ends, the geometry in full detail can look like this:

Using ExporterProxy component, we can simplify the geometry down to one polyplane and generate a model that looks like this:

Consequently we can put such manually created model (polyplane) on top of a tree structure like this:

And we get a final model like this:

Note the bright sides - we have a complex model of a tree simplified down to reasonable number of triangles (18044) for rendering and we have the shape of polyplanes fully under control.

The problem

And now the dark side. When we want to create a billboard texture from such a geometry, we have a problem. The polyplane simplification is too visible in the output. In general there are 2 types of problems: One is, that polyplanes that are in too sharp angle to camera view form a line-like artifacts. Another one is, that polyplanes tend to have too uniform lighting on them, even though normal map is applied. The macro texture looks like this:

These artifacts are very well visible on the final output.

The solution

There is a way out of this. The main problem is, that we use simplified geometry for rendering into billboard. And we don't have to. The manual polyplane is defined up to leaf level. When we generate model out of it, we can generate 2 versions: One the usual geometry simplification down to one polyplane, second the original full geometry generated up to leaf. First is used for producing 3D geometry with polyplanes of reasonable number of triangles, second is used for billboard shading. It makes the shading more demanding as there are going to be millions of triangles to render, but as it is happening offline, it is a small price to pay. And the output looks like this:

Silvador since version 1.53 supports automated generation of both mentioned versions during proxy model generation. It puts them as two separated lods of generated model. It is being controlled through argument ExporterProxy.generateDetail.
This is how the problem and the solution looks like in the realtime environment: