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, November 18th 2021 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.

AVAILABLE VIEWERS

This list reflects those viewers available via Linden Lab.

• Release viewer: version version 6.5.0.565607, formerly the Maintenance RC and dated November 10, promoted November 15 – this viewer now contains a fix for the media issues caused by the Apple Notarisation viewer.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • The Tracy Integration RC viewer version 6.4.23.563771 (dated Friday, November 5) issued Tuesday, November 9.
  • 360 Snapshot RC viewer, version 6.5.0.564863, issued October 21.
  • Simplified Cache RC viewer, version 6.4.23.562623, dated September 17, issued September 20.
• Project viewers:
  • Performance Improvements project viewer updated to version 6.4.24.565324 (dated November 5) November 9.
  • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
  • Mesh Optimizer project viewer, version 6.4.23.562614, issued September 1.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

• It is possible the 360 Snapshot RC viewer and the Simplified Cache RC viewers may be merged prior to either being individually promoted to de facto release status.

Graphics Work

• The core of the graphics team is shifting emphasis from making performance changes to the rendering pipe to focusing on stabilising the changes thus far made. As Vir has elsewhere noted, the problem with moving operations between threads / to their own threads is that there can be undesired consequences which then must be addressed.
  • This work has comprises a number of elements, both in moving processes that should logically have their own threads, and in moving processing that can cause the main thread to stall while it is handling them (e.g. processes that talk to the graphics API, the texture upload to OpenGL, etc.) to other background threads.
• Runitai Linden continues to update how avatar rigged meshes are rendered.
  • In short, he hopes to use the same approach to handling static meshes to rigged mesh (including Animesh creations), allowing the latter to be handled in batches, reducing the overall number of draw calls and giving a potentially substantial performance boost.
  • The improvements should be particularly noticeable when rendering the “onion layer” avatar meshes that have multiple layers and are segmented into multiple cuts. Runitai reports his testing shows a 50% improvement in rendering 20 avatars – but improvements will be hardware dependent.
  • There are some issues: as it stands, the updated code does change the order of sorting / rendering alphas, which could be problematic for some creators. If so, LL will look at what can be done to prevent this (as an aside to this, vertex ordering within Blender, etc.), should not be impacted). There are also limits on how far this can be taken due to things like how faces with unique textures or with separate materials must be handled.
  • Currently, Runitai plans to spend the next few weeks testing and improving the changes with a view to having a view publicly available in the New Year.
