Category: Content Creation User Group

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

The Fernet Maintenance RC updated to version 6.4.21.561414 on Wednesday, July 14th. The rest of the available official viewers are as follows:

• Release viewer: Project UI RC viewer, version 6.4.20.560520, dated June 14, promoted June 23 – overviews: Lab issues Project UI viewer aimed at new users and The Project UI viewer: a look at the new user Guidebook.
• Project viewers:
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.
  • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, dated November 22, 2019.
  • 360 Snapshot project viewer, version 6.2.4.529111, dated July 16, 2019.

General Viewer Notes

The Fernet Maintenance RC should have been promoted, but an error in the merging process meant that it has only just been merged with the current release viewer, so a further RC version has been issued to soak for the next few days in preparation for promotion, possibly in week #29.

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, which has seen some further redesign work.
• This work is currently separate to the work on revising that actual formulas used for calculating avatar complexity.
  • It has been suggested on a number of occasions that it might be preferable to hold-off issuing any viewer with the new floater until the new avatar ARC calculations are available and used, to prevent people just ignoring the information as being “wrong”, even when the new calculations do come into use.
  • There is a strong probability that without proper education, users will simply ignore the information anyway, but the objections to issuing the viewer ahead of the correct calculations being available has been acknowledged, so internal discussions are still in progress as to when the viewer might be released.
  • Beq Janus is working on her own variant of avatar ARC calculations, which she has dubbed “TrueARC”, which currently simply overlays avatars with colours (green, yellow, red) to indicate their rendering load from low to heavy. This work is in its early stages, and Beq plans to keep LL updated on her work / findings.

Graphics Work

• The Graphics team are working to integrate the Tracy debugger / system analyser for cross-platform graphics development. This will be used to look for performance “hot spots” in the rendering code.
• Callum Linden has now resumed work on the 360-degree snapshot viewer.

EEP Items

• Mainland EEP settings: since the release of EEP, multiple Mainland regions suffer from their default EEP settings being too dark. The fix for this has been awaiting the implementation of new tools on the back-end, which are now available. As a result, a simulator using updated environment settings for Mainland is currently on test, and will be deployed Soon™.
• BUG-230677 “llSetAgentEnvironment transition doesn’t work” – a fix for this should be in the next Love Me Render RC viewer (LMR-6).
• Following the EEP discussion at the Simulator User group (notes here), Vincent Nacon has raised his concerns / ideas in a set of Jiras:
  • BUG-230973 “[EEP] Obscured option to reset Cloud Scroll to the default position” – bug awaiting review.
  • BUG-230974 “[EEP] Increasement [sic] to max limit on Cloud Scale” – bug awaiting review.
  • BUG-230975 “[EEP] Brightness Slider for the Sun” – this is currently awaiting the weekly Feature Request triage.
  • It is possible the two bugs might be picked up for inclusion in an LMR viewer.

Mesh and LODs

Investigations have started into ways to improve mesh LOD model generation using the open-source Mesh Optimiser (originally used within Sansar). No ETA on potential visible output from this work at present.

This sparked a discussion on whether, and if introduced, auto-LODding should be enforced on existing content.

• The “pro” argument for this approach is that it would “rectify” content with poor / missing LOD models.
• The arguments against the idea include:
  • Many content creators do properly craft their LOD models correctly – and any enforced “re-optimisation” of in-world content could see these LODs replaced by poorer automated LODs, causing understandable upset.
  • Image matching (the suggested means of re-examining content) cannot contextualise content in terms of things like visibility (e.g. the interior of a vehicle might be intentionally entirely low-LOD, as it is designed to be seen from only a handful of metres away).
  • While LL have AWS under them, the process of re-examining thousands and thousands of in-world assets would be processing-intensive and come with a cost. – so who pays?
• A counter suggestion would be to make any such re-optimisation opt-in: if a creator has content they’d like to pass through the system, they could opt to do so and then utilise the automatic LODs.
• LL have also been in internal discussions on where the 16-bit limit on mesh faces originated, with the view that allowing a higher number of polys into a face would a) make rendering easier, and improve object decimation (it would likely be replaced with some form of global limit). However it has yet to be determined if changing this would require changing the mesh asset format. As such, there are no current plans to implement a new mesh format – but doing so in the future has not been ruled out.

