Category: SL User Group Meetings

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 4th, 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 live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

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

General Project Status and “Must Dos” List

[33:24-34:10] There are around 14 “must do” items remaining on the list of work to be completed for Animesh before it can really move towards release. Some of these are fairly major – such as performance profiling (tri, count, LI, etc., limits evaluation, and so forth). There are also a number of bugs to be fixed or determined to be trivial enough so as not to prevent Animesh from moving to release / require work outside of Animesh.

Bug Stomping

[1:12-1:54] Animation Playback issues: as highlighted at the December 14th meeting, 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. It now appears this is a race condition issue, 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.

Shadow Rendering Issue

[3:33-13:52] There has been a long-standing issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by the latter to render incorrectly (shadow rendering conforms only to the geometry silhouette). Animesh can exacerbate this issue on some objects (note the image of the tree on the right, and how the shadows of the leaves (faces using transparencies) are render.

As this appears to be a rendering pipe issue, rather than a specific problem with Animesh, it may require investigation and resolution by those handling viewer rendering pipe issues, If so, this could take time to complete, and so is currently being viewed as outside of the current Animesh project, and not a blocker to any initial deployment of this phase of the Animesh work.

“Dropping” Animesh / Mesh

[43:12-47:25] As previously noted in these updates, worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This makes the ability for people to pick up Animesh pets, carry them, then put them down in-world awkward.

The Lab’s view is that as dropping mesh directly in-world was never considered, the code-path for achieving this is not clear, touching as it would on a variety of elements: land impact calculations, physics updates, etc; there’s also a risk of forcing users to re-log should a No Copy pet be dropped and fail to rez in-world, in order for it to correctly register in their inventory again.

However, pets are seen a major use for Animesh, so not having a means by which they can easily be put back down in-world after being carried is seen as a potential limitation in the adoption of Animesh by pet creators; as it is, many have kept to using (render-intensive) sculpties with their pets, simply so they can retain the ability to pick them up and then put them back down in-world, rather than having to force users to detach and re-rez the pet after holding it.

The issue is again being that back to the Lab for further discussion.

In Brief

• [14:49-17:12] Global scaling and resizing: not something that is going to be implemented for Animesh with this initial work, but may be added later. It is possible to get the effect of global scaling on a rigged object by scaling in joint in the hierarchy individually, but this may not give consistent, expected behaviour.
• [17:32-20:29] Setting position and rotation of rigged meshes: slight confused discussion on whether rigged mesh attachments can be re-positioned / rotated. Generally, rigged meshes cannot be re-positioned / rotated as their the vertices are recorded to set distances from the avatar bone. However, Animesh attachments (which have their own skeleton) should be capable of position / rotation changes releative to their attachment points.
• [20:44-24:40] Slider support for Animesh: avatar shape sliders are not supported in the initial Animesh work, as these require a shape to be associated with an object which, as per the summary notes for the project (above), is considered a possible Animesh follow-on project. For this phase of the work, shape changes can only be defined by setting joint positions / using animations. The reason why shapes, sliders, etc., are seen as a potential follow-on project is that they will require an extensive overhaul of the baking service (which manages appearance information), so that it recognises Animesh objects and can handle them.

Continue reading “2018 SL UG updates #1/2: Content Creation User Group” →

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, December 21st, 2017 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 live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. However, the first part of the meeting is absent the video, so I’ve included two audio extracts of salient points raised, taken from my own audio recording of the meeting. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

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

Bug Stomping

• Animation Playback issues: as highlighted at the December 14th meeting, 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 had been considered a viewer issue, but could equally be a simulator / viewer race condition wherein the viewer is receiving animation information before it knows what to do with it (and so is ignoring it). Vir is still looking into this.
• Object Selection issues: this isn’t just an Animesh issue per se. Historically, selecting multiple animated objects (or an avatar) so they are displayed as wire frames has been handled “extremely inefficiently”, impacting local frame rates. A fix is in hand for this, and will be in the next update of the Animesh project viewer.

Animesh Release ETA and Limits

There is still no indication of a release date for Animesh. Work still to be completed / carried out includes:

• Bug fixing, including the two issues noted above.
• Performance profiling (tri, count, LI, etc., limits evaluation, etc.).
  • It is worth repeating (again) that the current limits of tri count, LI, and number of attachments are purely for the purposes of performance testing, they are not the “final” limits for Animesh, some of which will hopefully be somewhat more relaxed / reflective of server / viewer capabilities when scaling Animesh use within a region.

The initial tri count limit (again, set for testing purposes only) was increased from 20K to 50K with the current project viewer release (version 5.0.10.330058, at the time of writing). As noted in my week #50 update, this increase had been requested for some time – although it appeared to be wanted more for testing proposed Animesh products, rather than testing the basic Animesh capabilities. Zooby’s has since issued a video of one such new product, involving both a wearable cat avatar, and which is also intended to support the avatar being used as an in-world Animesh object, once Animesh is released.

Animesh Use Cases

The focus for Animesh among creators thus far has been for avatars (NPCs), and creatures, pets and things like mechanoids (both free-roaming and wearable). However, there is potential for Animesh to be used for landscaping as well: tree boughs / grass moving in the wind, water features, etc., and the Lab is interested in discovering how much appetite there is among creators to use Animesh in this way, particularly when it comes to profiling performance and limits.

Skeleton Use and Bone Naming Convention / Parenting

An extensive discussion on using the skeleton bones.

[0:00-10:36] When talking in terms of unique Animesh objects, the skeleton can be re-purposed to suit the need, and not all the bones need to be animated. So, for example, in a grouping of plants, the leg, arm, wing, and tail bones could be used to animate individual plants (in principle, individual finger bones could be used).

As with any use of the skeleton, the important aspects are preserving the recognised bone naming and parenting hierarchy (although it is possible to constrain bones  / bone groups for specific uses within Blender, then map this back to the SL skeleton, but it requires care and attention with a thorough understanding of the SL avatar).

This is where Animesh is attachments such as hair is of an advantage over hair that simply uses with avatar’s own skeleton. With the latter, the available bones are limited without potentially impacting the ability to wear animated hair with a Bento head (although there are “spare” ear and eye bones which could potentially be used to create an animated ponytail or pigtails).

Using a separate range of bones in Animesh hair offers greater flexibility – but then the issue becomes keeping the animations in the Animesh hair in sync with the movements of the avatar wearing it.

“Dropping” Animesh / Mesh

[11:50-15:31] Worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This has been seen as limited with Animesh pets, etc., where ideally people might want to pick a pet up and carry it and then put it down again (drop it). Making it possible to drop mesh is seen by the Lab as “kind of a hassle to do”, but it’s not currently clear how big or small a hassle it might be, as it would involve additional land impact calculations, physics updates, etc., none of which were given support when mesh was introduced. Thus, it could require  an extensive simulator-side overhaul.

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 mesh surfaces. 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

Viewer work has paused while some back-end baking service issues are resolved.

Other Items

How the Lab looks at Features

One oft-phrased point-of-view is that the Lab “only” think about features being used in a certain way – and this has at times been voiced for Animesh. Speaking at the meeting, Oz Linden sought to dispel this idea, pointing to the diverse ways capabilities are frequently used in SL.

 

Mesh Uploader

[18:15-22:44] Cost calculation issues: discussion on mesh upload costs noted in the viewer. These have long been an issues, where costs can alter due to the same model being automatically decimated differently with each upload, etc. These are most likely the result of errors in the calculations framework, and they are something the Lab is aware of, and might be the result of the removal of the SLM file from the uploader, which caused problems of its own. Those who wish to test whether the cost calculation issue is reduced by using the SLM file can do so by setting the MeshImportUseSLM debug to True.

[23:32-24:22] Mesh object names: Vir reminded people due to a limitation with Collada .DAE files mesh objects for upload via the official viewer cannot currently have spaces in their names. However, the Lab will be adopting the Firestorm work-around for this by allowing the use of underscores in object file names.

Bone Offsets

[26:44-29:18] Bone offsets: Vir points to an issue he encountered with an avatar model using a 75m offset for the mPelvis bone which, every time the offset was calculated, would cause the object to vanish from his screen until Reset Skeleton was used. This prompted the question whether should bone offsets have a constraint of bone offsets – such as no more than 5 metres, as is the case when offsetting using animations.

SL Viewer

• The Wolfpack RC viewer (containing no functional changes to the current release viewer) updated to version 5.0.10.330113 on Wednesday Novermber 20th, 2017.
• Nalewka Maintenance RC updated to version 5.0.10.330123 on Thursday, December 21st, 2017.

These likely mark the last viewer updates for 2017, leaving the rest of the viewer pipeline as follows:

• Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Alex Ivy 64-bit viewer, version 5.1.0.511248, December 11.
  • Voice RC viewer, version 5.0.10.330039, December 12.
• Project viewers:
  • Project Render Viewer version 5.1.0.511446, December 18.
  • Animesh project viewer version 5.0.10.330058, December 11 – project overview.
  • 360-degree snapshot viewer version 5.1.0.506743, June 29 – hands-on overview.
• Obsolete platform viewer version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.