The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, January 3rd, 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.
Due to the end-of-year / new year break, at the time of writing, the official viewer pipelines remain unchanged from 2018 week #51:
- Current Release version 22.214.171.1242263, dated December 5, promoted December 13. Formerly the Spotykach Maintenance RC viewer.
- Release channel cohorts:
- Estate Access Management (EAM) RC viewer, version 126.96.36.1992564, December 19.
- BugSplat RC viewer, version 188.8.131.522614, December 18. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
- Love Me Render RC viewer, version 184.108.40.2062531, December 18.
- Project viewers:
- Linux Spur viewer, version 220.127.116.119906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
- Obsolete platform viewer, version 18.104.22.1680847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
There was a back-end update to SL voice on Wednesday, December 26th, 2018.
Hover Height / Vertical Positioning Issue
Ever since server release 18#22.214.171.1241081 was deployed at the end of October / beginning of November 2018, there have been reports of a hover height / positioning issue for full mesh avatars of less than “normal” height. This can leave such avatars floating 0.2 to 0.3 metres off the ground if non-height related changes are made after hover height has been set (BUG-225893).
Anchor Linden has been investigating this, and the current thinking is that it is related to a change made to the Appearance / Bake Service, rather than to a simulator update. However, it is still proving difficult to reproduce 100% of the time, so investigations are still in progress.
- The number of Animesh items on the Marketplace is increasing, and “Animesh” is now sufficiently recognised as a search term that using it will turn up relevant results, as well as using the Animated Objects category as a means of filtering.
- The SL feature roadmap for 2019 is still being discussed, but Vir hopes to be able to put more work into Animesh in order to make Animesh characters easier to customise (e.g. applying a body shape). However, this work will not be appearing on the immediate horizon.
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 which include the ability to use custom Sun, Moon and cloud textures. These can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
The project also includes a new set of render shaders to support atmospheric effects such as rainbows, crepuscular rays (“God rays”), better horizon haze and fogging (but will not include rain / snow).
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- Project Viewer – via Alternate Viewers wiki page.
- EEP testing region: secondlife://Aditi/secondlife/EEPTesting/247/44/23
- EEP Feedback forum thread.
- EEP sneak peeks forum thread.
- EEP Jira filter.
- Rider Linden is working on updates to the EEP settings tabs for both the Region / Estate floater and the About Land floater (parcel-level controls). These should be appearing in an EEP viewer update “soon”TM.
- The viewer will hopefully be moving to RC status in the near future. In the meantime, it is hoped that the back-end will be expanded to a to least one further RC soonTM as well.
- By the time the back-end role-out occurs, support for crepuscular rays should also be available through the viewer.
ARCTan is the code-name for the project to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both, which it is hoped will also help correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh). This project has been on a slow burn through 2018, but is due to resume in 2019 – although when is still to be determined.
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, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.
This work 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.
- As Anchor Linden is still involved in determining and trying to fix the hover height / vertical positioning issue for smaller avatars, BoM is still pretty much on hold.
- Viewer contributions: The Lab have received contributions from the Firestorm Team:
- Beq Janus has contributed her improvements to the mesh uploader (see my Firestorm 6.0.1 review).
- Nicky Dasmijn has contributed improvements to the viewer’s search capabilities on preferences and settings.
- Hopefully, these updates will be appearing in a Maintenance RC viewer at some point in the future.
- SL 2019 Roadmap: It’s been acknowledged that 2019 is going to be something of a balancing act for Second Life between new features implementation and also all the infrastructure work involved in the transition to the cloud.
- Baked Mesh “seams” issue: there have been reports of issues with “seam” appearing on meshes using baked textures. This appears to go back to a normal maps related issue (BUG-5975). Within the Lab, it had been thought the problem was the result of the used normal maps being discontinuous, rather than a shader issue. Further investigation will require further examples with “non-broken” normals in order to determine if it is a shader bug.