In Brief

• A question was asked how any “dominance” between two worn rigged items that use position overrides for the same joint. Vir noted that there is no assigned dominance per se, other than via mesh ID (UUID), so it is something that cannot be directly controlled by assigning a priority or anything like that.
• The question was asked as to the difference, functionally, between a mesh and a sculpt. In short: a sculpt is a texture used as a cylindrical displacement map, whilst a mesh is a physical asset, which has had its ID “kludged” (Vir’s term) into the spot originally intended for sculpt IDs. If Vir recalls things correctly, whether the ID is for a Sculpt texture or a mesh is determined by the presence (or not) of an additional bit of information. Overall, information is to what an item is – prim, flexi, sculpt or mesh – is still held within the “prim” container.

In-Viewer Mesh Editing Tools

There is a view circulating that during his Meet the Lindens (MTL) session at SL18B, Patch Linden indicated that there are “plans to implement mesh editing capabilities inworld”. However, this is something of an incorrect extraction of what was actually said, based on Patch’s initial response to a question asked about content creation and scripting (“I think this is absolutely something we should tackle”). While he did start his reply using these words, Patch also added further context around them by:

• Broadening his reply in terms of the existing 3D tools in the viewer – how people have started with them before going on to model in mesh via Blender, Maya, Unity, etc., – and the more important need for LL to understand what incoming users need today by way of an updated toolset in order to engage in content creation.
• Noting that while Grumpity Linden might agree on this in principle, she would likely have very different idea on if / how / when any such work might be tackled, and so deferred to her on this aspect of any potential tool update.

As such, his comments shouldn’t really be seen as any form of statement that in-world mesh building tools is a project the Lab is about to embark on – and it certainly was not mentioned by Patch or Grumpity at their respective SL18B MTL sessions as being a part of the roadmap of work planned for the next 12-18 months.

The original question and Patch’s complete answer can be heard in the official video of his SL18B Meet the Lindens session, between 1:32:28 and 1:34:52.

Date of Next Meeting

In theory, Thursday, July 29th. However, Vir will apparently be out of the office then, so the meeting is dependent on someone deputising for him. If no-one does, then the next LL-attended CCUG should be on Thursday, August 5th.

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:

• Release viewer: Project UI RC viewer, version 6.4.20.560520, dated June 14, promoted June 23 – NEW – overviews: Lab issues Project UI viewer aimed at new users and The Project UI viewer: a look at the new user Guidebook.
• Release channel cohorts:
  • Fernet Maintenance RC, version 6.4.20.560398, dated June 22.
• Project viewers:
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.
  • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, dated November 22, 2019.
  • 360 Snapshot project viewer, version 6.2.4.529111, dated July 16, 2019.

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.

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.

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, June 3rd, 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 for the week, leaving the pipelines as follows:

• Release viewer: Eau de Vie Maintenance viewer, version 6.4.18.558266, dated April 23, promoted April 29 – No change.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Love Me Render (LMR) 5 viewer, version 6.4.19.560171, dated May 27.
  • Maintenance 2 RC viewer – Fernet, version 6.4.19.559726, dated May 19.
  • Project UI viewer updated to version 6.4.19.559612, May 14.
• Project viewers:
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.
  • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, dated November 22, 2019.
  • 360 Snapshot project viewer, version 6.2.4.529111, dated July 16, 2019.

General Viewer Notes

• The current version of LMR 5, 6.4.19.560171 is set for promotion to de facto release status at the start of week #23 (commencing Monday, June 7th).
  • This viewer includes a fix for BUG-230789 “[MAINT-E] Alpha failures with Release 6.4.18.558266 (64bit)”.
