2020 Content Creation User Group week #4 summary

RioSisco Studio Pictures, December 2019 – blog post

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

Resources

Current Status

  • EEP is now viewed as a priority for release by the Lab.
  • Work is continuing on the final bug fixes on the graphics side.
  • Release is anticipated by LL to be within the next month or so.
  • Those who use windlights for photography or within their regions are strongly urged to test the EEP RC viewer (last updated on January 9th, 2020, at the time of writing this summary).

Project Muscadine

Project Summary

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

Current Status

  • Now officially on hold pending other projects / work (notably major projects such as:
    • The cloud migration project.
    • Transitioning the viewer build tools to Visual Studio 2017 and to a recent version of Xcode (OS X)
    • Completing the migration of viewer repositories from Mercurial to Github.
  • The status of the project will be reviewed as other work progresses, but it is unlikely there will be any further work on Muscadene in Q1 2020 (through until the end of March).

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

As of January 2020 ARCTan has effectively been split:

  • Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations.
    • This work will also involve providing additional viewer UI so that people can better visibility and control to seeing complexity. For example:
      • Which attachments are taking the most rendering resources / rendering time.
      • Available options for improving local performance.
    • The aim is to provide users with information they can understand and make use of to assist in their local performance (e.g. “these red figures on your avatar attachment mean it is impacting YOUR system’s performance and slowing YOU down”, rather than jut pointing the finger elsewhere).
    • It is hoped that providing this information may also encourage creators produce better, more efficient avatar-related content.
  • Follow-on / future work on revising in-world object rendering costs (LOD models, etc.), which might affect Land Impact to a later tranche of project work.
    • The belief is that in having “good” avatar ARC values, they can likely be used as a computational base for these rendering calculations.

In Brief

LOD product: LL is considering taking future look at how level of detail is managed by Second Life.

  • GLOD is now 15+ years old and there are potentially better ways to handle things.
  • Automation of some LOD options might be seen as possible.
  • It is recognised that avatar LODs are not the most efficient (e.g. 2X bounding box LODs), but how they might be better managed is seen as a complex issue (e.g. avoiding situations where the viewer uses one LOD for an avatar’s body and another for the avatar’s head, so the head looks deformed compared to the body, or vice-versa).

Content Tools: interest was also expressed in hearing about the preferred tools used by creators and what creators might like to see by way of better support for said tools / file formats related to said tools and in general. The question was not asked with any specific project in mind, but simply to gain a broader understanding of what content creators use, etc.

The tools mentioned by creators at the meeting include:

  • Clothing: Marvelous Designer, Blender, Maya, Substance Painter, 3D Coat.
  • Other tools mentioned: Topogun, Zbrush.

PBR was also mentioned, although this would require a large-scale overall of SL’s rendering engine.

Requests were also made for:

  • Better handling of sub-meshes during the upload process (e.g. consistent linking between different uploads of the same multi-part mesh).
  • Ability for mesh instance recognition (e.g. if a specific sub-mesh is repeatedly used in a build, then it should be uploaded only one and instanced across the build) – or at least the viewer to be able t instance sub-mesh elements when rendering.

 

2020 Content Creation User Group week #2 summary

Elvion, November 2019 – blog post

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

Current Status

  • The EEP RC viewer updated to version 6.4.0.534193 on Thursday, January 9th.
  • Bug fixing continues, notably around alpha rendering issues.
  • It is believed there are about a dozen remaining issues to be dealt with before EEP may be ready for formal release.

Pathfinding

First introduced in 2012 (and developed over the following year), Pathfinding was intended to provide a means for more interactive non-player characters (NPCs) in Second Life. Unfortunately, the implementation of the system proved to be so cumbersome (and leaving aside some of the incorrect perceptions about Pathfinding on the part of land holders), the it has never really seen that much use in Second Life.

With the arrival of Animesh, there has been renewed interest in using Pathfinding in conjunction with Animesh characters, but again, the current implementation is proving a bottleneck (e.g. highlighting / indicating “walkable” areas in the viewer; whether the navmesh is actually visible; the effort required to Pathfinding, etc.).

  • A forum thread highlights the issue, and it has been suggested that if a Jira can be raised highlighting the specific problems, it might be something the Lab could take a look at to try to improve some of the visualisation issues within the viewer (Navmesh visibility, etc.).
  • However, a broader pass at improving / overhauling Pathfinding is not on the Lab’s current road map for SL.

Pathfinding Resources

In Brief

IP rights, UV Maps and “working copies”: there has been recent discussion on the forums, through various user groups (notably Governance, which I’ve been unable to attend for the last couple of months due to RL) concerning IP rights and things like mesh VW maps, compatibility, weight painting etc. The questions have arisen of late due to a mesh appearing on the Marketplace that achieves compatibility with all the other meshes of the same nature by providing amazingly close replicas of them.

Currently, the primary course of response to concerns over potential infringement – imperfect is it may appear to be where this issue may be more esoteric in nature, given that the meshes in question all tend to use things like UV maps derived from originals supplied by Linden Lab – is for a creator with concerns over infringement to file an DMCA complaint with LL.

BOM take-up: Bakes On Mesh take-up is seen as being a little slow. Some mesh body / head makers have yet to fully adopt BOM flagging on their products for example (so while Maitreya support BOM on their current body via a HUD, the body still has some 800 individual mesh elements that the viewer needs to handle, compared to the (roughly) less-than-fifty used by the Slink Redux (BOM) body). Also, there are continued concerns about BOM’s ease-of-use when compared with the use of HUD-based applier systems. While the latter can be more resource-intensive, the form is seen as requiring better scripted tools and / or better inventory visualisation mechanisms (even better base alpha support) in order to be more attractive to users.

Next CCUG meeting: Thursday, January 23rd.

 

2019 Content Creation User Group week #51 summary

Last Dove, November 2019 – blog post

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

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 **

 

2019 Content Creation User Group week #50 summary

Shadowlands Retreat, October 2019 – blog post

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

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.

2019 Content Creation User Group week #46 summary

Kinglet Sound, September 2019 – blog post

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

Current Status

  • Merging with the last set of viewer releases has caused issues, and these are currently being addressed.
  • Beyond the above issue, clearing the remaining EEP bugs is “a priority focus”.

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 providing a means for data collection across a range of different viewer-side hardware specifications.
  • His previous work on textures and texture handling / loading have revealed it is hard to quantify in terms of accounting for performance impact, as textures don’t result in the same kind of impact as mesh triangle complexity.
    • With mesh, there is a clear complexity correlation between the number of triangles and performance /  complexity hits.
    • The number of textures on a object don’t behave the same way, other then during initial loading or if they push against memory limits, so, there’s no gradual degradation in performance with texture that can be seen with mesh, making it harder to produce accurate calculations.

Avatar System

The avatar system has become considerably more flexible over the years, but also far more complexity to use. Given this, Vir put out a question on whether there is anything creators would like to see Linden Lab do in terms of managing the avatar behaviour and configurability.

For example, one aspect of avatar system management is HUDs, which can be impactful in a number of ways  – resources simulator side, texture use viewer side; general ease-of use. Discussion on this raised some suggestions ideas:

  • Presenting them through (if possible) a dedicated floater in the viewer that could be dragged around like any other floater, minimised, etc.
  • Possibly extending llDialog to prove better support for HUD-like actions via dialogues.
  • Providing an HTML-based means for HUD-style interactions.
  • Having a “favourites” inventory folder sub-set, floater and toolbar button, a-la Firestorm that users could use for their various HUDs and (hopefully) encourage them to only attach (via the toolbar button / floater) when required – thus assisting with reducing VRAM usage for users / eases resource loads when avatars move between simulators. This idea has been discussed at the Lab.

A further discussion on this involved avatar shapes and applying / managing parameters.

  • Currently the body shape is a “container” for all body parameters (head shape, body size, leg length, torso dimensions, etc).
  • This can make it hard when trying to carry out localised modifications to a part of a body (e.g. applying head parameters to a “preset” shape designed for a specific head brand).
  • There have been suggestions to help improve this, including:
    • Providing a means of exporting specific shape parameters for making new body shapes (see feature request BUG-216131).
    • Manipulating the shape via LSL (not seen as necessarily user-friendly).
    • Having some form of wearable that can be associated with specific body area parameters so that when used, would cause the currently worn body to adopt those parameters.
    • Provide a means to support some kind of “mask list” that just governs which bones they affect. This would allow for quite arbitrary sub-sets (as defined by the shape creator), but is seen as not that user-friendly, and potentially introducing added complexity into shape manipulation.
  • Some of these suggestions have a potential hit with increased UI complexity, but the idea of having explicit sub-set of shapes (e.g. one for the head, one form the upper body (or torso), etc.,) that have an obvious link to the sliders they would affect / be affected by, would seem to be the easiest for users to understand.
  • To address the head issue noted above, the most direct solution would be to separate the head shape from the body.

Other Items in Brief

  • Rider Linden is working on the texturing download and caching updates for the viewer, but these have run into merging problems with the current release viewer, so there is nothing available for public consumption on this work.
  • Several creators have noted issues with Bakes on Mesh and the left arm / leg, Universal wearables, tattoos and skins (see this forum post as an example, together with this feedback thread post). No precise solution has been offered (there has been a suggestion for LL to provide a means to convert existing skins to universals for left arm and left leg, but it’s not clear how well this would work in practice).

2019 Content Creation User Group week #43 summary

Breath of Nature, September 2019 – blog post

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 Copy / Paste project viewer adds buttons for copying the X, Y, Z co-ordinates for the Position, Size and Rotation of an object to the official viewer’s Build / Edit floater, offering a similar capability to that provided by TPVs

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:
  • 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 Muscadene 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

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.