I do hope he was exaggerating a little bit there but it made me think: the plants in a sim can often be very heavy on both server and client. But:
I love making elaborate natural landscapes that feel as "real" as possible. That means a lot of vegetation of course, far more than you usually see in an opensim region. Even so, my sims never have any such performance issue.
The secret is to use the right kind of vegetation for each job. Fill up your sim to the brink with high poly mesh vegetation and you're asking for trouble. Fill it up with old style crossed prims and it looks cheap and tacky. All six classes have their place in a well made virtual environment. That being said, Class C and D are by far the ones with the widest range of functionality. As a rule of thumb, if 75-95% of your plants are Class C/D, you be onto something, if not, you probably aren't. It's hard for the end user to know which is which though so maybe this description would be helpful?
This is very much a work in progress so any feedback is highly appreciated:
---*---
TL;DR
For those who don't have time to read the whole rather longish post.
- Class A: For those few extra-super-very-special spots
- Class B: For the extra exposed locations
- Class C: The "bread and butter" of SL vegetation
- Class D: "Bread and butter" with a quantity discount. Class D plants don't always work but when they do, they give a better visual quality/computing cost ratio than any other classes.
- Class E: For the places people can see but never visit
- Class F: Pure background
The Classes
Class A: Feature plants
Plants that are intended to grab the watcher's attention, either because they are particularly detailed or because they have some special features (such as trees with especially elaborate trunks).
Poly- and pixelcounts
The number of polys and pixels doesn't really matter too much for such plants since you shouldn't use many of them anyway (too many stars in the show only leads to fighting) but you don't want to waste resources either. Some plants only need a dozen or so tris and a single 512x512 texture, others, especially large trees, may require tens of thousands of tris and two, three or even more megapixels.
Physics
Class A trees ought to at least have solid trunks you can't walk through and may even need physics for some of the larger branches. Ideally you don't want medium sized plants you can walk right through either. Small plants should always be phantom.
Class B: Foreground plants
Plants you have to cam in on before you notice any lack of details and even if you do, they don't look too bad. Typically Class B trees will have canopies made from flat sheets, less elaborate trunks and lower resolution textures than feature trees.
Poly- and pixelcounts
Small Class B plants shouldn't have more than about 50 tris per plants, medium sized ones (bushes etc.) may have 100-150 while big trees can have 500-1,000 and still count Class B. Usually you don't want more than 0.5-1 megapixels for a Class B plant but you can get away with a little bit more if textures are re-used for several plants.
Physics
When it comes to physics, Class B is pretty much the same as Class A.
Class C: Standard plants
I sometimes call them "playground plants". Less laggy than class A and B but still detailed enough you have to look at them fairly closely to really notice. If you're involved in some other activity (chatting, role playing, driving a vehicle, watching the scene as a whole...) you'll never notice anything missing from them. Class C and D plants make up the bulk of the vegetation in any well optimized region.
Poly- and pixelcounts
Small Class C plants shouldn't have more than about 25 tris per plants, medium sized ones (bushes etc.) may have 50-75 while big trees can have 250-500 and still count Class C. Usually you don't want more than 0.5 megapixels for a Class C plant but you can get away with a little bit more if textures are re-used for several plants.
Physics
Class C trees ought to have solid trunks although it's usually not a disaster if they don't.. Medium sized plants may or may not have physics.
Class D: Volume plants and accentuation plants
All plants - and all other objects too - benefit greatly from an effective context but Class D plants are the experts.
When it comes to effective visual quality they are about the same as Class C plants but by taking full advantage of the "context bonus" they can do this with much lower triangle counts. Grass and flower fields are perhaps the most obvious examples of volume plants but the concept can be taken much further than that. Trees in a dense forest and bushes in a dense shrubbery for example, don't need nearly as complex shapes as free standing ones.
As for accentuation plants, flowers around a rock or a tree stump are perhaps the best example. They don't need to be very complex because they are not the focus point, they are just there to support the real feature.
Poly- and pixelcounts
Small Class D plants shouldn't have more than about 10-12 tris per plants, medium sized ones (bushes etc.) may have 25-30. Big trees can have 50-100 and still count Class D but ideally no more than 25-50. Usually you don't want more than 0.5 megapixels for a Class D plant but you can get away with a little bit more if textures are re-used for several plants.
Physics
Ideally Class D trees have solid trunks but having that throughout an entire forest may be too much to ask for. Medium sized plants can have simple physics if the server has capacity to spare but it's not too important.
Class E: Background plants
So low in lag and land impact you can have masses of them with no problems at all and still looking good at a casual glance or at a little bit of distance.
Poly- and pixelcounts
Small Class E plants shouldn't have more than about 5-10 tris per plants. Larger plants can have 10-25 and still count Class E.
Physics
Class E plants should always be phantom.
Class F: Surround vegetation
Flat billboards with pictures of plants on them. The "good old" privacy screen is of course the most typical example but it is easy to add a 3D effect simply by using several layers of billboards. It looks much better than 2D screens and hardly adds anything to the cost.
Physics
Class F plants are usually phantom but if they have simple physics, they can do double duty as blocks to discourage (although not prevent) unwanted visitors from entering. That can be a nice little bonus sometimes and physics as simple as that isn't likely to cause any issues worth speaking of.
---*---
Some additional points
Waste not, want not
No matter what use a plant has, you don't want to waste resources; keep it as simple as possible, not more and not less. That means among other things that the same plant may well fit several classes. In extreme cases it's quite possible for a plant to be low enough in lag to qualify as Class F and still visually detailed enough to be a Class A.
Reusable resources
Second Life and opensim don't support object instancing but it is still possible to save a lot of resources by reusing the same meshes, sculpt maps and textures for multiple objects. This is especially important on Kitely since the number of unique assets is vital for how fast an offline region can be loaded.
Plant groups
All the recommended tri and pixel numbers are per plant. You can save a lot by using groups of several plants combined into a single mesh, sculpt or prim.
System vegetation
From a resource usage point of view, system vegetation tend to be Class C or D although some are pushing the limit upwards and a few are low enough to qualify as Class E. Whether they look good enough to be used today is another question. It depends much on the textures they use and they are of very varying quality.
PMS (Prims, Meshes and Sculpts)
Polylist meshes (what we usually simply call "mesh") is by far the most useful material for vegetation nowadays but don't rule out the other two options entirely. All three have their pros and cons:
- Prims have exceptionally low bandwidth requirements, usually fairly low triangle counts and eminent LoD and are easy to handle even for fairly inexperienced content creators. Also, the sofware we use is very finely tuned to handle them as efficiently as possible. Their main downside is the limited number of shapes they offer. You often need to assemble a lot of them to construct the shape you want and that can put a lot of load on the poor assets server who has to search and find them one by one in its database.
- Sculpts give you a lot of tris at an amazingly low cost of bandwidth. Their two main disadvantages are that they give you a lot of tris whether you need them or not and that the code that handles them is very, very poorly made.
- Mesh will always require far more bandwidth per tri than prims and sculpts. This is the reason why SL and opessim didn't implement them right from the start. The load they add to the rest of the system depends a lot on the skills of the creator so it's hard to give any general advice there.
Nearly all plants need alpha textures (that is textures with transparent parts). Opensim and Second Life support two different alpha modes: blending and masking. The difference is that with alpha masking each pixel is either fully transparent or fully opaque whilst alpha blending also supports up to 254 levels of semi-transparency. Normally you want to use alpha masking since it is much less laggy and doesn't suffer from the dreaded "alpha sorting bug". Unfortunately there are some plants that only really work with alpha blending and ideally you want to avoid those. A few of them won't do any harm but it won't take many before you get into serious performance problems.
LoD
Plants are normally supposed to be visible from afar. That means with any standard graphics setting they should look perfectly OK even at extreme view distances and never vanish before the viewer's draw distance limit. At least they should look good at 128 m with LoD factor set to 2 - that's Firestorm's decault graphcis settings. (My own standards are a lot higher than that: 1024 m with LoD factor 1 but other plant makers may argue that's overdoing it.)
However, plants with poor LoD may still be useful in secluded spaces (indoors, in narrow valleys, in walled gardens etc.). Also, it's not always realistic to expect sculpts to hold up at long distance. This is due to a mistake LL did when developing the sculpt system and something we just have to live with.
Animation
Wind animation is a very important factor for realistic vegetation but unfortunately SL and opensim do not really have any way to do this. We can do a little bit with the animation function we have though:
- Flexiprims are the ones that can give the best wind animation. When set up right they can be very convincing. The method has three serious drawbacks though, it's hard to find the right values, it only works for prims (of course) and you can't have many flexiprims in a scene before you start getting serious performance issues.
- Ping-pong texture animation is the method I've found to be the most useful by far. It works with any texture and any prim, sculpt and mesh and it doesn't require any scripts to run (you need a script to start it but it can be deleted once the work is done). It's essentially lag free too since it's low priority work the gpu simply skips if it's too busy. The downside is that you can't have much of it before it looks "mechanical" and unnatural. Still, even the faintest hint of flickering of the leaves can do wonders for any scene and since the method has no other disadvantages, it's worth trying for everybody.
- Other more elaborate methods include slideshow texture animation, script controlled animations and animesh. I wouldn't usually recommend any of those. They typically require specially made textures and/or meshes, they add significantly to the server's and/or client's workload and you can get away with much more animation than ping-pong rotation before it becomes mechanical and unnatural. There are some situations where these elaborate animation methods do work well but they are very few.
For those not familiar with the term, a megapixel is 1,048,576 pixels of texture. So:
- a 1024x1024 texture is 1 megapixel
- a 512x512 and a 256x1024 are both 0.25 megapixels
- a 512x1024 is 0.5 megapixels
- a 256x512 is 0.125 megapixels
- a 256x256 is 0.0625 megapixels
Watch out for the bottom line!
All the numbers here are just rough guidelines. To keep it simple I have not taken into account the positive effect good LoD models, object-object occlusion and quasi-mip-mapping can have. Nor have I considered the file size difference between alpha and non-alpha textures or the number of draw calls.
Most important though, is that it's the sum of it all that really matters. A few "misplaced" heavy objects are perfectly fine if the rest of the build is light enough.
A scene made from 5,000 unique meshes/sculpts, 1,000 megapixels and a million tris isn't likely to cause anybody any problems (as long as there aren't other heavy lag factors involved of course). Assign one tenth of that to your plants and with a little bit of thought and care it should be more than enough to fill even a 4x4 region with lush, dense vegetation and still allow everybody to max out their draw distance so they can admire it all as a whole.
It may not be quite enough for a 16x16 but you can't see one of those as a whole anyway so from the viewer's point of view at least, this shouldn't be a problem.