Thursday, January 29, 2015

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.

Monday, January 26, 2015

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.

Monday, January 19, 2015

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.

Sunday, January 18, 2015

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:
Following images show what Silvador is about: