The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, November 29th, 2018 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.
Animesh
Avatar Rendering Cost Calculations Adjustment
An upcoming change that should be appearing at some point in a Maintenance RC viewer will see the avatar rendering cost calculations adjusted in respect to Animesh.
The updates for the calculations were made more frequent in the Animesh viewer (now the release viewer), with the intention of now accurately handling the rendering load with Animesh objects attached to an avatar.
However, there are some types of attachment that make frequent updates to prim properties, and when these are combined with the Animesh-related complexity calculations, it can trigger unintended side-effects (such as repeatedly showing the complexity alert dialogue (e.g “You may not be visible to X %age of avatars”).
The update will throttle the number updates to try to prevent the alert being displayed with every single change, no matter how small, to the complexity cost (significant changes will still generate the alert). It is also hoped the update will address the issue of the complexity alert dialogue being triggered simply by using CTRL-ALT-T.
Possible Rate limits?
Even with the above change, there is still concerns over code that frequently changes prim parameters, because of the additional load it places on the graphics pipeline in calculating / handling the updates. The engineering team is therefore discussing potential rate limits being imposed on such updates in the future – however, this is not something that will be implemented in the short-term, but is something that will be considered over time, most likely as a part of the ARCTan projects as a whole.
Firestorm Animesh Support
A limited beta test version of Firestorm should be available very soon. Depending on how well this performs in testing, a public beta should follow, paving the way for a release in the near future. This update will primarily focus on Animesh integration, but will include some other updates and feature improvements, including significant improvements to the mesh uploader by Beq Janus – as she demonstrates in the video below.
Bakes On Mesh
Project Summary
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.
This work does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.
Resources
- Bakes on Mesh forum thread.
- Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).
Current Status
At the time of writing, a new version of the Bakes on Mesh project viewer was about to undergo QA testing with the Lab, as is expected to appear either on Friday, November 30th, or in the early part of week #49.
This is currently being considered as the “feature complete” version of the viewer, and Oz Linden requested that creators wishing to leverage BoM to please put it to the test to see if there are any serious bugs / issues that need to be addressed.
Depending on the level of feedback gained, and the type of feedback (positive / negative) it is possible the viewer could quickly progress to release candidate (RC) status and perhaps even to release. However, without feedback, the Lab will not be able to fully assess its suitable for RC, etc., promotion.
For testing, note that the back-end support for BoM (which has recently received a “significant” performance update) is now grid-wide on Agni (the Main grid).
Environmental Enhancement Project (EEP)
Project Summary
A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, 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 which include the ability to use custom Sun, Moon and cloud textures. These can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
The project also includes a new set of render shaders to support atmospheric effects such as rainbows, crepuscular rays (“God rays”), better horizon haze and fogging (but will not include rain / snow).
Resources
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- Project Viewer – via Alternate viewers wiki page.
- EEP testing region: secondlife://Aditi/secondlife/EEPTesting/247/44/23
- EEP Feedback forum thread.
- EEP sneak peeks forum thread.
- EEP Jira filter.
Current Status
Rider continues work on the last of the SL functions for EEP support: llSetAgentEnvironment. This allows the environment parameters as applied to individual agents (avatars) within an experience (so if part of the experience requires the environment to be foggy at a certain point, avatars in the experience will have their view become foggy – but visitors who have not allowed the experience to control their avatar (e.g. because they are just observing) will not be similarly affected).
This should be the last of the server-side updates for EEP, allowing Rider to re-focus his attention on the viewer, including updating the experience dialogue to inform users their environment may be modified (where applicable). It’ also hoped that when ready, the next update to the viewer will have more / the rest of the EEP shader updates included.
SL Permissions System
Sansar uses a “supply chain” permissions system. In short, this allows creators to offer goods that can be purchased by others, modified and resold at a higher price, with the original creator receiving a “commission” on each sale, based on the original item’s sale price.
This has generated some interest among content creators engaged in both Second Life and Sansar in seeing a similar system introduced here – or perhaps in extending the Full Permissions option to additionally limit the further resale of unmodified Full Permission items.
However, any changes to the permissions system can have significant impact, and as such, are not something the Lab is liable to approach lightly or tackle in the short-term (or, as Vir Linden puts it, tends to have Lab engineers hiding under the furniture at the thought of changes! 🙂 ).
In Brief
- A reminder that if there are specific improvements people wish to see with Second Life, feature request Jira are the best way to bring them to the attention of the Lab.
- Vir Linden is currently working on a set of under-the-hood inventory improvements. After this, he will likely work on various “low hanging fruit” fixes within the viewer, etc.
- The texture caching project is currently gated by the work on the rendering side of EEP, however, TPVs are advised not to make any significant changes to how they handle texture caching because of the Lab’s own project.
- The code for Linden Realms is to be open-sourced – read here for more.
- The next CCUG meeting will be on Thursday, December 13th, 2018.
Inara Pey: Living in a Modemworld 
It’s good to hear that the Animesh will appear in Firestorm, but the Firestorm in-world support seems to have acquired a habit of denying the possibility of any change being released in the foreseeable future. Somehow, whoever might be talking at these meetings, nothing said about Firestorm can be trusted.
So where do these Firestorm claims come from? Who is it spilling the beans? Are you being manipulated?
That video of the mesh upload does look as though it will be useful, but will is be something else that is limited to Windows?
LikeLike
Blimey. As I’ve noted before when you’ve raised this: Firestorm doesn’t adopt or release a feature until after LL have made the release (they also keep to LL’s request that code not be adopted until it has reached RC status in the official viewer).
There’s then a degree of integration to go through, plus testing – which often includes additional features (as with Beq’s updates to the mesh updater). Ergo, the support team often isn’t in a position to offer possible release dates, as a) they don’t know how testing through the Preview and Beta groups might go b) it avoids the risk of any suggested date being taken as a “commitment”, and the upset it could cause if missed; c) they are volunteers working to provide assistance with the release viewer and my not be au fait with the current state of development.
As to where I get my information from – it by attending in-world meetings that are also attended by senior members of the Firestorm development team who might be more will to talk more openly about *possible* time frames, as they are more au fait with the state of the viewer’s development.
If you’d like to be more first-hand informed, perhaps you might like to attend said meetings as well. You can find details on the User Groups wiki page.
LikeLike