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, September 26th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

This was a shorter than usual meeting.

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 continuing on getting the logging and analysis elements of the project up and running. Right now the (in-development) test viewer is described and pouring out a lot of “gibberish” on frame draw rates and all of the attributes in a scene, and the idea is to try to pull this together into a predictive model that is more accurate than the current rendering cost model.

Project Muscadine

Project Summary

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

Status

• Largely on hold while ARCTan is being focused on.
• A bug whereby physics parameters weren’t being correctly applied has been resolved and a fix should be available in the next viewer update.
  • The default viewer-size avatar animations (fidgets, eye tracking, etc), were disabled for Animesh and have not been re-enabled, this update only applies to physics params.

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

• A new graphics resource – Euclid Linden – joined Linden Lab last week. He is currently finding his way around the rendering system and will be working on EEP in the near future.
• A further graphics expert is due to start with LL in the next month, and once up to speed, they will also be lending support to EEP.

General Notes

• Script breakage: there have been a number of reports filed concerning script breakage recently (see: BUG-227669,  BUG-277667 and BUG-227659 for examples). The reports have been noted by the Lab but have yet to be triaged
• The next CCUG meeting will be on Thursday, October 10th.

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, September 19th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually 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

• An unexpected / unintended side-effect of Bakes On Mesh is the baseline avatar rendering cost has gone up by 1,000. This is due to the additional channels being added in support of BOM (so a basic, naked system avatar will have a complexity of 2,000 instead of 1,000). Vir is going to correct this.
• Just as a reminder: there is no certainty as to how ARCTan will work – the Lab is focused purely on data gathering at this point, not on implementation. As such it is far too early to discuss policy, rules, implementation, etc.
• One aspect that is being considered is to provide a set of in-world tools and / or example models to allow creators better understand what ARCTan might be doing and how it could affect their work. Again, this could only be done when LL is in a position to start moving forward with ARCTan.

Should Existing In-World Content Be Excluded?

One area of discussion on ARCTan has been the matter of existing in-world content: should it be subject to the new ARCTan calculations (whatever they might be) or excluded?

• Arguments for excluding existing in-world content include:
  • Less risk of upset if changing values sees an increase in the land impact of items, prompting confusion among users (“why is my 16 LI bed now 26 LI?”).
  • Reduction in the possible large-scale return off objects by parcels / regions where ARCTan changes take them over their limit.
  • “Easier” to implement, as new costs only apply to “new” content.
  • Less work for content creators in updating their documentation (note cards, MP listings, vendor boards, etc.) to correctly reflect the “new” LI values for their goods that are changed as a result of ARCTan.
  • Reduces the risk of “permanent” content breakage in instances where the LI for objects rises to impact user’s ability to have them in-world, and the creator is no longer active to provide better optimised updates.
• Arguments against excluding existing in-world content include:
  • Potentially limits the purpose of ARCTan in educating users about using decently optimised content.
  • Introduces questions on how new limited should be applied. On upload? On rezzing?
  • If on rezzing, user confusion may not be negated (“when I rezzed this bed last week it was only 16 LI; now when I rez it, it is 26 LI! Why?!)
  • ARCTan will not be an overnight implementation. LL plan to try to work with creators and users to provided information on changes, and work as far as possible to minimise the risk of content return.
• The idea of excluding existing content has not been ruled out. But again, until the Lab have baselined their data, carried out experiments and tests in order to see the likely impact of various adjustments to the calculations / costs and investigated what can be done to mitigate some of them (e.g. increase the land capacity of regions), nothing can be decided one way or the other.

Core Content Projects Summary

• Animesh Follow-On – Project Muscadine: effectively on hold while Vir focuses on ARCTan.
• EEP: work continuing on rendering bug fixes, with additional resources being added to the project.

General Notes

• Avatar Impostering
  • Concern has been raised over the complexity handling on Animesh with impostering. Currently, Animesh objects are handled the same as avatars. However, as they are a lot less complex, there is an argument to say Animesh should be handled differently to avatars when impostering.
  • This is being taken into consideration, with the possible introduction of a “max Animesh” setting for the purposes of impostering Animesh.
  • Whether or not this will affect the current baseline for impostering avatars is unclear; the work is still only at the point of discussion.
• Mesh uploader:
  • There are reports of a rise in issues when uploading mesh models – failure to complete the upload, coupled with the production of hard-to-decipher “mav” errors.
    • So far as the Lab is aware, nothing has changed within the viewer or on the simulator side that might be causing the problems. Those encountering such problems are asked to file a Jira, preferably with  viewer log files.
    • There is a viewer with improvements to the mesh uploader in development. This may not resolve the issues, but it should offer improved feedback and messaging during the upload process.
    • It’s been suggested that the problem could be due to recent updates to Blender in saving .DAE files.
  • Many 3D tools are moving to use / support the glTF file format, which is currently subject to much discussion / criticism. Linden Lab has no plans to support the format at this point in time.
  • A few months ago, it was indicated that custom origin point (pivot point) for meshes would be implemented. This work is currently awaiting some back-end changes. As such, until these changes are made, the work is on hold.