2021 CCUG meeting week #24 summary

Nelipot, March 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, June 17th, 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 viewer since Monday, June 14th, leaving the official viewer pipelines as follows:

  • Release viewer: LMR 5 viewer, version 6.4.19.560171, dated May 27th, promoted June 7th – NEW.
  • Release channel cohorts:
    • Project UI RC viewer, version 6.4.20.560520 dated June 14th.
    • Maintenance 2 RC viewer – Fernet, version 6.4.19.559726, dated May 19th.
  • Project viewers:
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26th, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9th, 2019.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, dated November 22nd, 2019.
    • 360 Snapshot project viewer, version 6.2.4.529111, dated July 16th, 2019.

General Viewer Notes

  • The Project UI RC viewer will be the next to be promoted to de facto release status, and this will be in the “next week or two”.
  • The Mac notifications viewer has still yet to surface as a either a project or RC viewer.
  • The revised simplified cache viewer RC is returning to LL’s QA team, and if it passes through testing, should be appearing as a new RC, but this may not be for another couple of weeks.
  • A further CEF (Chrome Embedded Framwork) viewer for web content – media streaming, etc., – is also in the works, that should support more streaming / media codecs and fix a number of streaming-related issues.

ARCTan

Summary: An attempt to re-evaluate avatar rendering costs and the cost of in-world scene rendering, with the current focus on avatar rendering cost / impact, with the 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
    • It had been indicated the UI work could appear in the viewer before the avatar ARCTan calculations are updated to more accurately reflect the cost of rendering avatars.
    • However, there is a concern that if this is the case, the new floater will simply be ignored when made available, and will continue to be be ignored after the calculations have been revised.
    • It has therefore been suggested it would be better to revise the calculations first, and then release the viewer with the new information floater and explanations as to why it should be taken note of. LL have indicated they may consider doing this.
  • There is an on-going debate as to how useful information / self-regulating exercises like ARCTan are, compared to the enforcement of hard limits.
    • Self-regulating exercises (users making use of the information provided by their viewer) tend to be ignored (e.g. the Jelly Dolls complexity slide is generally left ramped up to the highest), thus defeating the purpose of such exercises.
    • However, enforcement of hard limits runs the risk of causing a high level of upset (and possible quitting) of a good portion of the user base when they find they can no longer overload their avatars with high-vertices/high texture load/heavily scripted attachments.
    • To  avoid the latter, it has been suggested the viewer should be able to automatically reduce avatar rendering to progressively lower LOD settings based on the load they place on the local system, rather than purely by distance from the camera.
  • It’s also bee suggested that for meshes in general, Second Life should have a robust auto-LODing system at upload.

In Brief

  • A long-standing issue for content creators producing mesh linksets for upload to SL, is that while they could give each element in the linkset a unique name for easier re-assembly post-upload, following upload, only the first element of the linkset would retain its name – the rest would be converted to “Object”, making re-linking an onerous task.
  • BUG-202864 “Change Mesh Uploader to preserve Scene File object names when a full linkset is uploaded” was raised in 2018 as a request for this to be addressed, and a viewer-side change to support this was implemented thereafter.
  • However, as per the week #22 CCUG, the server-side update also required to support this was not made, and the matter slipped off of LL’s radar.
  • Following that meeting, Vir Linden referred the matter to Rider Linden on the simulator team, and he has reported that:
    • The required server-side support will be going to RC, hopefully in week #25 (commencing Monday, June 21st).
    • In the interim, those wishing to test the capability can do so via the Preflight group of regions over the weekend.

One thought on “2021 CCUG meeting week #24 summary

  1. Regarding rendering costs one thing that would be helpful would be to require that merchants list the costs for all wearables on the Marketplace. It would help motivate some of them to improve their practices when people start questioning Merchant A why their dress has a complexity of 10,000 points while beautiful dress from Merchant B only costs 1,000 points. In other words we need to start embarrassing some Merchants into doing a better job of optimizing their content.

    Like

Comments are closed.