• The New User Experience project viewer will follow LMR 5 as the next viewer on the runway for promotion to de facto relapses.
• There is to be a “general push to improve graphics performance over the next few months”.
• BUG-5975 “Normal map rendering issue when UV island tangent basis has angular difference and mesh is smooth shaded” is an issue that should be fixed with LMR6. This may cause some content breakage, but will do more to fix an unwanted edge case that can affect content.’
  • The majority of the meeting focused on a discussion of this issue, which is more fully explained in this document, with Ptolemy Linden from the graphics team noting that investigations in to how best to resolve the problem and those related to it for SL are still on-going,

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 has finally started on the UI refactoring to present people with a “one stop shop” for displaying surrounding avatar complexity information and action upon it.
• This work is currently separate to the work on revising that actual formulas used for calculating avatar complexity, but the new UI should work with the existing calculations / values. The idea is to make the UI elements for ARCTan visible in a project / RC viewer whilst work continued on the new calculation formulas, then merging the new formulae into the viewer down the road.
• It is currently anticipated that the viewer with the UI work will appear some time in the “next several weeks”.

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

Wednesday, May 19th saw two RCs updated:

• The Fernet Maintenance RC viewer updated to version 6.4.19.559726. This version includes a set of Voice updates intended to reduce the number of drop-outs experienced when using the Voice plug-in. The full details of these updates can be found in the release notes and in the LL technology blog post.
• The Love Me Render 5 (LMR5) viewer updated to version 6.4.19.559046.

The rest of the official viewers in the pipelines remain as:

• Release viewer: Eau de Vie Maintenance viewer, version 6.4.18.558266, dated April 23rd, promoted April 29th.
• Release channel cohorts:
  • Project UI viewer, version 6.4.19.559612, issued May 14th.
• Project viewers:
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26th.
  • 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

• Both the updated Maintenance RC and LMR 5 are the front runners for promotion to de facto release status. From Vir’s comments, there appears to be a lean towards promoting the Maintenance viewer.
• Whichever f the above is promoted first may see the Project UI RC viewer leapfrog the other in being the next viewer set for promotion.
• LMR 6 is continuing through bug fixing work and being prepared for QA testing. It’s unlikely to appear until LMR 5 has been promoted.
• The Legacy Profiles viewer is going through a further UI clean-up, and should be progressing towards either a further project viewer release or possibly an RC release in the not too distant future.
• The simplified cache viewer is now being updated with suggestions for improvements submitted via Jira, and a new version should be appearing “pretty soon”.
• It’s still hoped the at Apple notifications fixes will be appearing in an RC viewer in the near future as well.

Due to the volume of viewers entering the backlog awaiting release, LL is considering merging some of the upcoming RC versions in a bid to reduce the overall number that could end up in flight, and ease the pressure on the release cycle. This will depend on how suitable different RCs are for merging with one another.

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.

The UI updates for how avatar complexity information is presented to users will likely be made available as a project / RC viewer separately to any updates to the ARC calculations, so when it appears it will display values based on the current calculation formula. The updates to the formula itself will be then be implemented separately as the project progresses.

Jira Note – Reports Failing

There have been instances of reports filed via the Jira erasing the descriptive text when filed. Until the problem is resolved, the recommended workaround is to copy the descriptive text fields to a notepad app or similar, then check the report after submission. If the text is missing, the report can be edited and the information cut-and-pasted back into it.

In Brief

• Account / inventory syncing between Agni (the Main grid) and Aditi (the Beta grid) remains broken, but LL are working to fix it. One aspect of the issue appears to be inventory size on Aditi accounts.
  • As a temporary workaround, it has been suggested that those who can access the beta grid and who have very large inventories, consider deleting unwanted items from their Aditi inventory (not their main grid inventory), as this seems to improve the chances of a successful log-in.
• In 2019, a viewer-side change was made to ensure individual objects in a mesh linkset upload would retain their original name (rather than all being converted to “Object” with the exception of the first object in the linkset). However, this change is still awaiting server-side support in order to work, and there is currently no ETA on inplementation.
• There have been requests for additional Bakes on Mesh AUXiliary texture channels. However, there is reluctance at the Lab to do so without a substantial use case, as it would require an extensive overhaul of the Bake Service to accommodate the additional channels, which is not something LL wants to contemplate at present.
• Date of next meeting: Thursday, June 3rd, 2021.