Category: Content Creation User Group

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

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

Current Status

• Final review of issues is due on Friday, February 28th. If the project passes this review, the EEP will be cleared for promotion to release status.
• There is a viewer build that the Lab has internally that is liable to be the release version; it’s not clear if this viewer will go to RC prior to promotion or be issued as the de facto release viewer .
• It has again been noted that EEP will not give a precise one-to-one rendering of absolutely every environment (sky, lighting, etc.) in SL when compared to Windlight, as EEP uses a completely different and updated set of shaders, but it is hoped that most will be “very close”.
• Once EEP has has reached release status, it is anticipated that their will be a “fairly rapid” cycle of viewer promotions to clear the remaining RC viewers in the pipelines (i.e. one new promotion every other week).

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).

As of January 2020 ARCTan has effectively been split:

• Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations and providing additional viewer UI so that people can better visibility and control to seeing complexity. This work can essentially be broken down as:
  • Collect data.
  • Update ARC function.
  • Design and provide tool within the viewer UI (i.e. not a pop-up) that presents ARC information in a usable manner and lets users make decisions about rendering / performance.
• Work on providing in-world object rendering costs (LOD models, etc.) which might affect Land Impact will be handled as a later tranche of project work, after the avatar work.
• The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.

Current Status

• Vir believes he has a fix for the appearance  / Bake Service issue that has been causing problems with ARCTan testing. This has yet to be QA tested. Should it pass, then it will mean internal testing can resume.
• UI tools: one of the issues with the current ARC capability is how the information is presented and how it is interpreted. The question was therefore asked (by Vir) about possible ARC-related tools that could be incorporated into the viewer.
  • There are tools already in the viewer (Max Complexity Setting, Always Render Friends, etc.), although how well these are used is open to debate.
  • A concern with added further tools is that they could just additionally confuse for users (“more options and sliders!”) or just be ignored.
  • Automated  / semi automated means of adjusting complexity settings was favoured by some at the meeting.
  • The problem with full automation could be difficult to implement due to the broad variance in hardware used to access SL, the complexity of existing content (avatar heads, bodies, etc.), plus people’s personal preferences, etc.
  • A mechanism for adjusting  / bypassing an automated process could be provided, but then it defeats trying to automate as people will just opt to bypass a the process and ramp up settings.
  • An alternative might be to make the current tools more intuitive / easier to access and also more granular, then gradually move towards greater automation (with overrides) as people gain more familiarity with the whole issue of optimised content and performance.
  • A suggestion from the Lab was to have some form of “temporary” thresholds: such as when teleporting into a busy region switches to some form of frame-rate threshold / asset load prioritisation that helps to maintain a reasonable frame rate whilst also prioritising CPU cycle use to speed up the initial loading period, then switching back up when done. The complication with this approach is, not everyone has the same bottleneck areas, so a threshold setting that works well for some, might not show any benefit for others.
• Bound up with this is the question of educating users as to:
  • What tools are available and how they work (e.g. a capability one of those at the meeting was espousing as something that would be “nice” to see in the viewer, has in fact been a part of it for almost five years).
  • What actually is impacting their experience with SL (it is so easy to blame “the servers” and “LL” when actually many of the problems are in fact viewer-side and could be better managed by a user than might otherwise be the case).

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

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

Current Status

• Work is continuing to clear the remaining rendering bugs, which are being described as “resilient”.
• The hope is EEP could be ready to move forward by the end of the month.
• There is a backlog of potential fixes / enhancements for EEP (e.g. further rendering improvements, improving the brightness of stars, etc). Some of these will form future EEP enhancements, others may be dealt with as part of other work such as on-going rendering system improvements, rather than being held for a future EEP-specifc project”.

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).

As of January 2020 ARCTan has effectively been split:

• Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations and providing additional viewer UI so that people can better visibility and control to seeing complexity. This work can essentially be broken down as:
  • Collect data.
  • Update ARC function.
  • Design and provide tool within the viewer UI (i.e. not a pop-up) that presents ARC information in a usable manner and lets users make decisions about rendering / performance.
• Work on providing in-world object rendering costs (LOD models, etc.) which might affect Land Impact will be handled as a later tranche of project work, after the avatar work.
• The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.

Current Status

• Vir is still working on the Bake Service issue I’ve noted in my last two CCUG updates. However, he believes he now has a fix, and this is currently going through internal testing.
• One thing that ARCTan testing has shown is the degree of variability in frame rates in terms of how long each frame takes to process. Part of this might be due to multiple operations running in the same thread when they should perhaps be separated into their own threads, particularly in terms of avatar loading.

Project Muscadine

Project Summary

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

Current Status

• Still on hold, but the Aditi simhost that did have the back-end code has also been re-purposed for other project work, so the back-end support for Muscadine is currently unavailable.

In Brief

• Viewer caching project: this has been a long-term project, which has recently re-started (and which is usually a subject for discussion at the TPVD meetings).
  • There is code related to the VFS caching (referenced in the message seen at viewer-start up) the in in-memory processes that sit on top of it that has not been updated in a long while and which can give rise to stability issues.
  • The Lab now plans to work on this code “extensively” over the next few months.
• There are claims that use of Animesh impacts simulator performance. As Animesh is predominantly a viewer-side capability, it is hard to see how it could impact simulator performance; it is possible that those experiencing issues could be conflating viewer and simulator performance.
• Poser project: a contribution from the Black Dragon viewer, this is a project that is currently on hold.
  • The idea is to allow local (i.e. viewer side) joint-by-joint poses by entering different values for each of the required positions and rotations for a joint.
  • The fact that the tool is viewer-side with the results unseen by other users has been seen by the Lab as the project’s core limitation.
  • The Lab’s view is that the easiest way to share the results would be to place them in a single frame animation that puts the avatar into the required pose and which can be seen by other viewers, and this would like be the approach taken when / if the project is resumed.
  • This work has nothing to do with the pupeeteering project from 2011.
