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, May 7th 2020 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are are available on the Content Creation User Group wiki page.

SL Viewer

No further updates this week, leaving the current crop of in-flight viewers as:

• Current Release version  version 6.4.1.540593, dated April 27th, promoted May 4th. Formerly the Zirbenz Maintenance RC viewer – NEW.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • CEF Special RC viewer, version 6.4.1.541204, April 30.
  • Camera Presets RC viewer, version 6.3.9.538729 March 25.
  • Love Me Render RC viewer, version 6.3.9.538760, March 25.
• Project viewers:
  • 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.
  • Legacy Profiles viewer, version 6.3.2.530836, September 17, 2019. Covers the re-integration of Viewer Profiles.
  • 360 Snapshot project viewer, version 6.2.4.529111, July 16, 2019.

CEF Viewer

The “special release” CEF RC viewer, version 6.4.1.541204, does contain the anticipated codec, etc., updates. However, it is classified as a “special” release at this point in time, as it includes some “short cuts” taken in the build process in order to get it out as a proof-of-concept for the Adult Swim event.

The recommendation is that TPVs should not adopt the code from this particular build, but to wait until a more formalised RC release of the CEF updates is made.

See: Exclusive Adult Swim Second Life Event: Introducing Live Video Streaming in SL (Linden Lab) and Adult Swim special streaming event in Second Life (this blog).

OpenGL Replacement

As has been noted in this blog and elsewhere, Apple is deprecating OpenGL. This has raised questions over the last several months about the future of graphic support in SL for OS X.

Currently, one of the routes under consideration is to undertake a complete switch-over (Windows and OS X) from OpenGL to using Vulkan.

• This is not a final decision, it is just one option under consideration, albeit one that is getting a good degree of thought.
• Numerous pros and cons have been identified with such a switch. However, more analysis is required before a decision is made – e.g. overall impact on shaders, etc.
• Even with any shift there are crucial questions to be asked, including how might it impact users on older, lower-spec systems. To help determine this, an upcoming RC viewer from the Lab will have some additional data collection code that will check to see if systems have / can support Vulkan.
• Vulkan could potentially streamline some of the alpha sorting issues seen with OpenGL, and might also provide some general performance improvements.
• There is a temptation when running a major graphics overhaul to try to include additional work as well, leading to drawn-out projects (a-la EEP). To avoid this, were a move to Vulkan to be made, LL will likely go for a focused implementation of Vulkan support, with broader graphics / shader work positioned as future follow-on work.

Advanced Lighting Model

With regards to any graphics system update, it is possible that the requirement to run with the viewer’s Advanced Lighting Model (ALM) always enabled might become universal. LL are aware that many people run the viewer with ALM disabled, and so are curious as to how much impact any decision to make it universal might have.

Part of the problem here is that people disable ALM for a variety of reasons. For example:

• Those on metered / slow connections may disable it, to avoid having the additional load of downloading materials information (normal and specular maps).
• Some disable ALM in the (not always accurate) belief that it carries a heavy performance hit, which is not necessarily true (e.g. enabling ALM on its own generally doesn’t place too much overhead on a system, but enabling ALM and shadows rendering does – so the trick is to turn of shadows via their own drop-down, rather than disabling ALM entirely).

In brief

• The viewer’s bandwidth usage was raised  – notably the 3000 Kbps upper limit, and whether this was still valid in the era of fast connections people can access. Whether the limit is still valid or not is unclear (particularly how higher limits might stress the servers in terms of requests for information), however, it is seen as something the Lab could potentially look at.
• Caching viewer: the upcoming viewer with updates to the cache is primarily focused on the VFS cache. If this is successful, it is possible the texture cache may be folded into the same structure.
• Official Linux viewer: not news. The idea of the Lab providing (with third-party contribution support) a core Debian package & leaving the libraries to TPVs / self-compilers to determine based on the flavour of Linux they want to use is essentially at a standstill due to lack of resources.
• Next meeting: Thursday, May 21, 13:00 SLT.

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, April 30th 2020 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are are available on the Content Creation User Group wiki page.

Unfortunately, my recording software crashed some 2/3rds of the way through the meeting (and I was afk, so didn’t spot it), so I missed recording around the last 15-20 minutes of the discussions.

Jelly Dolls / Avatar Rendering

• As noted in my week #16 CCUG summary, Vir has been looking at the jelly doll rendering code, which is not well optimised (e.g. it still draws rigged attachments) and it handles some operations inconsistently (e.g.setting an avatar to never render is actually more processing expensive that simply leaving it jelly dolled).
• One of the things Vir has been experimenting with is displaying Jelly Dolls as monochrome system avatars sans rigged mesh and attachments.
• An issue with this approach  is that non-human avatars use animations to reposition bones and joints, when can result in the system avatar looking very weird, even in monochrome. Vir has therefore been focused on finding a way to pause the animations when a non-human avatar is jelly dolled, and just running something like one or two of the default animations from the system locomotion graph.

In brief

BUG-228564 -Feature Request: New object property “Intangible”

This is possibly a duplicate request (those listed on the Jira are for different functionality, so not true duplicated), requesting an option to make certain in-world objects “invisible” to the viewer’s ray casting, so they they do not react to mouse clicks, but the objects beyond can.

Such a capability would be useful where semi-transparent objects are used to imitate sun beams or fog or rain, etc., otherwise block the ability to click on objects (e.g. seats, etc.), they surround / are in front of. However, such a change would require both viewer-side and back-end changes so, even if the Jira isn’t a duplicate of an existing request and is something LL accept, it is unlikely to be worked on until after the cloud uplift work has been completely, simply because it will require the introduction of a new object property on the simulator side / back end.

Education / Awareness

Much of the meeting was a general discussion on how to better inform / educate creators and users on the benefits of optimised content, and exactly what can impact things like perceived SL performance.

The major crux of this discussion came down to providing better documentation / information that both creators and users could be pointed to (e.g. more detailed information on mesh creation, including topics such as LOD generation, tri counts, use of maps, etc. for the former; clearly-worded instructions and benefits of using tools like ARC, etc., in the viewer to improve performance, etc., for the latter).

• It was pointed out that LL have limited resources for the production of comprehensive best practices, and that perhaps the best sources for these might be creators themselves.
• As the SL wiki is currently closed to general editing, those who have a specific desire to edit wiki pages / build articles can request access by sending an e-mail outlining who they are and why they want access to: letmein-at-lindenlab.com.