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, December 19th 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.

The majority of this meeting was a generic conversation of ideas such as moving Second Life to support PBR, what might be done to improve Pathfinding, etc., none of which are on the road map for Second Life at present; as such these notes keep the the current projects that are in progress at the Lab.

SL Viewer

A new Maintenance viewer, code named Xanté, was released on Thursday, December 19th. Version 6.3.6.533748 contains around 30 fixes for reported issues and bugs. All other viewer remain as per my Current Viewer Release List.

With regards to viewers:

• The Lab’s focus has been on transitioning their Bitbucket viewer build repositories from Mercurial to Git – see my week #50 TPVD meeting notes for more.
• As well as the current pipelines of viewers, work is also in hand to ensure the viewer is ready to manage Name Changes when that capability is deployed in early 2020.

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

• Bug fixing continues, notably around alpha rendering issues.
• The hope is that of the remaining issues, some my be related, and so solving one will help to solve others of a similar nature.

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 getting things to a state where he can do so practical testing over the holiday period to ensure the relevant data is being collected. This is dependent on whether he has the time to confirm the internal version of the viewer is logging everything it needs to be logging.
• The work is still very much focused on the data collection aspect, rather than doing anything with the data that is gathered.
  • The kind of data being gathered includes: what are the graphics and geometric properties of the objects in a scene, what rendering settings are being used, poly count for different LODs with a model, what are the graphics properties in use (materials, texture + texture size, etc.), plus the time required to generate a frame successfully given the work required to render the scene.
• Once the data has been gathered, the idea is to run the viewer on multiple hardware configurations (GPU, CPU, etc.), and gather data on the the impacts of changes those various properties.
• The aim is to get a more accurate feel for how performance is impacted, and how significantly changes impact performance (e.g. what’s the impact of enabling Full Bright compared to enabling materials? Which is genuinely better: properly optimised mesh or plain faces with materials or a combination of low-resolution mesh + materials?
• As well as allowing the complexity calculations for avatar attachments and in-world objects to be better refined, the data gathered might, further down the line in the project, enable LL to make plausible forecasts of what might be seen by way of performance improvements in relation to suggested constraints being put on objects as a part of the creation process.
• Textures are still proving a problem in terms of measuring impact (e.g. is it more a total threshold limit being hit, rather than the number of textures used within an individual object?).
• Anther limiting aspect is the number of different bottlenecks users can experience quite outside of the Lab’s control (e.g. their network connection, what else is going on across that connection at the same time, etc)., and bottlenecks within individual systems that can vary.
• One attempt to improve things that has been made in Firestorm is for the matrix calculations for worn mesh to be cached the the bones to which the mesh has been rigged hasn’t moved between frames. This can save up to 7 sets of calculations for a mesh with 8 faces that the viewer may not actually need to make. This may be contributed to LL for evaluation.

** The next Content Creation User Group Meeting should be on Thursday, January 9th, 2020, but check the wiki page for confirmation **

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, December 12th 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.

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

• Bug fixing continues – the estimate is around 18 or so bugs the Lab would like to resolve prior to any potential release.

Project Muscadine

Project Summary

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

Current Status

• Still on hold due to the focus on ARCTan.
• There are still requests to allow attachments on Animesh items.
  • This is something Vir hopes to look at in detail later in Muscadine.
  • It may require attachments to be handled differently to how they are managed with avatars.

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 getting things to a state where he can do so practical testing over the holiday period to ensure the relevant data is being collected. This is dependent on whether he has the time to confirm the internal version of the viewer is logging everything it needs to be logging.
• The work is still very much focused on the data collection aspect, rather than doing anything with the data that is gathered.
• It is not currently clear whether the ARCTan work will appear in a dedicated project viewer or will form a part of a Maintenance viewer update.

Texture Caching and Loading

• LL is working on a viewer intended to improve texture loading and texture caching (the latter as part of a general overall of how the viewer caches data).
• This will hopefully include a rethinking of the order in which textures are loaded (e.g. objects  / faces that all use the same texture may all have that texture loaded together/in sequence, rather than the texture having to be re-loaded each time it is encountered).
• The improvements should see textures load faster in general. In particular, there is a re-examination of some of the “optimisation” work previously done with textures, as this might actually now be slowing things down, so the hope is the new viewer will streamline how textures are handled and loaded in general, so bringing about improvements.
  • An example of this is switching the viewer from downloading a texture (or grabbing it from cache) and rendering it incrementally to just letting it grab the entire texture, particularly now that most broadband connections will allow this without it becoming a significant bottleneck.
  • This will allow a significant reduction in the amount of checking and re-checking the viewer has to carry out when obtaining and loading textures, which can have an impact.
• Hopefully, the viewer will also improve the texture load order (e.g. those textures nearest to you or filling your immediate field of view, such as a vendor board on a wall, will be loaded and rendered first, rather than waiting for other textures loading first).
• There is currently no date on when this viewer might surface for public use.