Category: Content Creation User Group

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 29th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

Animesh Project

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

Current Progress

Vir now has a proposed revised land impact / tri count formula and test plan for Animesh. This will be going to QA, and if all goes well, the new formulas will be deployed on the Aditi Animesh test regions ready for public testing. No end-date for public testing on Aditi has been defined – the Lab want to ensure as many as are interested have to opportunity to test the new formula. Animesh attachment will remain limited to one per avatar, at least for the time being.

It is likely that server-side support for Animesh will reach the Main grid ahead of the project viewer reaching release candidate status – although this still won’t be for a while.

LODs and Streaming Costs

How Animesh Level of Detail (LOD) is handled is still being tweaked. Currently, Animesh objects sit between in-world objects and avatars in terms of the way their LODs are handled / swapped. The Lab is looking to adjust this, so that Animesh LODs are more consistently handled as they would be for in-world objects.

The broad plan is – for Animesh only – that the lower LODs will not affect streaming costs so long as they are not disproportionately large. Providing they get smaller by at least a factor of approximately 2 as they go down to the courser LODS, they will not impact streaming costs.

Note this work is not part of Project Arctan, which may lead to further changes in costs associated with objects at some point in the future – see below for more.

Project ARCTan

This is the code-name for the project to re-evaluate object and avatar rendering costs (e.g. Land Impact and avatar ARC), led by Graham Linden as a part of the overall rendering system work. The aim of is to have the costs assigned to objects and avatar more accurately reflect the impact they have on people’s viewer performance.

The hope is that overall, by making a careful set of adjustments, not only can client-side performance be improved, but creators can be given positive incentives to build more performant content (a problem currently being that providing good LOD models – high, medium, low and very low – for mesh content can actually penalise a creator in terms of upload costs / Land Impact, encouraging them to skip doing so).

This project is still in the early stages, and the Lab is fully aware of the risks and concerns involved in potentially making changes to things like Land Impact (e.g. undesired object returns), and so are approaching the work cautiously. Right now, data is being gathered and internal comparative testing is being tried. There are no plans to make any kind of changes in the immediate future. When changes do start to be made, they will be done so carefully to avoid disruption, and users will be appraised of what is happening and when.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing baking service.

It is important to note that this project is still in its preliminary stages. Any release of a project viewer doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Current Progress

The project viewer is still with QA with a couple of outstanding JIRAs awaiting resolution. The hope is that it will be making a public appearance soon.

When issued, this viewer should work anywhere, as it doesn’t require simulator changes. However, only those using the project viewer will see things as intended. Anyone on a viewer without the Bakes on Mesh updates will see placeholder textures, rather than the intended baked textures, on avatars trying the Bakes on Mesh capability.

Bakes on Mesh will essentially use the three avatar elements used by the baking service – head, upper body, lower body, eyes, hair, skirt), and applies clothing bakes for those elements to specific mesh faces, effectively “hiding” the corresponding base mesh region. This means for example, a head bake can be applied to a mesh head, an upper body to the mesh upper body faces, etc.  It does not at this point allow for more finely tuned applications – such as an individual jacket layer, or just to the hands.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements involving simulator and viewer changes, and includes some infrastructure updates.

Current Progress

Rider is still engaged on infrastructure work, which he hopes to complete Soon ^TM. Once that is done, he’ll complete the work on assets in inventory.

Custom Pivot Points

Work is being carried out to provide custom pivot points for mesh objects (see BUG-37617). This will most likely appear in a Maintenance RC viewer, once ready. The exactly implementation details weren’t clear at the meeting; it’s believed the data for the pivot point is coming from the corresponding data for the highest LOD in the uploaded .DAE file. However, the pivot point must be inside the bounding box of the object, and remains the centre of the object. Steps will also be taken to prevent pivot points placed outside of the bounding box simply causing the bounding box to increase in size (as did happen in a mesh uploader error), as this tends to both increase the objects LI by a factor of at least 2, and break the associated LODs.

Other Items

Texture Caching

Work continues on trying to improve texture caching in the viewer – which has already been an educational process for the Lab. There is nothing on the horizon yet in terms of updates for the viewer, as the work is not seen as a high priority when compared to other projects. However, there is a belief that there is room for “dramatic improvement” in the way textures are managed.

Permissions System

