2019 SL User Groups 20/2: Content Creation summary

Grauland; Inara Pey, March 2019, on FlickrGrauland – blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, May 16th 2019 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.

New Viewer Release Notes Pages

The Lab’s RC viewer releases / updates all have shiny new viewer release notes pages on the web. These move the notes away from the old wiki pages, and into a new format that provides:

  • The release notes can be accessed via a new home page, with links to recent SL viewer releases – that is, the current RC viewers.
  • The release notes for a specific viewer, with new icon links to its respective download versions (Windows 64 / 32-bit and Mac OS).
  • There are also links to support information: a new Repositories overview page; an explanation of the viewer version numbering system; a link to the Viewer Support Policy.
  • A significant change is that many of the Jira links in a release page reference the public Jira bug reports, rather than the Lab’s internal MAINT clones. This should make specific bugs addressed in an update more visible to interested users.
  • These pages can also (for the time being at least) be accessed from the existing Alternate Viewers wiki page, when clicking on the release notes link for a specific RC viewer.


The new format viewer release notes pages for SL release candidate viewers (using the EEP viewer as an example)

Environment Enhancement Project

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 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 not include certain atmospherics such as crepuscular rays (“God rays”).


Current Status

  • The EEP viewer updated to version on Thursday, May 16th. This update should include a number of bug fixes and shader updates that will hopefully improve things “considerably”.
  • Graham Linden continues to work on the remaining shader / graphics issues.

Animesh Follow-On

  • Vir continues to work on adding visual parameter support to allow shape adjustments to be made to Animesh.
  • This work has new reached a point of being able to store visual parameter information relating to Animesh objects, and to be able to send it to viewers.
  • The next stage of the work is to get to get the viewer to understand what it is supposed to do with these messages.
  • Vir hopes to have an internal prototype for this running in the next few days. If successful, this should pave the way towards a project viewer being made available down the road.
    • It will initially focus on using list-based LSL input to set individual shape parameters.
      • These will probably be throttled to prevent over-use (e.g. to prevent the capability being used as a high performance cost alternative to animation).
    • Once this is working that shapes can potentially be added for manipulation.
    • Obviously, this will require simulator updates to be able to support the LSL commands, as well as the updates required for the new message types, etc.

Animesh as NPCs

  • There has been a lot of forum discussion on using Animesh as non-player characters (NPCs).
  • A limitation here is that a decent-looking NPC, suitably clothed and ready for use can too often have a huge LI (into the 100s).
    • Part of the problem is that until Animesh,  is there was no real incentive to optimise rigged mesh, as being worn by an avatar, it never really had a “Land Impact” per se, and a lot of clothing has an “insane” triangle count (e.g. 21,000 for a tank top).
    • As Animesh calculations do try to allow  for the cost of rigged mesh, such high triangle counts are (simply put) converted in LI, driving up the LI for any Animesh character on which it is used.
  • It is hoped that as the ARCTan project comes to pass, it will offer some form of incentive that will encourage those clothing makers who may not consider optimisations to do so, which will help improve things for both Animesh using wearables and also help reduce some of the performance overhead overly complex avatars can cause.
  • Another alternative would be to (at some point) extend Bakes on Mesh to include Animesh objects, allowing them to be clothed using system layers.
  • In the meantime, the suggestions is that those wishing to create NPCs perhaps consider doing so entirely in Blender (or similar), and not rely on using clothing and attachments that might be available in-world as a means of clothing / equipping them.

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, but 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.


Current Status

  • There is a simulator change pending. This includes a means of accessing BOM UUIDs.
    • These were changed in the last back-end update as a result of underlying asset property issues. If there is BOM content using the old UUIDs, this will have to be updated.
    • The simulator update is intended to allow access to the texture UUIDs without having to do so numerically, as is currently the case. This should re-enable the ability to access them via their name abbreviations.
  • There is also a further Appearance Service change pending, designed to correctly handle tattoo layer with partial transparency (currently, if a tattoo with partial transparency is sent for baking via the new BOM channels without any underlying opaque layer, then the alphas are not correctly resolved).