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 24th 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.

SL Viewers

Pipeline Updates

The Love Me Render RC viewer updated to version 6.3.3.532031 on Wednesday, October 23rd, bringing it to parity with the current release viewer. The rest of the viewer pipelines remain as follows:

• Current Release version 6.3.2.530962, formerly the Vinsanto Maintenance RC viewer, dated September 17th, promoted October 15th – NEW.
• Release channel cohorts:
  • Love Me Render RC viewer, version 6.3.3.532031, October 23rd.
  • Ordered Shutdown RC viewer, version 6.3.3.531767, October 21st.
  • Maintenance RC viewer, version 6.3.3.531784, October 18th.
  • Voice RC viewer, version 6.3.3.531811, October 18th.
  • EEP RC viewer, version 6.4.0.530150, August 19th.
• Project viewers:
  • Copy / Paste viewer, version 6.3.3.531844, released on Monday, October 21st.
  • Legacy Profiles viewer, version 6.3.2.530836, September 17th. Covers the re-integration of Viewer Profiles.
  • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530473, September 11th.
  • 360 Snapshot project viewer, version 6.2.4.529111, July 16th.

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

• Vir is working on trying to gather data on the impact of textures in rendering avatars and objects.

Project Muscadine

Project Summary

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

Current Status

• The server-side support or Muscadine is awaiting an update.
• The viewer has been merged up to the latest release viewer (no actual updates to the Muscadine code), and is awaiting QA testing.

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 anticipated viewer update has been delayed as a result of a couple of the changes made resulting in unintended outcomes whilst in testing. Plus the viewer now needs to be merged up to the current release viewer.
• Still no back-end updates while Ptolemy and Euclid continue to get up-to-speed with the SL rendering engine and pipelines.

Other Items in Brief

• BUG-227585 “[BOM] Display the new Universal wearables between the Skin and the Tattoos ones” is a feature request suggesting the new Universal Wearables for Bakes on Mesh be moved from sitting above the skin and tattoo layers, to being between them.
  • With a noted reservation that doing so will change behaviour so are already using, the Lab has accepted the idea as something they might consider.
  • The Jira includes additional discussion points  / ideas.
• The meeting included a discussion (voice and text) on alpha sorting and the issues that can occur within it when using alpha blending. Some of these issues are SL specific, others are more generic in nature and found within OpenGL in general. The suggestion was made to allow a certain amount of creator-defined ordering with objects, but there were several concerns raised around this by creators and the Lab, including the potential for performance impacts.
• The above discussion spiked into one about avatar meshes, the potential for a new “standardised” (or “Lab-driven) “mesh avatar 2.0”, that could be far more rendering efficient than all existing models, th pro (better efficiency of design and rendering) and cons (whole new system incompatible with existing heads / bodies & getting people to use it).
• Also folded into this was a conversation on how to encourage creators to make more efficient content.
  • One suggestions is to have some form of “scoring” system taking into consideration item complexity, use of textures, etc., that determines how high up on Marketplace searches goods appear & thus are likely to be seen and purchased – the idea being that by trying to “game” the scoring system, creators produce better content.
  • This skips the case of items sold in-world (how are scores enforced on vendors?). And also has a problem of how does an automated system “score” pre-packaged items uploaded to the MP (since it would only be able to assess the packaging, not the content)?
  • Alternatively, Vir pointed out that there is a lot more that the Bake Service could do in assessing the complexity of avatars in-world, and this could be potentially more meaningful in the future as ARCTan progresses beyond the current scope of the project.
• Overall, and given the amount of legacy content in SL, one of the core ways of encouraging better content  is seen as not only making improvements to the mesh uploader and trying to push creators into making more efficient content – but to give users the tools and reporting that help educate them about what is going on around them, what is causing potential performance issues and then allowing them to start making more informed decisions on how they set their viewer and the kind of content they purchase.
• Date of next meeting: Thursday, November 14th, 2019.

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.