The question was asked if there are any plans to re-work the Second Life permissions system to be more supply chain driven, as is planned for Sansar. Short answer: there are no current plans to overhaul the permissions system simply because it is so complex. Currently the only thing being considered with permissions is extending them to allow scripted permission changes (formerly known as mod keys), which are seen as important for enhancing Animesh capabilities. However, here are current no time frame in when / if these will be implemented.

Firestorm RenderVolumeLODFactor Setting / Object LOD Confusion

Some appear confused by the recent RenderVolumeLODFactor behaviour change (see here) and what it is doing, believing it is part of a change to object LODs in Second Life.

Essentially, the Firestorm update is purely a viewer-side change only, intended to encourage users not to use over-the-top settings in their viewer which can affect performance, because changes to this value are globally applied, affecting all objects within the viewer’s field of view, not just a specific wearable or object.

However, this change does not mark any kind of change to the object’s LOD data held on the servers (the content isn’t being “changed” in any way on the back-end); it purely alters the way content is rendered by the viewer in terms of which LOD model of the object it uses.

Date of Next Meeting

There will be a CCUG meeting on Thursday, April 5th, as the normal LL internal meeting has been postponed a week.

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 22nd, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures on avatar meshes.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

It is important to note that this project is still in its preliminary stages. Any release of a project viewer (see below) doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Project Viewer

• QA testing revealed a number of bugs which need to be addressed before the project viewer reaches public consumption.

EEP and Atmospheric Shaders Work

Environment Enhancement Project (EEP) Summary

A set of environmental enhancements, including:

• The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
• New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current status: Rider Linden is working on some internal fixes for EEP which should hopefully move it closer to public visibility, and there is some more infrastructure work to be done.

Atmospheric Shaders Work

A project to revamp the viewer’s atmospheric shaders and rendering.

Current status: Graham Linden indicated “good stuff” is in the works, but nothing he can publicly report on as yet.

Animesh Project

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.
• Will not support its own attachments in the initial release.
• Will not initially include the notion of a body shape (see below).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

Current Progress

Vir continues to work on performance profiles, and is “pretty close” to having something for Land Impact, with a formula under evacuation. Among the changes, this formula calculates scaling differently, and Vir notes there are a number of corner cases which need to be dealt with. The tri count cap will also be finalised alongside the updated LI formula.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

Vir Linden agreed that this is a problem, and that forcing abnormally large avatar bounding boxes is undesirable. In some places, the Lab tries to use the rigged mesh wireframe as the basis for the bounding box, which is seen as a little more robust as it is looking directly at the triangle data, rather than working off of the avatar itself – and this is the approach being considered with Animesh to avoid similar issues with Animesh rigged mesh failing to correctly LOD in the viewer – however, so believe the use of such static data is “meaningless”.

JIRA “Accepted” Status

The “Accepted” status on the JIRA still causes some confusion. In brief:

• For BUG reports, Accepted tends to mean the Lab have imported the report for evaluation / agree to there being a bug and will look to fix the issue. When it is addressed is dependent on a number of factors (e.g. severity of the issue).
• For feature requests, Accepted means the Lab is sufficiently interested in the idea to want to track it. It does not mean the idea will be implemented, either in whole or in part. Whether it is implemented in whole or in part again depends on a number of factors (how it sits within the current workflow, whether or not it is related to work being carried out and can be added to it; whether it is something which might be implemented alongside of upcoming work; whether it is better to hold off until it and other ideas like it can be implemented together as a project, etc.).

Return of Last Names

The last portion of the meeting focused on the recent blog post from Linden Lab indicating Last Names would be returning to Second Life. Given the level of interest in this project, I’ve written a separate update on this section of the discussion. See:  The return of Second Life Last Names – update with audio.

In Brief

• 

  Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette). Graham Linden indicated that this is something the Lab plans to fix, but the work has yet to be scheduled.

• Switching mesh asset on the same prim root: this used to be supported via script, but was removed due to people using it to create flipbook style animations which could adversely affect performance. It’s been suggested that it could offer an alternative to performance-impacting alpha swapping on meshes; however, the Lab’s view is that while alpha swapping is performance impacting, switching entire mesh assets would still be more of a performance hit, as the latter requires all of the geometry data associated with the mesh to be rebuilt every time.

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 8th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

Animesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.
• Will not support its own attachments in the initial release.
• Will not initially include the notion of a body shape (see below).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

Viewer Update

