2018 SL UG updates #12/2: CCUG summary

A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 22nd, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

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 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. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures on avatar meshes.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

It is important to note that this project is still in its preliminary stages. Any release of a project viewer (see below) doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Project Viewer

  • QA testing revealed a number of bugs which need to be addressed before the project viewer reaches public consumption.

EEP and Atmospheric Shaders Work

Environment Enhancement Project (EEP) Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current status: Rider Linden is working on some internal fixes for EEP which should hopefully move it closer to public visibility, and there is some more infrastructure work to be done.

Atmospheric Shaders Work

A project to revamp the viewer’s atmospheric shaders and rendering.

Current status: Graham Linden indicated “good stuff” is in the works, but nothing he can publicly report on as yet.

Animesh Project

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.
  • Will not initially include the notion of a body shape (see below).


Current Progress

Vir continues to work on performance profiles, and is “pretty close” to having something for Land Impact, with a formula under evacuation. Among the changes, this formula calculates scaling differently, and Vir notes there are a number of corner cases which need to be dealt with. The tri count cap will also be finalised alongside the updated LI formula.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

Vir Linden agreed that this is a problem, and that forcing abnormally large avatar bounding boxes is undesirable. In some places, the Lab tries to use the rigged mesh wireframe as the basis for the bounding box, which is seen as a little more robust as it is looking directly at the triangle data, rather than working off of the avatar itself – and this is the approach being considered with Animesh to avoid similar issues with Animesh rigged mesh failing to correctly LOD in the viewer – however, so believe the use of such static data is “meaningless”.

JIRA “Accepted” Status

The “Accepted” status on the JIRA still causes some confusion. In brief:

  • For BUG reports, Accepted tends to mean the Lab have imported the report for evaluation / agree to there being a bug and will look to fix the issue. When it is addressed is dependent on a number of factors (e.g. severity of the issue).
  • For feature requests, Accepted means the Lab is sufficiently interested in the idea to want to track it. It does not mean the idea will be implemented, either in whole or in part. Whether it is implemented in whole or in part again depends on a number of factors (how it sits within the current workflow, whether or not it is related to work being carried out and can be added to it; whether it is something which might be implemented alongside of upcoming work; whether it is better to hold off until it and other ideas like it can be implemented together as a project, etc.).

Return of Last Names

The last portion of the meeting focused on the recent blog post from Linden Lab indicating Last Names would be returning to Second Life. Given the level of interest in this project, I’ve written a separate update on this section of the discussion. See:  The return of Second Life Last Names – update with audio.

In Brief

  • Rigged / static meshes using transparencies (blended or masked) tend to cast an incorrect shadow

    Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette). Graham Linden indicated that this is something the Lab plans to fix, but the work has yet to be scheduled.

  • Switching mesh asset on the same prim root: this used to be supported via script, but was removed due to people using it to create flipbook style animations which could adversely affect performance. It’s been suggested that it could offer an alternative to performance-impacting alpha swapping on meshes; however, the Lab’s view is that while alpha swapping is performance impacting, switching entire mesh assets would still be more of a performance hit, as the latter requires all of the geometry data associated with the mesh to be rebuilt every time.

One thought on “2018 SL UG updates #12/2: CCUG summary

  1. That bounding-box problem looks nasty. I have already seen those oversized heads when rezzing is slow, and adding those extra invisible prims is just stupid. It’s good to know the Avatar bounding box is used as the baseline for the attachments, I’d noticed it when Firestorm introduced its LOD info display in the Object Editor, but when I asked I was told you couldn’t rely on it. Now it looks like there’s a simple rule, which is being abused by some content creators, and does a lot to explain those avatars with huge Complexity numbers. Use the largest bounding box for the set of components. Usually that’s the avatar, and then somebody pulls an antisocial stunt like this.

    There’s an argument for revoking Mesh Import Permission for the creators who have done this stunt with the extra prims.


Comments are closed.