The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, February 21st, 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.
- Vir has been assisting with the clean-up following the inventory issues users experienced over the weekend of February 9th /10th. These apparently impacted a number of SL’s back-end services and are still being worked on.
- A planned change for Animesh designed to throttle the number of complexity updates for avatars and Animesh objects actually never made it into a release viewer. This will now likely get pulled into the (non-public) viewer repository where Vir is experimenting with Animesh follow-on work.
- The lack of this throttle has meant that some TPVs have implemented their own throttles on these complexity updates to reduce their potential impact.
- Will there be attachment points for Animesh? Currently unknown. Vir will be investigating options; attachments to Animesh won’t function in quite the same way as avatar attachments, so the optimal mechanism needs to be determined, if possible.
- One option might be to have attachments behave as part of the Animesh linkset, but have a flag set for them that forces them to be displayed in the required location when used.
- This doesn’t allow the full range of capabilities seen with avatar attachments, but it would allow the attachment to be made, and the Animesh complexity calculations to be properly updated.
Environment Enhancement Project
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”).
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- Project Viewer – via Alternate Viewers wiki page.
- EEP Feedback forum thread.
- EEP sneak peeks forum thread.
- EEP Jira filter.
- It is hoped that the current project viewer version of the EEP viewer (version 220.127.116.114476, dated Tuesday, February 19th) will be the last before EEP moves to viewer release candidate status.
- There are still a couple of bugs to be hunted down which may impact the promotion.
- Rider hopes to see the viewer go to RC status before the sider code for EEP moves beyond the LeTigre and BlueSteel simulator RC channels, to allow more widespread testing of the viewer once it is in RC without the risk of bugs impacting other simulator updates.
- People using the EEP viewer (project or RC, once it has been promoted) should see no difference in behaviour when using it on non-EEP regions.
Bakes On Mesh
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.
- Bakes on Mesh knowledge base article.
- Bakes on Mesh forum thread.
- Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).
- A further appearance server update is required to fix the “black skirt” issue that can result in an avatar appearing to wear a long, jet black “skirt” when seen in the BoM viewer.
Multiple Texture Uploads
As noted in my previous Content Creation UG meeting notes, there was some discussion on textures and uploads, during which, Beq Janus suggested making it possible for users to select more than one image resolution when uploading textures to the viewer.
- The idea here is to encourage people to experiment and see how the different resolutions work on surfaces, rather than always automatically opting for the highest resolution (e.g. 1024×1024), which might not always be required.
- A feature request was subsequently submitted for this – see BUG-226352 – which has been accepted.
- It’s not clear if / when this might be implemented, although it is acknowledged as being “a nice thing to have” (particularly given the different resolution mipmaps are generated at upload anyway, but only the selected resolution is made available).
- It is not clear how much would be involved in the necessary back-end updates required to support the idea.
- Also, the usual caveat: “accepted” means the idea is something the Lab is interested in tracking / possibly investigating. It doesn’t automatically mean a feature request will be implemented.