Category: SL User Group Meetings

The following notes were taken from  my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, October 20th 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.

PBR: Materials and Reflections

• Please also see previous CCUG meeting summaries for further background on this project.
• Work is now entering a “public alpha” mode which will commence with the release of a formal project viewer, in order to put the viewer before a wider group of creators and obtain their input / feedback in addition to that gained during the “closed alpha” with those on the Discord channel.
  • This project viewer could be available in the next week(ish), subject to QA testing.
  • It is hoped this “alpha testing” will show that minimal changes to behaviour / functionality will be required, but it will allow LL time to gather broader stats on performance (particularly on hardware specs they have not bee able to test), and allow for additional tuning and optimisation.
  • LL are aware there are some performance regressions within the viewer (together with some issues with AMD drivers) that need to be addressed before it can proceed beyond project viewer status, but these are not seen as blockers to this wider testing, as they can be noted within their viewer release notes.
  • It is also noted that permissions will be “a little bit broken” to start with, and some edge case rendering cases may appear broken -but issues like this will be documented in the project viewer release notes.
  • Once these issues have been ironed out, it is anticipated that there will be no FPS loss when comparing the PBR Materials viewer to the current release viewer.
• Following this “open alpha”, the viewer will move to “beta mode” (presumably as it reached RC status), when the focus will be on bug fixes rather than adding / changing features.; as such, the project viewer phase is seen  as crucial in obtaining feedback encompassing concerns over things like file formats, functionality, concerns over changes to the rendering pipe, etc.

Reflection Probes

• LL is concerned that reflection probes may prove to be an Achilles Heel with the new capabilities, simply because the technique  in using them by the industry as a whole is somewhat counter-intuitive.
• The core issue is getting people’s heads around the idea that the “shiny thing” is not itself the probe; but the probe must be correctly set, including its influence volume.
  • Typical documentation on setting-up reflection probes, such as that provided by Unreal and Unity – both of which share the same concepts around the influence volume as the SL implementation (although the latter has fewer parameters), doesn’t always make for easy reading.
  • The influence volume is a particular issue for SL due to the use of the automatic probes which exist within a region, and which are unlikely to always be in the right place, so may need to be countered by manually-placed probes.
• One significant concern arising from this is that content will be sold with it own reflection probe which is precisely the wrong thing to do, as it could lead to dozens of probes in a single room, none of which have influence volumes that eat into viewer resources when a single probe for the room as a whole would achieve the same results.
  • A way around this would be to offer the means to disable the reflection probe as supplied within individual objects sold by creators.
  • However, this then begs the questions to what happens if said content is sold No Mod – blocking any ability to disable the associated reflection probe? Would it be sufficient to let market forces determine the success of such items?
• No definitive  solution for this has been determined – other than the need for full and proper education for creators (with documentation) – both of which assume creators will a) want to be educated; b) RTFM; and the meeting time drew to a close whilst this was still under discussion, so will likely be picked up at the next meeting.

Forward Rendering + Deprecating OpenGL 2.0

• As has been previously stated by LL (and covered in these CCUG summaries), a key change that the PBR work will bring to the viewer is the removal for the forward rendering pipe – otherwise know as “disabling ALM”.
  • To help with this, LL have implemented additional optimisation within the PBR viewer designed to help low-end systems perform better with ALM (Advanced Lighting Model) always on, and more optimisations are to be added to the viewer.
  • However, one of the areas of feedback the Lab would like to obtain during the “alpha testing” is how well low-end hardware they may not have been able to test functions when running the PBR viewer.
  • Obviously, removal of forward rendering  will mean the final end to invisiprims, which have for the last 10+ years required ALM to be turned off in order to mask other elements (e.g. system body parts, Linden Water, etc.).
