Category: SL User Group Meetings

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.