sl-service-account
commented
1 year ago ChinRey commented at 2023-06-14T10:01:43Z, updated at 2023-06-14T11:34:27Z
Six comments (Edit: make it seven):
- I think the existing system plants should be kept as they are, warts and all, to maintain backwards compatibility. Add some more plants instead. It's very easy to do. The only problem is that the data for the new plants have to be included in the tree.xml or grass.xml file so it can only be done as part of a viewer update.
—
- PBR materials would be an improvement to system vegetation and it should be much easier to implement than more drastic changes. But is it enough? System vegetation attractiveness is a binary value it's either TRUE or FALSE: the visual quality is either good enough people are happy to use them instead of mesh plants or it isn't. There's nothing in between. Is PBR really enough to make people want to swap their laggy mesh trees with system ones? I'm not sure and there's no point in spending development resources on features nobody will actually use even if they are easy to implement.
—
- We have to keep in mind that although system trees are very light for the server and connections, requiring only 24 bytes of data to be transferred, the meshes the viewer generates are rather inefficient and can be very render heavy. One of the heaviest of the current system trees is the Cypress 2 with no less than 28,512 tris at full LOD - easily a hundred times as many tris as a well optimised mesh tree with similar level of visual quality would have. To be fair, there is no realistic scenario where an entire big system tree will ever be rendered at full LOD but even with the entire tree rendered at lowest LOD the triangle count is as high as 1,936 (if my calculations are right). That's still several times as high as what a tree of that quality should have at full LOD.
Most important if you are going to create new system tree variants is to keep in mind that none of the existing ones are anywhere near the mesh complexity the system allows for. I once made a variant with a very high branches value to create a dense round canopy. It looked really good but a single copy of it was enough to cause serious render lag.
—
- Animat's triangle calculation for the Cypress 2 tree is incorrect. Without going into details (I've explained it to him in an IM) the depth parameter doesn't work quite the way he thought and he didn't know that the trunk_depth parameter also has a huge impact on the triangle count.
—
- When it comes to LOD, I don't think there's much to gain there. The trunk and branch segments are already reduced down to flat sheets even at a fairly high LOD level (LOD_2 believe but certainly LOD_1). The problem is that a system tree is made from so many parts that the triangle count is fairly high even if each part is reduced to a minimum.
Implementing the impostor function for LOD_0 would help of course. If it's possible that is: I'm curious about how. A system tree is not an object. It's a linkset and just like any other linksets each part is treated as a separate object when it comes to LOD. I don't know but is the reason why the impostor function was disabled (or never enabled?) in the first place? I do know that Animats has been working on impostors for other linksets though so maybe he has a solution?
—
- I don't know the problem with the Pine 1 impostor being applied to Palm 1 but I have seen some other caes where the species/species_id parameter has reverted to 0 (Pine 1 for trees, Grass 0 for grass). This may need a separate bug report.
—
- I didn't notice the propsal to switch to alpha masking. System vegetation already uses alpha masking and always has.
How would you like the feature to work?
The built in tree system is very old. It predates mesh. It predates materials. Once terrain gets materials, system trees will be the last thing still using only flat shading.
Per Simon Linden's suggestion at Server User Group, a proposal:
System tree textures get material layer support.
The "trees.xml" file in in the viewer gets a "material_id" for each standard tree.
Improve art for trees, providing material layers.
Match impostors to generated trees.
Only display generated trees in close up. This allows large forests with low triangle count. Impostors seem to be disabled in some viewers. They should be turned back on. Don't use lower LODs for generated trees. They're awful and sometimes result in pointy bare trunks. Drop all the way to impostor mode instead.
These are all reasonably easy to do, and low-risk. New servers and old viewers, and vice versa, should still interoperate successfully.
Images: frostartrees.jpg - trees
Why is this feature important to you? How would it benefit the community?
System trees just look bad compared to modern SL content. Forests of system trees don't look good and have a high rendering load.
boardroomtreesfs.jpg - Firestorm showing some trees, at Boardroom region.
boardroomtrees1.jpg - Sharpview showing the same trees as a cross of flat impostors, using the impostor image from the system tree texture atlas. 16 triangles.
Attachments
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-233997 | | Summary | Proposal: System tree upgrade, phase 1. | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Unresolved | | Reporter | animats (animats) | | Created at | 2023-06-13T20:27:39Z | | Updated at | 2023-06-21T18:22:01Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-06-14T05:01:43.229-0500', 'How would you like the feature to work?': 'The built in tree system is very old. It predates mesh. It predates materials.\r\nOnce terrain gets materials, system trees will be the last thing still using only flat shading.\r\n\r\nPer Simon Linden\'s suggestion at Server User Group, a proposal:\r\n\r\n1. System tree textures get material layer support.\r\n\r\n2. The "trees.xml" file in in the viewer gets a "material_id" for each standard tree.\r\n\r\n3. Improve art for trees, providing material layers.\r\n\r\n - Normals for bark.\r\n - Normals for some leaves.\r\n - Trunks in impostors get normals which give the trunk curvature.\r\n - Some shinyness for leaves where appropriate.\r\n - Set material to alpha masking, to reduce overhead.\r\n - Match existing art closely enough that few users notice.\r\n - Fix badly broken art. \r\n -- Palms 1 seems to have the leaves from Pine 1.\r\n - Match impostors to generated trees.\r\n -- Palms 1, again, is badly matched.\r\n \r\n4. Beyond 2x-3x the tree height/width or so, go to impostor mode.\r\n\r\nOnly display generated trees in close up. This allows large forests with low triangle count. Impostors seem to be disabled in some viewers. They should be turned back on. Don\'t use lower LODs for generated trees. They\'re awful and sometimes result in pointy bare trunks. Drop all the way to impostor mode instead.\r\n \r\n5. No change to procedural tree parameters in this phase. A rewrite of the L-system that generates trees can be considered for phase 2. While some trees currently have excessive triangle count, if we only fully render those within 10-20 meters, that won\'t hurt performance much. Chin Rey notes that "Cypress 2" has a huge triangle count. The number of branches in a tree is "branch count" ^ "depth", which ranges from 5 for "Pine 1" to 81 for Cypress 2. \r\n \r\nThese are all reasonably easy to do, and low-risk. New servers and old viewers, and vice versa, should still interoperate successfully.\r\n\r\nImages: frostartrees.jpg - trees', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "System trees just look bad compared to modern SL content. Forests of system trees don't look good and have a high rendering load. \r\n\r\nboardroomtreesfs.jpg - Firestorm showing some trees, at Boardroom region.\r\n\r\nboardroomtrees1.jpg - Sharpview showing the same trees as a cross of flat impostors, using the impostor image from the system tree texture atlas. 16 triangles.\r\n\r\n", } ```