Plant classification - does this make sense?

General discussions related to content creation
Post Reply
User avatar
Tess Juel
Posts: 72
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 51 times
Been thanked: 110 times

Plant classification - does this make sense?

Post by Tess Juel »

At A Kitely comunity meeting a few months ago, Ubit said he wished there was no plants on opensim apart from the system vegetation because plants are so heavy on the servers and bandwidth.
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.
Transparency

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.
A few notes about textures

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
Don't forget that normal and specular maps are textures too. They may not be quite as heavy to render as regular textures but they still take up jsut as much badnwidth and VRAM.

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.
Last edited by Tess Juel on Thu Dec 17, 2020 8:37 am, edited 2 times in total.
These users thanked the author Tess Juel for the post (total 7):
Ilan TochnerSnoots DwagonRezMela AppsDot MatrixAnthony EliasonAlexina ProctorPrax Maryjasz
User avatar
Snoots Dwagon
Posts: 254
Joined: Mon Jul 30, 2018 9:45 pm
Has thanked: 259 times
Been thanked: 457 times

Re: Plant classification - does this make sense?

Post by Snoots Dwagon »

I wonder about the reasons Ubit had for making that statement. It seems one of those "An empty sim is a happy sim" comments. A world with no plants? :cry:

As you point out, I believe the problem isn't plants as a concept, but the way some plants are made and used. Many plant creators use large flexiprims to give their plants motion. We once tested flexible prims for lag, and discovered they created significant lag. I was unable to determine whether that was server side or viewer side (likely viewer side)... but it was immense compared to other prim types.

Another problem is that many plants are not turned phantom, thus bear impact as people walk across typically ragged surfaces (compared to bare ground or flat prims). Every time someone collides with non-phantom grass or vegetation or tree folliage, it creates collision impact. Plants are especially significant in this problem because they often contain complex shapes. (How many times have we been flying along and suddenly become seriously tangled in tree branches?)

So just as with scripting, use of physical objects, particles or anything else... there's a right way to use foliage, and a not-so-right way. Having 100 trees consisting of large, flexiprim branches is not the best idea for a world. Sometimes one has to choose between "realism" and virtual world impact.
These users thanked the author Snoots Dwagon for the post:
Alexina Proctor
~~~~~~~
Please enjoy visiting DragonForge on Kitely Market. Home of Dwagons.
Check out Weefolk Township on Wellspring megaworld... Kitely's first Tiny community
Free avatars, free homes... Wee is Free.
~~~~~~~
User avatar
Dot Matrix
Posts: 1560
Joined: Sun Jul 28, 2013 3:26 am
Has thanked: 1065 times
Been thanked: 2139 times

Re: Plant classification - does this make sense?

Post by Dot Matrix »

That's a helpful analysis, Tess -- thank you. I notice that the classification is one you use on your own plants and trees.

I'm looking out for some full-perm single prim trees that could be used to create speedy landscaping as part of a kit. Would you consider offering some of your trees as full perm, to be sold (CM only of course) as part of such a kit?
These users thanked the author Dot Matrix for the post (total 2):
Snoots DwagonAlexina Proctor
User avatar
Tess Juel
Posts: 72
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 51 times
Been thanked: 110 times

Re: Plant classification - does this make sense?

Post by Tess Juel »

Snoots Dwagon wrote:
Fri Dec 11, 2020 4:03 am
I wonder about the reasons Ubit had for making that statement. It seems one of those "An empty sim is a happy sim" comments. A world with no plants? :cry:
I don't think he meant it literally but he definitely had a point.
One of the more recent problems I've seen with opensim vegetation is a program called Tree[d]. It's a free application that generates fairly decent looking trees at the push of a button. Usually not good enough to qualify as Class B but with a few minutes of tweaking you should be able to get some moderately good Class C trees out of it. Unfortunately they come at a render cost that would be high even for Class A feature trees. I've seen a lot of them recently and a performance/load ratio as poor as that there is bound to cause issues.

Another problem is of course that there is still a lot of outdated sculpt vegetation around. Mind you, I say outdated, not bad. JubJub Forder's origami inspired way to fold a flat sculpt sheet into the standard crossed panel simple plant shape was a major breakthrough in SL/opensim building and I'm still lost in admiration and love for the skillful design of Lilith Heart's marvelous oak trees (and many other early sculpt plants as well). From that perspective it's easy to understand why the copybotters have spread their works far and wide across opensim. But 2000+ tris for a single, simple shrub? Or 20,000-40,000 for a single tree? That's just insane now that we have mesh. Time has moved on and so have those creators. It's time to retire their early works.
Sculpts still have a limited place in good plant making btw. If you can find ways to get a lot of plants out of a single 2048 tri sculpt they can be very performant indeed. The render engine doesn't care whether the tris it's drawing originated from a prim algorithm, a sculpt map or a polylist. It's all the same as far as it is concerned.
Snoots Dwagon wrote:
Fri Dec 11, 2020 4:03 am
As you point out, I believe the problem isn't plants as a concept, but the way some plants are made and used. Many plant creators use large flexiprims to give their plants motion.

...

Another problem is that many plants are not turned phantom,
Two very good points. I mentioned them briefly in my original post but I should have said more about them. I have re-written the entire post, discussing animation and physics in more detail and also added some other things I should have remembered to include.
Last edited by Tess Juel on Mon Dec 14, 2020 8:27 am, edited 3 times in total.
These users thanked the author Tess Juel for the post (total 2):
Snoots DwagonAlexina Proctor
User avatar
Tess Juel
Posts: 72
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 51 times
Been thanked: 110 times

Re: Plant classification - does this make sense?

Post by Tess Juel »

Dot Matrix wrote:
Fri Dec 11, 2020 9:32 pm
That's a helpful analysis, Tess -- thank you. I notice that the classification is one you use on your own plants and trees.
YW, glad you like it. :)

I've used an early draft of the system for some of my plants. I may have to revise their classifications but I don't think there's much difference. This new and possibly final revision is mainly about defining the classes more precisely. The only drastic change is that I merged the original Class F and G into one but I've never made any Class G plants anyway and probably never will. (In case you wonder, the original Class F was for 3D screens using multiple billboards to add depth, Class G was the regular 2D single billboard screen.)
Dot Matrix wrote:
Fri Dec 11, 2020 9:32 pm
I'm looking out for some full-perm single prim trees that could be used to create speedy landscaping as part of a kit. Would you consider offering some of your trees as full perm, to be sold (CM only of course) as part of such a kit?
Yes, I probably should. I do sell plants full perm when people contact me and ask but i haven't listed any officially yet for three reasons.

One is that the database I have listing all my works have close to 200,000 entries. It's not quite as bad as it sounds - lots of texture variants and such and also complete builds assembled from my own standard parts - but it's still a lot to shift through to decide which to group together and which not to sell at all. Then I have to write product descriptions, take promo pics and make posters. It's raher overwhelming. I'm also worried about the number of listings in a store. In SL I have six different stores for different product categories but I don't think that's an option here. Keep in mind that this is a hobby for me. I would have loved to be able to work full time as a content creator for opensim but unfortunately the market isn't anywhere big enough.

The second reason is that I have some bad experiences listing alternative perm variants at my builder's supplies store on SL MP. Too many customers got confused and ended up not buying what they thought the bought.

The third reason isn't a problem anymore but it was until recently. I was planning to open a separate SL store for full perm kits and finished builds in collaboration with another content creator. Those plans came to nothing though so maybe it's time to look for other alternatives for those builds.
These users thanked the author Tess Juel for the post (total 2):
Alexina ProctorDot Matrix
Post Reply