An updated to the Animesh project viewer occurred on Wednesday, March 7th with the release of version 5.1.3.513013. The focus of this update has been bug and crash fixes (e.g. correcting some of the issues of LODs getting stuck).

Current Progress

• The major piece of work to be completed (other than further bug fixing) is performance profiling: looking at possible limits on tri count, LI, to ensure Animesh can scale across regions without becoming a major performance impact. This work takes object scaling into consideration.
• Remaining bugs to be resolved include the animation timing issue, whereby an avatar entering a region were an Animesh object is already running may not receive the animations updates for the object. This is liable to require both viewer and server updates to fix.

Body Shapes

Providing a notion for Animesh objects to have a body shape is being considered as an initial follow-on for the project. If implemented, this would mean that Animesh creations could:

• Make use of the shape sliders.
• Utilise the Appearance / Baking Service.
• Have a fully avatar-like inventory.
• Make use of the server-side locomotion graph for walking, etc.

The assumption is that if the Lab look to add this functionality, it will be handled in much the same was as is the case for avatars. However, this aspect of the work will be opened up for discussion and ideas once it has been officially adopted as a follow-on project, rather than having speculative (and premature) discussions about how body shapes might be applied / managed.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures on avatar meshes.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

It is important to note that this project is still in its preliminary stages. Any release of a project viewer (see below) doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Project Viewer

• Currently with the Lab’s QA team.
• Will support a basic means of applying system bakes to mesh faces, although their will be caveats as to how well this initially works (e.g. matching to mesh UV maps).
• The majority of this work is viewer-side, allowing mesh faces to be flagged with a special texture ID which allows a specific part of an avatar bake to be applied to them.

Feature Request JIRA