• It is acknowledged that forward rendering currently offers better anti-aliasing than ALM, but a means to improve this under ALM is being looked at.
• The PBR Materials viewer will effectively see support for OpenGL 2 finally deprecated in the viewer, the minimum requirement being OpenGL 3 (Open GL 4 being required for reflection probes).
  • This thought to impact around 0.5% of all Windows / Linux users (stats still are collected for Linux, and many of those might be bots utilising older clients, with the majority of users – even those on elderly hardware – trending towards OpenGL 4 (which has been available for around a decade).
  • Given given basic GPU cards such as the Nvidia GTS 250 (introduced in 2009) and many laptops with integrated graphics can support at least OpenGL 3, it is hoped that even those still running OpenGL 2 will be able to updated to OpenGL 3 to avoid issues.
    • If you are concerned about your hardware supporting OpenGL 3, go to Help → About in your viewer, and you can check the OpenGL version you are running from there – most people will likely find they are running a version of OpenGL 4. Those on Mac OS systems might also use this tool to check.
  • The testing period will be sufficient enough for LL to determine whether they need to address the lack of OpenGL 2 support in future iterations of the viewer.

Alpha Modes

• With the PBR / Materials viewer, alphas are (as previously reported) move to linear colour space, which may cause problems for some pre-PBR content.
• This is not been an issue for those creators working within the close Discord channel group using pre-release viewers (particularly given some TPVs already use linear colour space), but LL expects to get fuller feedback on the move once the project viewer is ready for use on a much broader basis.
• If the move doesn’t work for pre-PBR content with alphas, the result might be that legacy content and PBR content will not alpha sort against each other, forcing an artificial sorting (e.g. sort rigged mesh alphas first, then sort non-rigged over).

In Brief

• The question was asked about SL supporting the Open Asset Import Library for mesh imports.
  • It was described as a “cool but bloated”, and “great when you want broad spectrum asset import and don’t really care about doing it super well for any particular format, not so great when you want to support one thing really well.”
  • As such, LL would rather focus on just support glTF mesh, and as a part o this, as the viewer progresses and glTF mesh import is added, support for importing COLLADA files will likely be discontinued in the official viewer, and creators will be pointed to a COLLADA-to-glTF converter.
• Terrain textures: LL is still looking at options for a future project to improve terrain textures.
  • One user-generated suggestion that has been accepted  for consideration is BUG-232769.
  • The Graphics Team are also looking at materials paint maps for terrain.
    • IF this approach were to be adapted it might comprise of a set of four materials per parcel, which could be painted onto the terrain “at some fidelity” (e.g. around 1/4 m or so), over the existing elevation-based texturing.
    • This would allow parcel owner to, or example, “paint” something like a cobblestone path through a part of their parcel or add high quality grass for  lawn, etc.
    • In particular, it could enable creators to provide “terrain ready” materials packs others can purchase and use in their parcels.
  • Note that currently, these are ideas. There is no actual project for revamping terrain textures in progress at the moment.
• It was reiterated that there is an internal move to update the Second Life minimum system requirements to reflect the versions of required APIs which must be run on client hardware rather than specifying specific hardware (CPU, GPU, memory, etc.) as is currently the case.
• The hoary old complaint of aviators having to fly through parcels with different EEP settings was again raised as an “issue”  (while not perfect, applying a preferred EEP setting to your avatar – Fixed Sky or Day Cycle – still seems the easiest option to overcome this rather than working to re-jig the viewer as a whole).
• A  reminder Local KVP / “Linkset Data” should be deployed to the simhost RC channels in week #43. I’ll have a post out on this during that week.
  • When testing this capability it is important to not that data committed to a linkset will not survive the move of the linkset to a simulator channel that does not have the necessary support for the capability; ergo, all testing must take place within the defined RC channels following the initial deployment.
  • There will be a special article on this capability in these pages once it has rolled to RC.

Next Meeting

• Thursday, November 3rd, 2022.

The following notes were taken from  my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, October 6th 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 Status

No changes through the week, leaving the current crop of official viewers as:

• Release viewer: version 6.6.4.575022 – hotfix for Crash at ~LLModalDialog() – promoted September 15 – no change.
• Release channel cohorts:
  • Maintenance 3 RC viewer, version 6.6.5.575257, September 23.
  • Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.5.575055 September 19.
• Project viewers:
  • Performance Floater / Auto-FPS project viewer, version 6.6.5.575378, October 4.
  • Puppetry project viewer, version 6.6.3.574545,  issued on August 30.
  • Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.

The Performance Floater / Auto-FPS project viewer includes a merge between the performance improvements from Firestorm integrated with the Lab’s auto-FPS capabilities.

PBR: Materials and Reflections

• Please also see previous CCUG meeting summaries for further background on this project.
• Test viewers continue to be made available to those on the Content Creation Discord channel. Requests to join that channel should be made in person at CCUG meetings. I am no longer able (at LL’s request) to furnish such information.
• Viewer notes:
  • In order to make it clear when someone is working with PBR materials assets, there is an additional option within the viewer’s Build floater which, when selected, will open a dedicated PBR Materials editor, rather than munging the editor controls into the Build floater.
  • This also allows options like Glow (not a part of the glTF specification) to be retained and potentially used as an overlay on PBR materials.
  • Render work has seen the removal of the stencil buffer. This means that those build tools relying on the stencil buffer will be changing or completely going away from the viewer (e.g. the show grid cross-section checkbox, which has been broken for some time).
• Work is in progress to integrate Linden Water into the new rendering pipe and support reflection probes.
  • This is also seeing some additional work on underwater refraction and on water reflections (e.g. no longer necessarily real-time reflections) so as to lighten the performance load.
  • The changes will mean Linden Water will look a little different as to how it looks at the moment.
• Additional scripting functionality has been added to the glTF test regions on Aditi to allow the configuring the reflection probes:
  • llSetPrimitiveParams([ PRIM_REFLECTION_PROBE, /*integer*/ enabled, /*float*/ ambiance, /*float*/ clip_distance, /*integer*/ flags ])
  • llGetPrimitiveParams([ PRIM_REFLECTION_PROBE ])
  • Link set variants of these functions should also work. These are the flags you can use in the last parameter:
    • PRIM_REFLECTION_PROBE_BOX` – Flag that determines if probe is a box or sphere.
    • PRIM_REFLECTION_PROBE_DYNAMIC` – Flag that determines if probe will cause avatars to be shown in its reflections
• Overall, it is felt:
  • That a plan / process is in place to future-proof the work for the additional of further glTF parameters down the road.
  • The test viewer is moving rapidly towards a point where a pubic Project viewer will debut.
• The aspirational goal for this work is to have the viewer fully released by the end of 2022. However, this is dependent upon feedback and reaction to some of the compromises made, once the viewer gets to project status as a wider audience.

In Brief

• Planar mirrors: if developed, these are seen as being similar to mirrors found in VRChat, etc., where they can reflect the local scene in detail, although at a performance impact.
  • There are potential ways to help reduce the impact – such as by limiting the distance at which a mirror is seen as “active” via the viewer (e.g. if you are within 5 metres, reflections are generated in the mirror; if you are beyond 5 metres from it, no reflections are generated) or by having mirrors touch-activated.
  • Ideally, such mirrors would have a specific function, and not merely another item of set dressing for a scene, and reflection probes will be used for generating environmental reflections (e.g. those seen on the shine of a car body or piece of silverware), rather than trying to make general object surfaces planar mirrors.
  • Note that any of this work would be for a future project, and is not part of the current PBR Materials + reflections work.
• Custom pivot points: this work is described as currently “stalled out” due to investigations into supporting full hierarchies and similar, which have proven more complicated that first thought – although the benefits of having a full hierarchy is seen as being a major benefit.
• LOD Clamping, etc. (please refer to my previous CCUG / TPVD summary for background on this: discussions are still in progress, and nothing definitive has been decided as yet. However, enforcing a hard clamp on setting LOD factors (including via the RenderVolumeLODFactor debug) is seen as a potential first step.
  • Were this to be done, TPVs would be given a suitable lead time to encourage creators to make suitable adjustments to their content.
  • This would apply only to in-world objects, although it is recognised avatars are a problem in their own right.
  • The latter have had some amelioration applied, as the Performance Improvement code ignores rigged attachment scaling, and only paying attention to the avatar bounding sphere, so a) LODs should be selected based on the size of the avatar; b) rigged attachments should change LOD depending you your camera distance from them.
  • The above does not apply to rigged meshes with no LODs – so it is possible the Lab will start auto-generating LODs for these in the future.
• Avatar imposters: SL currently leans heavily on the avatar imposter system to reduce the load of rendering avatars. It has been noted that a preferable route would be to generate mesh proxies for avatars at a distance. However, whilst discussed within the Lab, this is not  – yet – a project.

Next Meeting

• Thursday, October 20th, 2022.