The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, November 14th 2019 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.
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.
Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- Merging with the last set of viewer releases has caused issues, and these are currently being addressed.
- Beyond the above issue, clearing the remaining EEP bugs is “a priority focus”.
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).
- Vir is working on providing a means for data collection across a range of different viewer-side hardware specifications.
- His previous work on textures and texture handling / loading have revealed it is hard to quantify in terms of accounting for performance impact, as textures don’t result in the same kind of impact as mesh triangle complexity.
- With mesh, there is a clear complexity correlation between the number of triangles and performance / complexity hits.
- The number of textures on a object don’t behave the same way, other then during initial loading or if they push against memory limits, so, there’s no gradual degradation in performance with texture that can be seen with mesh, making it harder to produce accurate calculations.
The avatar system has become considerably more flexible over the years, but also far more complexity to use. Given this, Vir put out a question on whether there is anything creators would like to see Linden Lab do in terms of managing the avatar behaviour and configurability.
For example, one aspect of avatar system management is HUDs, which can be impactful in a number of ways – resources simulator side, texture use viewer side; general ease-of use. Discussion on this raised some suggestions ideas:
- Presenting them through (if possible) a dedicated floater in the viewer that could be dragged around like any other floater, minimised, etc.
- Possibly extending llDialog to prove better support for HUD-like actions via dialogues.
- Providing an HTML-based means for HUD-style interactions.
- Having a “favourites” inventory folder sub-set, floater and toolbar button, a-la Firestorm that users could use for their various HUDs and (hopefully) encourage them to only attach (via the toolbar button / floater) when required – thus assisting with reducing VRAM usage for users / eases resource loads when avatars move between simulators. This idea has been discussed at the Lab.
A further discussion on this involved avatar shapes and applying / managing parameters.
- Currently the body shape is a “container” for all body parameters (head shape, body size, leg length, torso dimensions, etc).
- This can make it hard when trying to carry out localised modifications to a part of a body (e.g. applying head parameters to a “preset” shape designed for a specific head brand).
- There have been suggestions to help improve this, including:
- Providing a means of exporting specific shape parameters for making new body shapes (see feature request BUG-216131).
- Manipulating the shape via LSL (not seen as necessarily user-friendly).
- Having some form of wearable that can be associated with specific body area parameters so that when used, would cause the currently worn body to adopt those parameters.
- Provide a means to support some kind of “mask list” that just governs which bones they affect. This would allow for quite arbitrary sub-sets (as defined by the shape creator), but is seen as not that user-friendly, and potentially introducing added complexity into shape manipulation.
- Some of these suggestions have a potential hit with increased UI complexity, but the idea of having explicit sub-set of shapes (e.g. one for the head, one form the upper body (or torso), etc.,) that have an obvious link to the sliders they would affect / be affected by, would seem to be the easiest for users to understand.
- To address the head issue noted above, the most direct solution would be to separate the head shape from the body.
Other Items in Brief
- Rider Linden is working on the texturing download and caching updates for the viewer, but these have run into merging problems with the current release viewer, so there is nothing available for public consumption on this work.
- Several creators have noted issues with Bakes on Mesh and the left arm / leg, Universal wearables, tattoos and skins (see this forum post as an example, together with this feedback thread post). No precise solution has been offered (there has been a suggestion for LL to provide a means to convert existing skins to universals for left arm and left leg, but it’s not clear how well this would work in practice).