System vegetation
Opensimulator: Documentation: Asset types: System Vegetation
System vegetation is a special form of procedural models intended to create plants with a lower streaming cost than those made from prims, sculpts or mesh.
The models are generated by the viewer, mostly from predefined values and data stored in two xml files, grass.xml and trees.xml. that are included in the viewer download package and located in the viewer's app_settings subfolder. Only a few parameters are delivered from the server. This of course means that the load the plants put on the servers is all but negligible. This is however not quite true for the viewer. System vegetation is always farily simplistic and not likely any serious stress to any modern client computer. But even so, neither the code nor the mesh generated are well optimized.
There are two basic kinds of system vegetation "Trees" (really any single plants) and "Grass" (really any multi plant ground cover).
The main problem with system vegetation, however, is that it's way outdated. It was developed as early as 2002 and apart from the addition of one more ground coverage option it has never been updated. A lot has changed to computer graphics since then and although system vegetation isn't completely irrelevant most of the variants do not meet the expectations to visual quality people tend to have today.
Physics
System vegetation is always phantom.
Textures
Textures are one of the main shortcomings of system vegetation. Alpha cutout texture were harder to make and rarer to find back in 2002 than they are today. Linden Lab had to make do with whatever they could scrape together which resulted in a rather mixed bag of styles and qualities. Most of the textures seem to be based on hand-colored illustrations from old public domain botany books, some are cutouts from photos and only a few seem to be specifically created for textures.
Alpha
System vegetation uses alpha masking and was the only element of Second Life and Opensimulator to do so until new materials were implemented in 2013.
UUIDs
The UUIDs for the various variants are the same in Second Life and Opensimulator and can be found in the xml files.
Grass
A piece of system grass consists of 32 flat panels with a picture of some sort of vegetation on them. The panels will always be aligned with the system terrain and can not be moved vertically. Nor can the panels be resized; changing the vertical (z axis) scale has no effect and changing the horizontal (x and y axis) scale will change the distance between the panels.
Variants
There are six (really only five) system grass variants:
- Grass 0 Yellowish-green grass with straws.
- Grass 1 Dense cluster of poorly masked grass.
- Grass 2 For most practiucal pruposes identical to Grass 0. It uses the same texture but is slightly bigger.
- Grass 3 Similar to Grass 1 but lighter color and bigger.
- Grass 4 An "autumn variant" of Grass 0/Grass 2. Bigger and with reddish-brown colors
- undergrowth_1 Small alder(?) shrubs.
Parameters
The parameters delivered by the server are type, location, scale and rotation. The parameters stored in the grass.xml file are:
- name
- The name the plant is given in the edit/build palette.
- species_id
- A unique number for each type of plant on the list.
- texture_id
- As the name implies: the UUID of the texture to be used.
- blade_size_x
- blade_size_y
The exact placement of each panel relative to the others is random. All other parameters are predefined and can not be altered.
UV mapping
The UV mapping for the grass is simple, just a single texture covering the whole map.
Level of Detail
System grass does not seem to have any LOD simplifications, it's render in full at any view distance.
Trees
A system tree is a single plant and there are 21 variants. Most of the names are self-explanatory:
- Pine 1
- Oak This is not actually an oak at all but a small maple with orange autumn leaves.
- Tropical Bush 1 Looks like some sort of palm shrub.
- Palm 1
- Dogwood
- Tropical Bush 2
- Palm 2
- Cypress 1 Not really a cypress. The texture used for the foliage is from a cypress but the canopy shape is typical for genereic hardwood trees and not like any common type of cypress.
- Cypress 2 Not really a cypress. The texture used for the foliage is from a cypress but the canopy shape is typical for genereic hardwood trees and not like any common type of cypress.
- Pine 2
- Plumeria A seriously oversized flowering shrub.
- Winter Pine 1
- Winter Aspen
- Winter Pine 2
- Eucalyptus
- Fern
- Eelgrass
- Sea Sword
- Kelp 1
- Beach Grass 1
- Kelp 2
The trunk
All system "trees" have trunks and branches but for those that aren't actual trees they are scaled down and hidden inside the foliage.
The basic trunk segment is a cylinder with a narrow waist and pointed ends. Some trees have several trunk segments of diminishing sizes stacked on top of each other others have only one. The number of segments is set with trunk_depth. The scale of consecutive trunk segments relative to the previous is probably set with scale_step but this needs to be confirmed.
A trunk segment has 10 edgeloops, each with nine edges and ten vertices (the ends of the edgeloops are not joined and seem to overlap slightly). The vertices of the top and bottom edge loops are collapsed but not joined. This is what gives the segment the pointed ends. The total number of vertices and triangles are 100 and 162 respectively.
The branches
The branches are located around the second highest edgeloop of each trunk segment and spaced evenly around the circumference of the tree. The branch mesh is essentially the same as a trunk segment one but it does not have the noise parameters and the taper is fixed to a value slightly lower than 1.
Sidebranches are arranged around the second to highest edgeloop of branches of the previous level in the same way that main branches are arranged around the trunk.
The foliage
The foliage consists of one or more pairs of crossed panels ("billboards") arranged around the second to highest edgeloop of the highest level sidebranches (or around the trunk segment if there are no branches) the same way as branches are arranged around the trunk segments.
Size
In Second Life system trees are assigned a random size when rezzed, on opensim the nominal size is always 4x4x4 m or 4x4x10 m depending on the tree type. In either case the tree can be easily rezised after rezzing
The actual size is more complicated though. A system tree is a linkset with the trunk (or each trunk segment is there are several), each branch/sidebranch and each foliage panel being a separate object. The nominal size is the size of the bounding box of the root of the linkset which is the trunk or lowest trunk segment if there are several. The other parts are scaled according to the root size and various parameters.
The bounding box isn't the actual size of the root object either. With trunk_length set to 1.0, the visual model extends slightly above and below the bounding box. With a lower trunk_length value, the actual size is smaller than the nominal.
To complicate the matter further, the proportions of a tree can not be changed all all three scale parameters affect the size along all three axises.
The formula for the length of the root seems to be L=(x+y+z)/3*trunk_length/10*n where x, y and z are the nominal scales along the three axises and n is a constant slightly higher than 1.0. This formula needs to be confirmed but even if it's not correct, it seems to be close enough for all practical purposes.
The actual size of the tree as a whole depends on several parameters and it's far too complicated to go into details here.
Parameters
The parameters delivered by the server are type, location, scale and rotation.
The parameters stored in the XML files are:
- tree name
- The name the plant is given in the edit/build palette.
- species
- A unique number for each type of plant on the list.
- texture_id
- As the name implies: the UUID of the texture to be used.
- droop
- The angle of the branches.
- twist
- branches
- The number of branches at each level.
- depth
- scale_step
- trunk_depth
- The number of trunk segments.
- branch_length
- trunk_length
- The aproximate length of the main trunk segment relative to the nominal size.
- leaf_scale
- billboard_scale
- billboard_ratio
- trunk_aspect
- branch_aspect
- leaf_rotate
- noise_mag
- noise_scale
- taper
- repeat_z
- The nominal number of verticle texture repeats along each trunk and branch segment. The actual number of repeats is slightly higher than the nominal but not significantly so.
Level of Detail
Due to their excessive geometry trunks and branches need to be heavily LOD reduced and collapse into flat sheets even at a moderate view distance. Canopies don't seem to have any LOD reduction at all.
The trees has a "impostor" function, that is a flat sheet with a picture of the whole plant used as the lowest LOD model. This function isn't currently enabled though and may never have been implemented.
UV mapping
Trees use a texture atlas. The bark texture, used for the trunk segment(s) and branches, takes up the left half of the map. The foliage texture is assigned to the upper right quarter but for some plants only a small part in the middle is actually used. The lower right quarter is reserved for the impostor texture; see the Level of Detail section above.
The UV maps for trunk and branches are upside down.
Animation
System trees used to have an optional wind animation feature. It was a very simple function, just the whole plant rocking back and forth around its lowest point. According to Linden Lab, the effect has been described as "disturbing" and it was disabled long ago. Singularity eventually reintroduced it but it seems to have been intended more as a fun effect than anything else and no other viewers have followed up.
Creating System Vegetation
Technically it's very easy to create new system vegetation variants although since there is no documentation it make take a bit of trial and error, especially to figure out the exact UV mapping for the tree foliage.
To add your new plant(s) to your viewer, simply add the data to the appropriate xml file and it will show up both it the list of options in the build window and in-world. However, it will only show up in viewers that has the same modified xml files so this is not recommended unless it is for a private place with no visitors. If a viewer comes across a variant it doesn't recognise, it will render it as a Pine 1 for trees or Grass 0 for grass.
