Category: SL User Group Meetings

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

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

• Data gathering is continuing, with the intention of gathering enough information on different rendering operations to be able to update the current cost coefficients being using in the rendering cost calculations.
• Normalising the settings across different client-side hardware is seen as a challenge.
  • One thing the Lab proposes doing is running the resultant model across a range of client hardware types and different ranges of settings.
  • However, if there are significant differences across hardware types (which is likely), then some weighting mechanism will need to be used.
• One issue noted as a part of the work is a persistent spike – frames in every second that were much longer than the others in the Windows viewer. This was traced back to a call being made to an expensive API that wasn’t even required and has therefore been removed.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

• Project definition document.
• Project summary (this blog).
• Full EEP Documentation.

Current Status

• The viewer is being merged up to the latest release viewer (version 6.3.2.530962, dated September 17th, promoted October 15th). This may also include at least one UI issue fix as well.
• There are no further simulator-side updates that are ready for deployment as yet, but work has been continuing in resolving bugs.

Other Items in Brief

• Following on from the discussion at the previous meeting about object size and land impact calculations a feature request – BUG-227762 “Removal of Size from Land Impact calculation/Texture LOD/Adjustable LOD distance” – has been submitted, and has been accepted by the Lab for consideration
  • The Jira also touches on texture management and handling, suggesting a way the textures for an object could be manipulated / downscaled in real-time.
  • It was pointed out that Firestorm offers an automatic downscale of 1024 textures in its 32-bit versions (and the setting in optional in the 64-bit versions), but the suggestion is that be providing users with information in the viewer could allow them to make more informed choices when making adjustments to help with their own performance.
  • This JIRA will be looked at in reference to ARCTan.
• Something of a companion idea to this would be to allow a texture upload to produce multiple versions of a texture (e.g. a 1024×1204 also produces a 512x512x256x256 and 128×128). This has been discussed in the past, and is seen as something that, will requiring input from the Product Team, might be worth exploring.
• A suggestion to lessen the reliance on high-res specular maps is for the Lab to provide a set of default grey textures at (say) 128×128 against which specular glossiness and environment could be set. A counter to this was that the blank white texture could be used and tinted to grey.
• There was also general discussion on PBR and its possible introduction to SL in the future (it is *not* on the roadmap right now!) and its potential impact on existing content were it to be introduced.

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

Graphics Team

There are two new Lindens now on the rendering team – Euclid Linden, who has been with the Lab for around a month at the time of writing, and Ptolemy Linden, who has been a Linden for the last couple of weeks, again at the time of writing. Both will be working on various rendering projects which will include the Love Me Render viewer updates and also projects like the Environment Enhancement Project (EEP) – which is considered a priority in order to move that project towards release.

Viewers

No further updates thus far in the week. The hope is that the Vinsanto Maintenance RC viewer (version 6.3.2.530962 at the time of writing) looks to be in “good shape” for promotion, but currently requires a little more time in its release cohort.

This leaves the official viewer pipelines at the time of the meeting as follows:

• Current Release version 6.3.1.530559, formerly the Umeshu Maintenance RC viewer, dated, September 5 – No Change.
• Release channel cohorts:
  • Voice RC viewer, version 6.3.2.531587, October 8.
  • Love Me Render viewer, version 6.3.2.531296, September 30.
  • Ordered Shutdown RC viewer, version 6.3.2.530972, September 24.
  • Vinsanto RC viewer, version 6.3.2.530962, September 17.
  • EEP RC viewer, version 6.4.0.530150, August 19.
• Project viewers:
  • Legacy Profiles viewer, version 6.3.2.530836, September 17. Covers the re-integration of Viewer Profiles.
  • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530473, September 11.
  • 360 Snapshot project viewer, version 6.2.4.529111, July 16.
• Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
• Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

• Work is progressing on building a predictive model based on the data LL has been gathering on mesh complexity, frame times, etc.
• This model will be tested across a wider range of client hardware types and different ranges of settings.
• The data thus far confirms that geometric complexity plays a large part in performance reduction, but also that there are a lot of other variables in play: rigged meshes are very different in behaviour impact to static meshes; some graphics properties can make a “big difference” in frame time, etc.
• Details on the impact of textures has yet to be folded into the project.

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Current Status

Still largely on hold while ARCTan is being focused on.

Other Items in Brief

• Mesh Uploader: a couple of points were brought up concerning the mesh uploader:
  • At the time mesh was introduced, materials were no supported; therefore, in the uploader there is code to discard tangent space (which can be used by normal maps). This means normals must be calculated in real time, causing both performance problems and inconsistencies between how normals appear in Second Life and how they appear in the 3D software used to create them. It’s been suggested this issue should be the subject of a Jira.
  • Allowing for the work on ARCTan, some see the uploader unfairly punishing on grounds of size and LI.
    • It what pointed out that a very large mesh that can be complex to render get hit with a high LI and high upload cost, but a very small object  – which may still have tens of thousands of triangles – is not penalised to the same degree, even though it might be as costly to render.
    • The alternative suggested was to have costs based not on LOD boundaries & changes rather than a simple size / LI basis. The idea here being that the cost is more reflective of what is seen and rendered by the viewer, which is seen as “levelling” the playing field (if a small object has a really high LOD tri count, then it would incur higher costs, in theory making creators more conservative in how they construct their models.
    • It was pointed out that in some respects complexity / LODs are already being gamed (e.g. by having one high LOD model then setting the medium and low LOD levels to use the same low poly version of the model for both and avoid costs for a proper mid-level LOD model), and such an approach as suggested might further encourage similar gaming.
    • Vir’s view is that the issue is not really that tied to the uploader per se, but is more in the realm of overall cost calculations (although LOD models obviously impact upload costs). As such, ARCTan is really the first step in trying to deal with these kinds of issues, and may help alleviate some of the perceived imbalance seen with upload costs.
• Materials and Bakes on Mesh: a request was again put forward for LL to provide materials support for Bakes on Mesh. This is not an easy capability to supply, because:
  • System layers for clothing do not have a means to support any materials properties.
  • The Bake Service has no mechanism for identifying and handling materials properties to ensure they are correctly composited.
  • Thus, in order to support materials, both the system wearables and the Bake Service would require a large-scale overhaul which, given all that is going on right now (e.g. trying to transition services to being provisioned via AWS services), the Lab is unwilling to take on.
• A request was made to allow 2K textures to be displayed by Second Life under “controlled conditions”, the idea being that a single 2K texture could eliminate the need for multiple smaller textures. The two main problems here are:
  • There is already a propensity for people to use high-res textures across all surfaces, whether required or not on the grounds “higher must be visually better”, so allowing even higher resolution textures to be displayed could exacerbate this.
  • Given there is no real gate keeping on how textures are used in-world once uploaded, how would any “controlled conditions” on the use of certain textures actually be implemented (both technically and from a user understanding perspective)?