The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, June 2nd 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
- A new Maintenance RC viewer – Maintenance N, code-named Nomayo – version 6.6.1.572179 – was issued on June 1st. The viewer should offer improvements on media playback of web content, etc.
The rest of the official viewers remain as:
- Release viewer: version 6.6.0.571939 – formerly the Performance Improvements viewer, dated May 25th – NEW.
- Release channel cohorts:
- Makgeolli Maintenance RC viewer (Maintenance M) viewer, version 6.5.6.571575, May 12.
- 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.
Reflection Probes
Additional information available within my week #20 CCUG meeting summary.
- A reflection probe will be a sphere or cube (mesh, prim or sculpt) set within a scene with specific properties allowing it to create a cube map of all objects within its bounding box. Anything within that bounding box with a “reflective” (shiny) surface (with the possible exception of worn attachments) will then offer “reflections” based on that cube map.
- Cube maps for probes are a purely viewer-side artefact, and are updated approx. once every 30 seconds at 60 fps, although this will “get smarter” in the future and be based on actual probe location (e.g. in or out of the current field of view, etc.).
- So, think of probes as mapping where reflections should be coming from in a scene, not as a tool for deciding which object should be reflecting things.
- The viewer will hopefully be able to handle up to 256 probes at any one time (the number of probes in a region can be unlimited), each with a (current) maximum effective draw distance of 64 m.
- Probes will:
- Be detected by the viewer on load, much like lights already are (reflection probes use a lot of the code originally developed for light state management), with revisions to prevent issues associated with lighting such as flickering.
- Have an influence volume, an ambience setting (which overrides the environment ambience) and a “near clip” parameter to help control what is rendered into the cube map (e.g. so items close to the centre of the probe and which might otherwise dominate any generated reflections, are not rendered into the cube map).
- Require “PBR enabled”, and when this is set, legacy objects using glossiness and / or environment shine will render the reflection generated by a cube map respectively in accordance with the degree of glossiness / the sky environment, as well as any objects using the upcoming PBR materials.
- There are a lot of nuances with the above bullet point such that legacy content won’t simply “work” with reflection probes, some degree of adjustment on object glossiness / shine might be required.
- Work independently of LOD.
- Probes will not be designed for use as attachments.
In Brief
- Custom pivot point work: currently awaiting simulator updates & will require viewer-side changes; the focus is slowly moving towards trying to move the latter part of the work forward “in the not too distant future”.
- It was noted that the mesh optimiser (as in the current release viewer) still has issues that need to be addressed,
- One such issue is when the LOD generator is implicitly asked to simplify a model, and it cannot hit a target without destroying UV seams, it will destroy the UV seams (whereas GLOD will delete triangles, leaving holes in models). This appears to be happening on models with a lot of UV islands, resulting in texels becoming visible when they should never be drawn.
- LL acknowledges that neither the optimiser issue nor the GLOD issue are ideal.
- Issues with the mesh uploader are requested via Jira with objects included, if possible.
- In response to a question, LL currently have no plans to alter the LI calculations for Animesh, however, with the performance improvements (and given part of the LI “penalty” was to compensate for the performance hit of animating Animesh characters), there is a suggestion it should perhaps be re-visited, particularly given most at the meeting with an opinion felt the 15LI penalty was a “blocker” to developing Animesh content.
- The above points led to a general discussion on LODs, decimation, Land Impact based on size, the ARCTan project (still something LL would “like to get back to”), the impacts of draw calls over poly counts, etc., but with no actionable points raised.
- There is a fork in the texture rendering pipeline underdevelopment that should, once available, ensure that only the required texture resolution is loaded when it is required (e.g. so the tiny buttons and the little broach and the earring etc., on an avatar won’t all be displayed at 1024×1024 all the time, but the system will only ever download at use a 128×128 version of the textures used).
- Work is also in progress to ensure the official viewer uses all available video memory. This will eventually see the VRAM slider in Preferences → Graphics vanish.
- Note that this is available video memory – not necessarily the total on your system; obviously, running SL and multiple browser tabs and other windows will impact how much memory the viewer can actually access, leading to the potential of textures being uploaded.
Next Meeting
- Thursday June 16th, 2022.
Inara Pey: Living in a Modemworld 