• A further project awaiting resumption is the move to HTTP 2, which will hopefully improve things like asset data fetching, offer improved stability in data handling and improve scene loading.
• Tidbit: the mesh uploader for Second Life apparently took around 10 people over 2 years to develop / get to work (and still has a UI element that might be incomprehensible to some). As such there is some concern at the Lab that attempt to extend SL to support other modelling formats (e.g. FBX) could result in something equally / more confusing – although this is not to suggest LL is resolutely against supporting other file formats for use with SL.

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

Note: this meeting was called at short order after the the usual start-of-month Linden Lab internal All Hands meeting was delayed a week. This means that a) the meeting was slightly shorter than usual; b) there will not be a CCUG meeting on Thursday, February 13th.

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

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

Current Status

• EEP is now in burn-down mode – which means more bugs are being fixed than are being reported.
• Again, as this project is drawing ever closer to a possible full deployment, now is the time for those who use windlights for photography or within their regions to test the EEP RC viewer and see if they can identify any potential issues / bugs.

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).

As of January 2020 ARCTan has effectively been split:

• Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations and providing additional viewer UI so that people can better visibility and control to seeing complexity. This work can essentially be broken down as:
  • Collect data.
  • Update ARC function.
  • Design and provide tool within the viewer UI (i.e. not a pop-up) that presents ARC information in a usable manner and lets users make decisions about rendering / performance.
• Work on providing in-world object rendering costs (LOD models, etc.) which might affect Land Impact will be handled as a later tranche of project work, after the avatar work.
• The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.

Current Status

• Vir has been working on the apparent Bake service issue noted in my last CCUG summary. Unfortunately, while he has ascertained it is something that can occur, it seems to do so entirely randomly and with no real consistency, making reproducing the issue in order to track down probable causes very difficult.

In Brief

• BUG-228153, “FAO Vir: Possible cause of greyness in bakes” reports a Bake Service issue, which is due to be looked at by the Lab. This is probably not related to the issue Vir has been seeing with complex attachments.
• A side on on the Bake Service: it is not only responsible for handling appearance bakes (textures), but also include calculations on shape, vertical positioning, etc., some of which must be calculated regardless of whether or not wearables are being used, and which can be affected by attachments containing position offsets.
• There have been a number of feature requests for follow-up Bakes on Mesh work. Some of these have been accepted. However, there are no plans to re-open BoM for further work in the immediate future.

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

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

Current Status

• EEP is now viewed as a priority for release by the Lab, with work progressing on the final bug fixes on the graphics side.
• The biggest change recently made is to remove the option to disable Basic Shaders in the viewer, on account of this option causing problems when trying to address other issues.
  • It is not believed this will impact users, unless they are running really old graphics cards that do not support (the now 15-year-old) OpenGL 2.0.
  • Note this is not removing the ability to toggle ALM off / on.
• Release is still being couched in terms of being in “about a month” – so possibly early March.
• 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).

Rendering System Improvements

Outside of EEP and in the future, the rendering team plan to spend time simplifying SL’s multiple rendering paths and options to make them easier to maintain going forward.

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).

As of January 2020 ARCTan has effectively been split:

• Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations and providing additional viewer UI so that people can better visibility and control to seeing complexity.
• Work on providing in-world object rendering costs (LOD models, etc.) which might affect Land Impact will be handled as a later tranche of project work.
• The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.

Current Status

• Testing has suggested that when an avatar attachment has a very high number of prims, there is a chance the avatar appearance does not get baked correctly – the number of prims effectively “chokes” the Bake Service.
  • The number of prims is reported as “north of 32”.
  • It appears to be the number of prims – not submeshes – in an attachment that cause the issue, but this is by no means certain.
  • It is not something that appears to have been reported via Jira, so LL is curious whether or not it is an artefact people may have witnessed.
  • A version of the internal Jira will be filed publicly by Vir for creators to look at.

Next Meeting

The next CCUG meeting will be on Thursday, February 13th, 2020.

Brief Notes from the January 29th open-Source Developer Meeting

These notes are recorded here as they may have longer-term relevance to content creation / viewer use.

• Linden Lab has identified improving the viewer UI / UX to be a high priority.
  • Initially, the focus will be on improving usability for users who are not yet familiar with the viewer (and/or SL in general).
  • A further aspect of the work will be making the number of choices available in many places smaller and making the terminology more uniform.
• The UI team is said to have “quite a list” of possible changes / improvements, some of which have come directly from TPV developers and through feature requests.
  • Additional feature requests are well – including illustrative mock-ups of idea, providing these are properly documented.
  • Please see my tutorial notes on filing SL feature requests, if required.

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

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

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 Muscadine 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.
• Work on providing a UI for in-world object rendering costs (LOD models, etc.) which might affect Land Impact has been deferred to a later tranche of project work.
• The belief is that “good” avatar ARC values 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.

 

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

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

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

• SL wiki Pathfinding Introduction.
• SL wiki Pathfinding Tool in the Viewer.
• SL wiki Pathfinding LSL functions.
• SL wiki Pathfinding Quck Start Guide.
• This blog: Pathfinding overview (2012).
• This blog: Pathfinding – Playing Inside Buildings (2012).

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.