Day: July 2, 2021

2021 CCUG meeting week #26 summary

Posted on by Inara Pey
Butterfly Conservatory, April 2021 – blog post

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, July 1st, 2021. These meetings are chaired by Vir Linden, with dates available via the SL Public Calendar and the venue for the CCUG is the Hippotropolis camp fire.

SL Viewer

There have been no updates for the any of the official viewer versions, leaving the pipelines as follows:

General Viewer Notes

  • The Fernet Maintenance RC viewer is next in line for promotion.
  • LMR-6 continues to be developed.
  • Voice update: this wasn’t an update the SLplugin.exe API, but was a change to the automatic voice level detector. This was causing a lot of the cut-out issues with voice, as it is overly sensitive to voice cadence when speaking, causing the temporary drop-outs, so by default the viewer no longer uses it at all.

ARCTan

Summary: An attempt to re-evaluate both avatar rendering costs and the cost of in-world scene rendering, with the current focus on avatar rendering cost / impact, and in-world scene rendering / LI to be tackled at some point in the future.

  • Work is continuing on the new performance floater. This pulls together information from various menus / debugs to display useable information on avatars / attachments that are heavy in rendering cost, and what can be done.
  • This work is currently separate to the work on revising that actual formulas used for calculating avatar complexity. As the viewer has yet to appear, it’s not clear if the updated avatar complexity calculations will be folded-in to the viewer before it reaches eventual release status, or if they will follow after. Currently, Vir hopes to get back to working on the calculations “some time in the new few weeks”.

Graphics Update Discussion

  • There have been numerous questions about LL switching the viewer’s renderer to a commercial engine such as Unreal Engine or Unity.
  • As Grumpity Linden indicated during her SL18B Meet the Lindens session, there are currently no plans to do so. This is not to say it would never happen – although doing so would be a very significant project.
  • One major argument against turning to a commercial engine is that users have very strong views on existing content and how it should be rendered, and can get very upset when things change – and they would change significantly were the viewer to be re-built around a new rendering engine.
  • Other factors weighing against commercial engines include:
    • They are not currently considered as being particularly good at dealing with dynamic content.
    • They could be restrictive in terms of the hardware people can use to access SL.
    • The basic work to make a switch-over would likely require around 18-24 months of development, which would curtail other viewer work, simply because it would be a significant viewer re-build.
  • Currently, the major areas of performance impact are said to be:
    • The sheer volume of draw calls the viewer has to make under OpenGL, which have a large processing overhead.
    • Avatar rendering, due to that volume of unoptimised content avatars can be loaded with – hi-poly meshes, excessively heavy unique texture use, etc.
    • Poorly considered in-world content (undue reliance on high LOD models, texture use, etc.).
    • The processing required for rendering shadow, etc, (when people run them).
  • The draw calls issue could be largely significantly reduced via a switch to more recent graphics APIs – such as Vulkan (PC) and Metal (Apple), which process things differently. Such a switch also yields benefits in other areas – such as the potential to use graphics libraries based on the capability of the user’s computer.
  • As such, the preferred route is to make incremental changes, such as a switch to a more modern set of APIs and libraries, rather than a total replacement of the rendering engine, simply because this will yield some degree of benefit and improvement without a substantial impact on the Lab / SL / users.
  • Another aspect of performance improvement (which has also been subject to recent questions) is improving the viewer code to better leverage multi-core processors.

General Improvements / Education

  • It’s acknowledged that better LOD models for objects would help improve performance where “new” content is concerned, and work is being put into a mesh optimiser,, although more could be done.
  • The Lab also acknowledges that much of the documentation produced through the wiki for content creation is increasingly out-of-date. There is also much that simply isn’t documented.
  • A problem with a lack of proper documentation / education is that creators  – especially those new to the platform – can pick up incorrect ideas / approaches, and end up contributing to  issues such as poor performance (e.g. the idea that everything must be high poly in order to be high quality).
  • However, the flip side of the argument is, even if effort is put into better documentation, etc., there  is a) no guarantee it would be read be newer creators; b) it is unlikely that those already set in their ways (bad habits and all) will actually decide to take notes and change their ways
  • While somewhat valid this above point doesn’t excuse ensuring the information that is provided is at least relevant / accurate and again becoming a resource that can be actively used / pointed to.

In Brief

  • A clarification was given on the upcoming resumption of work on the 360º Snapshot viewer (see: 2021 TPV Developer Meeting Week #25 Summary), stating that this viewer remains for snapshots only – there are no plans at present to extend it to 360º video capture.
  • There are still no plans to re-implement official support for VR headsets at this time, as it is generally felt at LL that while it would be nice to offer it, overall viewer frame rates cannot be maintained (e.g. at least 60 fps per eye) to make for a comfortable experience.
  • BUG-229908 “[EEP] Build floater shows incorrect light colour values/incorrect colour set for light” (also BUG-230549 “Colour picker for Light (PRIM_POINT_LIGHT) shows and sets incorrect values”, noted as a duplicate to BUG-229908), has been accepted by the Lab, but no ETA on any possible fix – and it is not currently being looked at as a part of the LMR-6 work.