• Part of the discussion centred on texture use (and over-use), which covered a number of elements including:
  • A reminder of why the use of 1024×1024 textures on every surface, no matter how small is really bad idea, both because of the amount of VRAM each texture (+ any associated materials) uses (up to 4MB each); and because even if the face used only exposes a small portion of the texture, the viewer still has to process the entire texture before it can be rendered at full resolution, so it’s just leaving people with a greater amount of time the texture is blurred in their view.
  • The pros and cons in using a texture atlas. On the plus, this always multiple textures to be handled as a single draw operation, and is done where possible. However, unlike a conventional game, texture use in Sl is less predictable (e.g. an avatar can use the same texture “as is”, alpha masked, alpha blended and as a specular map, impacting the ability to use it within any texture atlas.
• Whilst on the back burner at present, it is hoped that Vulkan, if / when adopted, could solve a lot of texture batching and draw call issues on the Windows platform, as it has a “fundamentally different” way of handling the latter. However, any shift in graphics API is held depending the current clean-up of the rendering code. On October 30th, Runitai described the options under consideration as:
  • Using Vulkan (Windows) and Metal (Apple).
  • Running Vulkan extraction layers on top of G3D on Windows (and MoltenGL for Apple?)
  • Implementing an off-the-shelf multi-API extraction layer.
  • Home-brew a dedicated extraction layer.
  • Stick with OpenGL for Windows and use MoltenGL for Apple (as noted above).
  • Initially supporting Vulkan + OpenGL for Windows and then retiring OpenGL and running Vulkan extraction layers on top of G3D (no word on Apple solutions in this scenario).
• As a part of the current  work, LL has tested using OpenGL Core Profile rather than the currently-used OpenGL Compatibility Profile.
  • Core Profile offers a performance win for nVidia GPUs – but presents a performance hit for AMD and Apple systems, so a determination on its use has yet to be made.
  • Core Profile also does not work GLOD for mesh uploads, so if adopted, GLOD support may be entirely dropped from the viewer in favour of the Mesh Optimiser (as found in the current Mesh Optimiser project viewer).
• Other updates the graphics team are considering include:
  • Making VSync enabled by default in the viewer, which should give a more consistent rate at high (100+) FPS.
  • Removing the ability to uncheck OpenGL Vertex Buffers and Hardware Skinning, as disabling either isn’t particularly good for performance.

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

AVAILABLE VIEWERS

This list reflects those viewers available via Linden Lab.

• Release viewer: version version 6.4.23.564172, formerly the Apple Notarisation Fix RC viewer, issued September 24 and promoted October 15.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • 360 Snapshot RC viewer, version 6.5.0.564863, issued October 21.
  • Maintenance RC viewer updated to version 6.5.0.564805, on October 20.
  • Simplified Cache RC viewer, version 6.4.23.562623, dated September 17, issued September 20.
• Project viewers:
  • Performance Improvements project viewer, version 6.4.23.564530, dated October 12.
  • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
  • Mesh Optimizer project viewer, version 6.4.23.562614, issued September 1.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

Graphics Work

• As has been previously reported in my user group meeting summaries, a core focus of work at the Lab is on performance improvements, both on the back-end and in the viewer.
• With the viewer, the work is very much on improving graphics / frame rate performance (utilising the Tracy analyser). Much of this work has been to move non-rendering operations currently in the main rendering thread to their own / other threads.
  • In October, the first cut of a project viewer featuring the fruits of this work was issue (see Performance Improvements Viewer in the list above), and an update to this viewer is expected in the next working day or so.
  • Once the updated version of the viewer is available, users are encouraged to take it for a test and see if they can see improvements in rendering / FPS rates.
• Overall, the Graphics team plan to spend around two more weeks in general performance updates. before the work will shift to stabilising the changes so far made to the viewer (which has been acknowledged as being “crashy” at this point in time).
• Once the stabilisation work has been completed, the hope is that the viewer will be in a position to progress forward through the RC cycle to enter the queue for promotion to release status around the the end of the year, with actual promotion coming in early 2022.
• Separate to the above, Runitai is currently working on the fork of the render pipe inside the avatar draw pool that handles the rendering of avatar rigged meshes. The aim is to move this work to the same machinery that handles the other draw pools, and so hopefully enable rigged mesh rendering to be handled on a batch basis, rather than one face at a time as is currently the case, thus giving a potentially substantial performance boost.

In Brief

• WRT to performance, it was pointed out that the baseline hardware specifications LL give for Second Life are route in hardware between 10-15 years old, and so many users tend to stick to outdated hardware. Thus the situation is somewhat double-edged: ending support for older systems would allow LL to focus more on updating and improving SL to run on more recent hardware; however, by the same measure, it risks “locking out” users who may be unable to move on to more recent hardware in order to stay reasonably “current”.
• Work is still in progress trying to overcome the Apple Notarisation / media issues and outlined here. Part of the problem was the result of LL using a very old VLC. However, getting a new VLC to be recognised by the notarisation process is also proving problematic.
• A request was made to all region owners to be able to automatically drop a general information package on preferred viewer settings, etc., on users arriving in a region. Given automated notecard givers can already do this, and many of the “recommendations” are completely over the top for many systems (e.g. “set your graphics to Ultra, enable shadows and set your draw distance to 500+ m”), no advantage is seen in providing  a capability to provide this information (presumably via a chat channel).
• Similarly, pro-actively scanning viewer settings using LSL as visitors arrive and “advising” them about the recommended settings for a region should some of their own be “below” the recommendation, was also seen as not particularly advantageous unless it was somehow made an opt-in capability that those who do wish to receive such information can do so.
• It is recognised that Pathfinding is overdue for some improvements, and it *might* be that it gets looked at in the future; however there are no definite plans beyond considering what might be done, and poking at feature requests, etc., that have been filed for Pathfinding.