The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, February 4th 2021 at 13:00 SLT. These meetings are chaired by Vir Linden, with dates available via the SL Public Calendar.
The venue for meetings is the Hippotropolis camp fire.
Due to Vir having to depart the meeting early, the majority of the meeting focused on viewer rendering.
SL Viewer
There have been no updates since the promotion of the Dawa Maintenance viewer to de facto release status earlier in the week. the viewer pipelines therefore remain as:
- Current release viewer Dawa Maintenance RC Viewer, version 6.4.12.555248, dated January 25, 2021, promoted February 1st, 2021 – NEW.
- Release channel cohorts:
- Project Jelly viewer (Jellydoll updates), version 6.4.12.553798, January 7, 2021.
- Custom Key Mappings project viewer, version 6.4.12.553437, January 7, 2021.
- Project viewers:
- Love Me Render (LMR) 5 project viewer, version 6.4.12.553511, issued on January 7, 2021.
- Simple Cache project viewer, version 6.4.11.551403, November 12.
- Legacy Profiles viewer, version 6.4.11.550519, October 26.
- Copy / Paste viewer, version 6.3.5.533365, December 9, 2019.
- Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, November 22, 2019.
- 360 Snapshot project viewer, version 6.2.4.529111, July 16, 2019.
Viewer Rendering
Love Me Render Viewer
The Graphics team are getting close to an RC release of the Love Me Render 5 (LMR 5) viewer (project viewer version 6.4.12.553511 at the time of writing).
- The one remaining issue they addressing with it is the matter of incorrect vertex attribute normals (not normal maps themselves) being rendered with Debug Normals enabled in the viewer (see BUG-228952 “Mesh Debug Normals display incorrectly. Normal Maps on scaled objects appear to use incorrect mesh normals for shading calcs”).
- This appears to occur with models created in Maya with normals applied, but which uses non-uniform scaling.
- The fix involves updates to both the Debug Normals code and the affected shader code.
- The focus of LMR 5 is EEP fixes, apparently including the inverted rainbow issue, going on comments made (although currently that isn’t listed in the release notes), together with more general fixes related to things like specularity renderings, etc. It also includes a number of TPV contributions that fix assorted rendering issues.
- It is hoped an RC version of the viewer will be available in the next week or two, with the aim of moving it to release status as rapidly as possible.
Outside of any specific rendering work going on for LMR 5 (or which my be directed into the next Love Me Render viewer, aka LMR 6 (such as BUG-5975 and BUG-229462, which might be investigated as part of LMR 6 work), it was indicated the Graphics Team would like to work on the environment map, if only to reduce the performance load it currently places on rendering.
Rendering API Replacement
No specific updates at present on the replacement of OpenGL as the rendering API.However, it was indicated that consideration is still being given to supporting more than one rendering capability by means of some form of back-end “tool kit” or library. There are a number of reasons for this:
- As indicated in my previous CCUG meeting summary, there appears to be a substantial portion of Windows users accessing Second Life on hardware that cannot support more recent APIs like Vulkan (which had been the preferred choice).
- Whilst they are set to deprecate OpenGL at some point in the future (prompting the need for the switch away from OpenGL), Apple actually don’t provide native support for Vulkan, thus prompting the need for a second alternative (such as – perhaps – Apple’s own Metal API).
- Therefore, the use of an intermediary tool box / library approach would, whilst adding a layer of complexity, allow Linden Lab to potentially leverage more than one rendering API to support a wider range of user hardware.
Looking to Possible Future Options
Some thought is being given to rendering capabilities beyond the replacement of OpenGL, such as physically based rendering (PBR).
- It is important to note that none of these are currently being considered for adoption at this point in time; they are simply on the Graphics Team’s wish list of things they would like to look at.
- As such, if something like PBR were to be adopted, it would not be until some time after the need to replace OpenGL has been addressed, which itself is liable to be a long-term piece of work.
- In terms of PBR in particular, it was noted that in practical terms, it would only be of value on objects that utilise PBR materials.
- This likely means that if it were implemented, it would be a opt-in capability: creators would set a flag against content they are importing to indicate it uses PBR, and thus use the required shaders.
- Such an approach would prevent any “breakage” of existing content (which would effectively continue to be rendered “as is”, and in turn allows creators to determine which of their products they might like to update to / replace with models utilising PBR.
- Outside of PBR, it was suggested that High-dynamic-range (HDR) rendering might be something the Graphics Team would like to look at at some point in the future.
Mesh File Formats
Again, not a project under active development or something that will come about in the near future, but the Graphics team are also giving thought to potential mesh model file format support outside of the current .DAE.
- In the past, users have expressed a desire for .FBX support; the problem here is potentially that whilst widely used and accepted as a “standard”, it is pretty much close-source by Autodesk.
- The open-source Graphics Language Transmission Format (gITF) has been suggested by some as an alternative, particularly given it is already supported by Blender as via a plug-in option, and the Graphics Team have indicated they will have a look at this as and when time allows.
Date of Next Meeting
- Thursday, February 18th, 2021.
Inara Pey: Living in a Modemworld 