Day: January 24, 2020

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, January 23rd 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.

Environment Enhancement Project

Project Summary

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.

Resources

• Project definition document.
• Project summary (this blog).
• Full EEP Documentation.

Current Status

• EEP is now viewed as a priority for release by the Lab.
• Work is continuing on the final bug fixes on the graphics side.
• Release is anticipated by LL to be within the next month or so.
• Those who use windlights for photography or within their regions are strongly urged to test the EEP RC viewer (last updated on January 9th, 2020, at the time of writing this summary).

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Current Status

• Now officially on hold pending other projects / work (notably major projects such as:
  • The cloud migration project.
  • Transitioning the viewer build tools to Visual Studio 2017 and to a recent version of Xcode (OS X)
  • Completing the migration of viewer repositories from Mercurial to Github.
• The status of the project will be reviewed as other work progresses, but it is unlikely there will be any further work on Muscadine in Q1 2020 (through until the end of March).

ARCTan

Project Summary

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).

Current Status

As of January 2020 ARCTan has effectively been split:

• Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations.
  • This work will also involve providing additional viewer UI so that people can better visibility and control to seeing complexity. For example:
    • Which attachments are taking the most rendering resources / rendering time.
    • Available options for improving local performance.
  • The aim is to provide users with information they can understand and make use of to assist in their local performance (e.g. “these red figures on your avatar attachment mean it is impacting YOUR system’s performance and slowing YOU down”, rather than jut pointing the finger elsewhere).
  • It is hoped that providing this information may also encourage creators produce better, more efficient avatar-related content.
• Work on providing a UI for in-world object rendering costs (LOD models, etc.) which might affect Land Impact has been deferred to a later tranche of project work.
• The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.

In Brief

LOD product: LL is considering taking future look at how level of detail is managed by Second Life.

• GLOD is now 15+ years old and there are potentially better ways to handle things.
• Automation of some LOD options might be seen as possible.
• It is recognised that avatar LODs are not the most efficient (e.g. 2X bounding box LODs), but how they might be better managed is seen as a complex issue (e.g. avoiding situations where the viewer uses one LOD for an avatar’s body and another for the avatar’s head, so the head looks deformed compared to the body, or vice-versa).

Content Tools: interest was also expressed in hearing about the preferred tools used by creators and what creators might like to see by way of better support for said tools / file formats related to said tools and in general. The question was not asked with any specific project in mind, but simply to gain a broader understanding of what content creators use, etc.

The tools mentioned by creators at the meeting include:

• Clothing: Marvelous Designer, Blender, Maya, Substance Painter, 3D Coat.
• Other tools mentioned: Topogun, Zbrush.

PBR was also mentioned, although this would require a large-scale overall of SL’s rendering engine.

Requests were also made for:

• Better handling of sub-meshes during the upload process (e.g. consistent linking between different uploads of the same multi-part mesh).
• Ability for mesh instance recognition (e.g. if a specific sub-mesh is repeatedly used in a build, then it should be uploaded only one and instanced across the build) – or at least the viewer to be able t instance sub-mesh elements when rendering.