This is a page where users of herbiforge can suggest ideas, and bugfixes. It is intended to be WIKI like, in that it should be discussion based.

The developers will use it to respond to specific requests and to keep the users up to date with planned features for the next release.

Two important aspects to keep in mind when extending these concepts.

The server needs to be able to generate the geometry of the tree/plant in order to to at least basic collision detection. Although it may choose to ignore plants of a certain size or smaller, it still needs to be able to do this.
The client also need to be able to generate this geometry, as well as render the plant quickly, and appropriately for the client. We do not want to impose too much onto the method each client chooses to use to render the plant.

Planned additions to Herbiforge:

We need to get rid of the concrete media interface, and allow artists to add unlimited media to the system with the following attributes:
- Url to media
- Billboard?
- Algorithm( maybe just a range? ) entry to define range of branching levels to which the media is assigned.
- Algorithm( maybe just a range? ) entry to define the scaling of the mesh, possibly separate scaling in x, y and z directions.
- Munin would like these algorithms to be functions of the age, season and the LOD. I (Lakin) would prefer to have the ability to define ranges of age, season and LOD, to which these media apply to. In the end, my goal is to have these conditions be very simple and easy to define.
- In any case, the end goal here is to have the herbiforge itself do most of the necessary repetitive calculations, allowing the Artist to quickly and easily define the complete sets of media required for a particular tree/plant for any given game.
Ability to specify different media and rendering concepts for the same tree which depend upon the season. Control of the season should be a drop down list of seasons which are available for the current target game.
- There should be a 'default' rendering mode which has a complete set of media specified.
- Different seasons allow the use of specific textures/models for each season, this can be a complete set, or can be simple overrides for that season.
  - Example: Evergreens would use all of the default media, except would use a different texture(for snow covered branches) for the winter season.
  - Munin originally wanted to be able to specify ranges of the year for a particular textures. Would this proposal remove the need for this?
- Would there ever be a need to change the models of a tree for a particular season?
Age should be tied to the iterations. That is, after 1 iteration, the lsystem should resemble a young version of the tree, while after 8 or 9 iterations, the lsystem should resemble a full grown version of the tree.
- There should be a way to also associate certain textures and models with certain ages of the trees.

Suggestions by munin:

Currently Herbiforge uses a treetype specific alogorithm to specify branching. The only variables available is number of iterations, and url to meshes and textures. The leaf(ball) object is always on the outermost branch.
My suggestion is to add 2 variables and add more controllability. A procedural tree should be generated based on (in my view) 3 main variables: Season, Age,and LOD (Level of Detail). All three should in Herbiforge have a slider available so that the media creator can check variables quickly.
Age and LOD are more difficult. both young trees and low LOD trees should have few branches. Thus, number of iterations should be an alogorithm of these two. Turthermore, branch length should be a function of the age of the tree. Lakin: Only for client side rendering, the iterations/branching would more likely be tied to the age of the tree.
However, an old low LOD tree should not look like a large sapling. Here comes media assignment in. Currently there are 3 slots for media assignment: Root, Low branch, Middle Branch and Leaf. This is not optimal. To make it possible to use the full potential of procedurally generated vegetation I propose making the list expandable, allowing for assigning anything from 1 to xxx meshes to the plant.

That should be it for now. Spellchecking and comments/ suggestions are welcome. Feel free to edit text.

munin

Comments By Lakin:

LOD requirements, and thoughts.

After thinking about the LOD a bit more, I do realize that my proposal might prove to be a bit clumsy. So I've decided to list a few requirements for LOD, and some thoughts.

I still have my doubts of tying LOD to the iterations. Generally in L-Systems the iterations represent the aging process of the plant, and I think we should keep it this way. Not only for clarity, but also to allow the server to simply execute another iteration everytime the tree's age increases appropriately.
- I can still be convinced, I would just need a concrete plan of attack which will allow iterations of the system to be tied to both LOD and age.
- One reason I doubt this method is that the tree should take up essentially the "same" space no matter what the LOD is. We just want to ease the requirements of rendering the tree so the client can quickly render trees which are far off.
- the number of iterations directly affects the branching complexity of the tree. This is an almost direct relationship with the age of the tree. Therefore it seems to be a clear match of the age to the iterations.
I do think that it is wasteful to produce the full branching structure of the tree when it is still far off. As such, we need a clear concept of how we can achieve the following:
- The lowest LOD should not include a branching structure, but should be a simple billboard(a 1D texture perpindicular to the camera at all times) rendering of the tree.
- The lsystem for a low LOD tree should be very quick and easy to compute and render.
- The lsystem should have an efficient manner of moving back and forth between each successive LOD.
- The highest LOD should create a branching structure which is identical to the branching structure created through the 'aging process' using the same seed as the server used.
All of these requirements just SCREAM that we need a nice multiresolution scheme for L-Systems, but as of yet, I have not come across any literature suggesting how such a scheme could be achieved. It could be achieved by using well known model or curve multiresolution schemes, but these require that the highest level of resolution be calculated first, and then we can move freely between resolutions, violates our requirement for an efficient method of achieving the initial level of detail without knowing the full branching structure of the tree.
So, in reality, we need to create two equivalent L-Systems which result in the same tree, one where the iterations represent the passing of time and the aging of the tree, and one where the iterations represent the different level of details available.
- I'm not sure this is possible.
- I'll refuse to accept a scheme which requires the artist to produce these.
- These 'alternate' representations need to be computable from definitive artist built L-System, such that at media distribution time, these two paths are computed.
- If we can conceive of a system which will work without the random rule selection, I think I can map this system to another system which will work with the random rule selection.
- The second system which produces the multiple levels of detail.

Some quick ideas on how it MIGHT be achieved:

The server would need to send "guiding" variables to the client when describing the tree. These guiding variables would allow the client to build a simple model which is close to being correct for the first level of detail. Then with each successive iteration it would build a tree that is closer to being correct, until finally, it builds one which is exactly correct.

The server would send basic attribute variables like: seed, height, orientation, radius of the sphere enclosing the tree, etc.
The client would use the seed, and run 1 iteration which would result in a young version of this tree, but provide some important information: The base root, and the basic directions for the branches. From this it could quickly generate a version which was the correct height and size and uses these basic directions to place some low LOD branches.
Then as the client needed, it would run more successive iterations on the tree, (Using the same lsystem as the server) each iteration would provide the client with a closer representation of the tree, allowing it to better guess at the shape of the final tree, but it would use the provided variables to make sure the tree was the right size etc.

eventually the client would achieve the final correct branching structure, and could then render the tree with a perfect level of confidence.

The bad things about this is:

I'm not sure how expensive it would be. If we can come up with a way of "guessing" at the tree to produce something similar at low LOD's then it might be feasible. This method would need to be faster than just generating the full branching structure and rendering it at a low LOD.
The possible number of LOD's would be tied directly to the age of the tree. The older a tree gets the more level of details are possible. I'm not positive this is bad in the case of old trees, but having only 1 LOD for young trees sounds like a bad idea.