It is recognised that there are numerous questions / concerns relating to Bakes on Mesh (see my week #8 update). Because of this, and the lack of a specifications document, user Elizabeth Jarvinen (polysail) has started putting together a Feature Request JIRA outlining some of the specifics which need to be considered with regards to the project. Some of the ideas offered might be considered as a part of the initial Bakes on Mesh project, so might be left for a follow-up project. For more information on this follow the links below:

• Feature Request JIRA: BUG-214631.
• Additional information: BUG-10980.

Project Arctan

This is the code-name for the project to re-evaluate avatar and object rendering costs (avatar complexity and Land Impact). Again, just to be clear on this project:

• It is only just starting.
• The aim is to make avatar complexity and Land Impact values more reflective of the actual “cost” to render avatars and objects. This might lead to ARC / LI values changing.
  • However, there are currently no details of how LI / avatar complexity values may change or when, as the Lab is still gathering data at this point in time.
  • The Lab is aware of the potential for increases in LI values to cause disruption, and if this is the case, they will seek to minimise the impact as far as possible.
• The work is not related to Animesh – which will see a “basic” cost (in terms of geometric complexity) applied to Animesh objects (see performance profiling, above). Animesh objects may be subject to further revision as a result of Project Arctan’s findings.
• It is hoped that Graham Linden, who is leading the project, will attend future CCUG meetings to discuss Arctan as the project progresses.

Other Items

• PBR Shaders: there have been requests for the Lab to implement physically based rendering (PBR) – using realistic shading/lighting models along with measured surface values to accurately represent real-world materials. Such requests have been noted by the Lab. While adding support for PBR shaders has not been ruled out, it is seen as a significant undertaking, and is thus seen more as a “someday, maybe” piece of work, rather than being a part of the current SL enhancement roadmap.
• Terrain texture improvements: terrain textures in SL suffer from a low texture density, causing blurring, etc. Again, the Lab is aware of this, and considering making improvements to terrain texture as a possible future project.

Next Meeting

The next CCUG will be on Thursday, March 22nd, 2018, and 13:00 SLT.

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, February 15th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni streamed the meeting, and his video is appended to the end of this update. Timestamps in the text will open the video in a separate browser tab at the relevant point in the meeting. As always, these notes cover the core points of discussion, and my thanks to Medhue for recording it.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures on avatar meshes.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Status

• • A reminder that this will not initially include Animesh as the Baking Service requires an avatar shape, which Animesh currently does not support.
  • There is a lot of confusion about this project and what it will do, so an overview document has been suggested.
    • One example of some confusion: Anchor linden mentions being able to “upload 1024 textures” – this is actually a reference to the Baking Service supporting 1024×1024 textures, not to users uploading 1024 textures (because they are already supported).
  • [5:21] The target date for completing this first phase of this work is the end of March 2018.
  • [12:09-22:15] Alpha layer and Alpha masking discussion:
    • [12:09-13:55] A means to hide the system avatar has yet to be determined, but Anchor hopes to focus on this in the course of the next week.
    • [13:06-15:44] One suggestion for this is to have a new “avatar” alpha mask which would allow specific parts of the system avatar to be hidden in a similar manner to how it is currently handled (e.g. to allow the body to be hidden when using a mesh body, but the head exposed, for those not using a mesh head).
    • [13:55-15:44] These updates should allow elements of a mesh body to be hidden much as can be done with the system avatar, possibly eliminating the need to break the avatar into multiple faces which can be individually masked. However, this has yet to be tested.
    • [19:05-22:15] Repeat that alpha layering via the Baking Service (e.g. make-up / tattoo layers), and full alpha masking (e.g. hiding an entire body / body part) should work with mesh avatars exactly the same was as for system avatars at present (again, as per above, without the need for the mesh itself to have multiple faces which can be individually masked).
  • [22:56-24:46] Clothing layers when applied to a mesh body should hopefully work as per the system avatar (e.g. “jacket” layers are applied over “shirt” layer, which are applied over “underwear” layers, with the last worn item in each layer being uppermost and the most visible.

• [25:56-27:37] Discussion on wearable layers for specific mesh models, branding and creator / user understanding.

Project ARCTan

[3:55-5:03] This is the code-name for the project to re-evaluate object and avatar rendering costs. It also now falls under Graham Linden’s leadership as a part of the overall rendering system work.

[32:02-34:06] Oz explains the function of the project, and the fact that originally, the weightings (land impact / avatar complexity) applied to avatars and in-world objects, were somewhat biased to allow for the simulator having to handle a lot of texture, etc., transfers to the viewer (so for example, avatar complexity include texture counts, LI doesn’t). As all of this data now goes via the CDNs, rather than the simulators, this bias can be removed, and the actual costs of rendering complex objects made (hopefully) a lot more accurate and thus promote better content creation.

[34:48-35:48] There are currently no details of how LI / avatar complexity values may change, as the Lab is still gathering data at this point in time in order to make informed decisions on how best to revised the calculations.

[35:51-37:04] For Animesh this means the project will be released with an initial land impact calculation assigned to it for objects. However, as with the rest of SL, these may be subject to change as a result of the work on Project Arctan. See this Animesh forum comment from Vir for more.

• [39:59-43:30] In brief: the value for Animesh will primarily be based on tri count based on the high detail LOD version of the mesh, with Medium,, Low and Lowest having less of an impact in pushing up the overall LI. This will be added to a basic cost component for driving an avatar skeleton (uniform across all Animesh objects). Again, no precise values are available as yet, as LL are still performance testing.

[37:07-39:40] Land Impact: obviously, Land Impact changes are potentially disruptive. To ease this, the Lab plan to add code to the simulator and the viewer to calculate the new LI values but not enforce them. Instead the data on LI using the new calculations will be gathered with data on the existing values, and the Lab will then assess how many parcels they might push over their LI capacity (and thus force object returns) and by how much, were the new values to be enforced. Depending on the overall impact, they will look at increasing region land capacity to compensate to some degree.

So, for example, if the new calculations so parcels will on average go over their LI limit by 10% under the new calculations, region LI might be increased by 15% to compensate. Then, for those who still exceed their limit, there will be a period of grace when then can consolidate and bring their LI use within the limit of the revised calculations before the latter are enforced.

Overall, the Lab is extremely aware of the risks in altering LI values, and will be approaching this work carefully to try to avoid it having a major negative impact with object returns, etc.

Animesh Updates

• Some of the Animesh test regions on Aditi (animesh1 through Animesh4, Animesh Adult and Animesh XL, have become more sandbox than testing areas (including being used for non-Animesh items). To prevent this, the regions are to start being cleaned-up, auto-return made a little more aggressive and warnings that they are only for Animesh are to be added to the About Land descriptions.
• [50:52-51:50] Worn Animesh Limit:  there shouldn’t be an LI cap on worn Animesh, although the limit of only wearing one Animesh at a time remains in place pending performance testing results.

Other Items

Rendering Improvements and Fixes

[2:10-3:50] The Lab recently split work on the viewer’s rendering pipe into a separate viewer development branch (Project Render, with a project viewer – version 5.1.1.512446, dated February 9th at the time of writing – currently available).  Graham Linden, a long-time Linden, will be working on rendering updates more-or-less full-time going forward. He’ll be looking at things like increasing rendering stability, fixing bugs, and potentially other aspects of the rendering system.

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 18th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video for this meeting, as Medhue missed the first 30-ish minutes. Audio extracts are supplied instead, where relevant.

Animesh (Animated Mesh)

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

Viewer Update

The Animesh project viewer updated on Thursday, January 18th to version 5.1.1.511908. This includes a merge up to the Alex Ivy viewer code base, and so is only available for Windows (32-bit and 64-bit) and Mac OS X (64.bit). A number of updates are also included with the viewer:

• Reduced lag when zooming in and out on some models.
• Improved rendering performance when preview wireframes are displayed.
• Some diagnostic updates and performance fixes.
• In mesh upload, allow underscores in joint names to substitute for spaces.

Performance Profiling / Animesh Limits

As promised in the week #2 meeting, a region has been set-up on Aditi for public Animesh performance profiling which has a tri cap that can be varied (called Animesh XL), allowing it to be set higher than the 50K limit found on the other Animesh regions on Aditi. The Lab has internal regions set-up for performance profiling as well.

There has been a request for a triangle count and/or skeleton count per square metre limit, rather than the triangle count and land impact limits the Lab are currently experimenting with. Vir concedes that this may give a similar result to the Lab’s approach with tri count and LI, but also notes that people are already pushing tri counts to the limit, and he’d rather have something that helps push towards more optimised content creation. He also notes that tri count isn’t the only potential performance impact  – texture use, for example can also have an impact – so it’s a case of finding the right balance and ensuring that balance uses figures which are easy for creators / users to grasp.

The tri count limit is per object / linkset for Animesh, and is something of an approximation based data specifying the size of an object, in order to avoid having the simulator having to carry out all the triangle count calculations (and possibly impacting simulator performance). The resultant figure does under-estimate of the actual number of triangles within an object / linkset – but not, Vir believes, by a huge amount.

One issue around performance is avatar attachments, which don’t directly count towards region limits in the same way as things like LI, but which can still have an impact on performance (as can be seen with avatars wearing a lot of high-poly mesh attachments). However, re-working how attachments are handled specifically for Animesh is considered problematic, and unlikely to be re-worked (and so is being handled by a straightforward cap on how many Animesh attachments can be worn at one time – initially 1 for testing purposes) .

Animation Playback Issues

It’s been noted that animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This appears to be a race condition, with the viewer receiving information on the animation before it has rendered the object being animated, resulting in the animation being ignored. Vir is confident that now the cause has been found, the issue can be fixed.

There is also an issue related to the Interest List where an Animesh object in a neighbouring region fails to update (animate), even when in your field of view and draw distance.

Both of these issues are still being investigated.

There is a claim that animations fail to play when an Animesh object is attached directly from inventory. This is something that isn’t being seen by the Lab, and which might be down to code within the animation script itself, or could be an issue. Vir has requested a JIRA specifying the problem and how to reproduce it.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

Vir believes Anchor Linden has resolved the issues around getting the appearance service updates out.

Other Items

Screen Release Estate and Multiple Monitors

The Second Life viewer is constrained to the window / screen on which it is being used: however many floaters and panels a user opens, they can only be displayed in the one window / screen, which can quickly become crowded. This had led to various suggestions on how the issue of screen real estate use might be improved, including:

• Making floaters and panels so they can be displayed outside of the main viewer window. Firestorm actually developed a proof-of-concept model for this several years ago. However, it was just an experiment, and the overall functionality was limited. The idea was thrown open to allow viewer developers to work on the idea, but the complexity of the work meant it was never carried forward.
• Altering Second Life so that more than one viewer session can be run from the same account at the same time: the idea here being that a use with multiple monitors could log into SL with their account, position the viewer on one screen, then log in again with the same account, and have that viewer instance on a second monitor – so they could use one for all their chat and inventory floaters, while have a clear in-world view on the other. This would require extensive changes to the back-end of SL, and so is potentially even more complicated than making the viewer floaters work outside of the main viewer window.

Next CCUG Meeting

Due to various conflicts, it appears that the next CCUG meeting will not be until Thursday, February 16th, 2018. However, as this has yet to be confirmed, the best thing for the next 2-3 weeks is to monitor the CCUG wiki page for updates and meeting notifications.