The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, March 26th 2020 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.
Following the promotion of the Premium RC viewer in week #12, the following viewers were merged up to that code base on March 25th:
- Camera Presets RC viewer, version 184.108.40.2068729.
- Love Me Render viewer, version 220.127.116.118760.
At the time this report was written, the rest of the SL viewer pipelines remain as:
- Current Release version version 18.104.22.1688264, dated March 12, promoted March 18th. Formerly the Premium RC viewer.
- Release channel cohorts):
- EEP RC viewer updated to version 22.214.171.1248823, March 20.
- Zirbenz Maintenance RC viewer, version 126.96.36.1998719, issued March 19.
- Project viewers:
- Copy / Paste viewer, version 188.8.131.523365, December 9, 2019.
- Project Muscadine (Animesh follow-on) project viewer, version 184.108.40.2062999, November 22, 2019.
- Legacy Profiles viewer, version 220.127.116.110836, September 17, 2019. Covers the re-integration of Viewer Profiles.
- 360 Snapshot project viewer, version 18.104.22.1689111, July 16, 2019.
Environment Enhancement Project
A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- Is now “really close” to be ready for release, with all of the graphic team working hard to eliminate the last of the issues that have been seen as blocker to moving the project to formal release status.
- There may only be two remaining blockers that need to be cleared.
An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).
As of January 2020 ARCTan has effectively been split:
- Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations and providing additional viewer UI so that people can better visibility and control to seeing complexity. This work can essentially be broken down as:
- Collect data.
- Update ARC function.
- Design and provide tool within the viewer UI (i.e. not a pop-up) that presents ARC information in a usable manner and lets users make decisions about rendering / performance.
- Work on providing in-world object rendering costs (LOD models, etc.) which might affect Land Impact will be handled as a later tranche of project work, after the avatar work.
- The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.
- Vir is still trying to resolve the appearance / Bake Service issue he thought he might have a fix for.that has been causing problems with ARCTan testing. This has yet to be QA tested. Should it pass, then it will mean internal testing can resume.
Currently: offering the means to change an Animesh size parameters via LSL.
- Still technically on hold, but Vir has been looking at what will be required to get what had been worked up back up-to-date This work, when it can be tackled will include:
- Merging the project viewer up to the current release viewer / EEP.
- Updating the server code with all of the updates made to the simulator code, which is described as a “fairly major” piece of work.
- LL is continuing to see a rise in Second life use as a result of SARS-Cov-2, and the majority of the services are handling things well.
- There is a report that larger Animesh objects do not LOD (level of distance) swap gracefully if the viewer cache has been heavily used (e.g. as a result of going to an even), even if the Animesh has been previously cached. The only ways to clear the issue appear to be re-logging or clearing cache.
- This is not a known issue or something LL have seen, and a Jira has been requested on the problem.
- There is an issue with the LL viewer getting confused between RC viewers when updating to a more recent RC update. This is a known issue and is being investigated.
- There was a discussion over animation priorities and expanding the current range of priorities (with one suggestion they should go as high as 15!).
- An advantage with a greater range is that in theory allow for more granular control of animation types (e.g. 0-1 for default system animations; 2 for general AO animations (standing, walking, running, flying); 3-4 for common AO animations (e.g sitting); 5 for “speciality / custom” AOs; 6 for “must run in all cases”.
- The flip side to this is the issue of creators just opting for the higher-end settings “because they are there”.
- The ability to dynamically set animations via LSL was also re-mentioned and discussed.
- Vir noted that were LL to look at implemented the dynamic application of animations, they might also look at priorities and priority ranges.
- A further request was made for a “standalone”alpha channel for materials (separate to the one pre-baked into the diffuse texture channel. This is something that has been requested in the past (e.g. see: BUG-224928), and something not under current consideration.