The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, June 30th 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.
This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.
Official Viewers Update
One Wednesday, June 29th, The Maintenance M(akgeolli) RC viewer, version 6.6.1.572458 was promoted to de facto release status.
No changes to the rest of the official viewers through until Thursday, June 30th, leaving them as:
- Release channel cohorts:
- Nomayo Maintenance RC (Maintenance N) viewer, version 6.6.1.572179, June 1.
- Project viewers:
- Performance Floater project viewer, version 6.5.4.571296, May 10.
- Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
- Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
- Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.
Materials and PBR Work
Please also see previous CCUG meeting summaries for further background on this project.
Outline of Work
- Work on an implementation of reflection probes which can be used both with PDR shading and with legacy content.
- The overall aim of this work is to provide a means to support more physically accurate reflections in SL than can be currently generated (seen as a requirement for PBR support).
- It applies to both PBR generated content, once available, and to legacy content.
- Creating a materials type with an associated inventory asset. This will initially comprise the ability to copy a texture entry (with its specific parameters) to inventory, to be followed by initial work to work implement a PBR graphics pipe in the viewer.
- Normals will likely be MikkTSpace, as per the glTF specification, but work needs to be done to see if supporting this could lead to clashes with the current normal maps rendering. This does mean that current Normal maps will not work on PBR materials.
- The initially supported capabilities are:
- RGB albedo + transparency.
- RGB Occlusion/Roughness/Metalness: R = occlusion, G = roughness; Blue = metalness.
- RGB emissive.
- RGB normal (- alpha).
- Double-sized supported (disables backface calling before issuing the draw call).
- Two-sided lighting (so if the back of a triangle is visible, it flips the normal around).
- In addition:
- There will be an ability to “preview” materials on an item within your own viewer (similar in nature to Local Textures) before actually uploading them.
- LSL support is still being defined, but should at least allow individual texture UUIDs to be replaced under script control.
- The approach being taken is to may the system extensible so that further capabilities / plug-ins / options can be added with relative ease in the future.
- However, Displacement maps will not initially be supported due to not being defined in the core of glTF 2.0; nor will any extensions that are not adopted into the core glTF standard (either glTF 2.0 or 3.0).
Materials Progress
- The focus has been on under-the-hood work to allow drag-and-drop of materials assets onto objects / object faces (download demonstration mp4 here).
- There is further work required on the back-end inventory services and asset store, and on some of the shaders in the viewer, before any of this work is ready for public testing on Aditi.
ALM Proposal / Work – Recap
At the #week #23 TPVD Developer Meeting (notes here), it was indicated that LL are “leaning” towards removal of the non-Advanced Lighting Model (ALM) (aka “forward rendering”) rendering path from the viewer, leaving just ALM rendering (aka deferred rendering”).
- Were this to be done, it would only be done if it can be shown that this does not adversely impact performance (e.g. ALM runs roughly as well as non-ALM for those using the latter) on the broad cross-section of hardware most commonly operated by SL users.
- The work will include:
- A slider to manage the number of rendered local lights to lightening the load of rendering illumination on lower specification systems.
- A “data saving mode” primarily intended to help those on metered connections by culling the download of additional materials / PBR maps and potentially downloading lower resolution textures mips, all of which will reduce the data passing over their connections. However, it will result in a much poorer visual experience once the PBR work has been implemented, and the hope is the mode will only be used in the minority of cases.
- Given the ongoing work to support PBR and a more rounded set of materials, moving to deferred (ALM) rendering without fallbacks to non-ALM rendering – providing, again, the caveats noted above can be met / implemented – will in general help ensure a more reliable / consistent viewing experience across a broad range of hardware.
In Brief
- The work to make full use of available video memory on a client computer is being put out to a hardware compatibility lab to help ensure the code changes are doing what they are supposed to be doing on a wide variety of hardware. These tests will also look at the impact of running the viewer with ALM active all the time across all hardware configurations.
- On Animation:
- The Puppeteering project highlighted at Grumpity and Mojo Linden’s Meet the Lindens session came in for criticism, but it was suggested people give the system a chance to reach a more advanced stage before judging, as the video presented in the talk does not do the work justice.
- Vir indicated that while there is an understanding at the Lab that people would like the animation system overhauled:
- Such a project currently isn’t on the roadmap
- However, consideration is being given to allowing an on-the-fly adjustment of animation priorities.
- Requests for additional animation work were requested via Feature Request Jira.
- Runitai Linden suggested that as glTF supports animations it might – in the future – be a possible option for animation improvements. However, note that moving in this direction is also not part of the current roadmap.
Next Meeting
- Thursday July 7th, 2022.
Inara Pey: Living in a Modemworld 
As a creator, this is very welcomed. But I feel there are a few things missing.
For example, while we won’t have displacement maps (which it’s okay), having Parallax Occlusion Mapping would be pretty handy for some things and we could place the height map right on the normals map alpha channel.
But more importantly, we need new methods of alpha display. While alpha masking it’s very handy, having alpha dithering methods for masking would help to blend between two masked objects getting a similar feeling to alpha blending at a lower performance cost. This has been a standard for longer than 15 years for most game engines, we shouldn’t fall behind now. Additionally, being able to use a separate alpha channel it’s a must. With extra capabilities to animate separately alpha channels (or any other material channel) independently from the albedo would result in great possibilities to create better effects and animations which is something lacking as of right now.
And last but not least, is the inclusion of detail normal (or bump) maps. These are small textures, often of like 128 or 256 pixels that are seamless and you use with several repeats blending with the main normal map. For example, you could bake the wrinkles of a high poly jacket into the normal map of a low poly jacket to retrieve details and use the detail normal map with a fabric texture used with several repetitions to get the look of real fabric, especially during close ups. This could help creators to reduce the number of textures that they use on a single item as all the small details could be retrieved with higher quality than it is possible now but at a fraction of the cost. One single 1024 normal map and a 128 detail normal map would give sharper details than using 4 or more textures for a single item with the advantage of not filling the whole video memory with a single worn item.
LikeLike