2018 SL UG updates #2/2: Content Creation User Group

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 11th, 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).


Performance Profiling

[2:08-3:58] Work is now starting on performance profiling for Animesh to determine suitable limits (e.g. tri counts, LI, etc.) when Animesh goes live. This is regarded as being one of the last steps before the project moves to the main grid. As a part of this, Vir has been adding the ability to control the triangle count limits for Animesh objects on a per region basis. This will be used to set different limits on different regions for the Lab’s internal performance profiling, and a region with the capability will also be made available on Aditi for public testing, and details will be made available once the region is up and running.

Object Animations And Animating Animesh

[43:13-55:34] A convoluted enquiry requiring a feature request in order to be made clear, but appears to be a request to provide a means for object animations to override an Animesh object’s own animations. So, for example, an Animesh hamster could be placed into a treadmill, and the treadmill either override the hamster’s in-built animations (stored in the hamster object’s Contents tab of the build floater) and cause the hamster to run, in much the same way as in-world objects can override avatar animations.

Such a capability could offer additional flexibility for Animesh – if a creator brings out a new toy for a pet (e.g. the treadmill, above), a means by which the treadmill could override the pet’s behaviour would avoid the need to update the pet as well in order for it to make use of the new toy. It’s unlikely such a capability will be considered for this phase of Animesh; however, Vir has requested a feature request on the idea is filed, so it can be considered alongside other work in a future Animesh update.  Hopefully, any feature request will avoid the use of pseudo technical terms such as “faux permission system” and “reverse animation system”, which initially caused some confusion when the idea was raised at the meeting.

In Brief

  • [4:00-8:10] Performance (FPS) issues when camming on Animesh: there has been a report of some mesh items causing drops in FPS rates when converted to Animesh, leading to choppy camera motion for some. Vir has been looking at one of the models in question, and believes the problem lies with the recalculation of attachment overrides, which can be excessive and even be carried out when there is no change in the object itself. Improving when and how the calculations are handled should hopefully resolve the problem, which can obviously be exacerbated through models having more joint positions defined. The fix, once implemented – hopefully in the next Animesh viewer – may help with other instances where there is a performance drop-offs when camming / zooming.
  • [8:51-10:55] LOD Drop: this is not considered an Animesh specific issue. Essentially, Animesh objects are being treated by the viewer as if they are avatars, and so get a similar boost in LODs, which needs to be tweaked.
  • [31:02-33:29] “Dropping” Animesh objects (i.e. allowing avatar to put pets, etc., down on the ground, without having to detach them back to inventory first, then rez them in-world): as per my 2018 week #1 CCUG meeting notes, this is still considered too big a piece of work to add to the Animesh project, as it requires changes to a variety of elements: land impact calculations, physics updates, etc. It could also result in 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, such a capability for dropping mesh might be looked at again in the future.

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

[8:21-9:25] Anchor Linden is working on issues around getting the appearance service updates out. These include on problems specific to Animesh attachments. A setting is also being added which means that the texture resolution increase (to 1024×1024) isn’t applied by the baking service until there is a mesh surface requiring it. Work on adding further baking servers is also required to manage the compositing / baking load at 1024×1024. However, the updates are now available on Aditi.

[11:04-21:12] A further explanation as to what Bakes on Mesh is, born from expressed confusion over the term “baking” in terms of 3D rendering, and the fact that the current work only applies to meshes worn by avatars.

[21:22-26:00] Bakes on mesh for Animesh: this would be part of any “phase 2” work that follows-on from the initial work on Animesh, once Animesh objects have a formal inventory structure. This would be required in order for the baking service to be able to recognise and use textures with Animesh objects. Includes a discussion on how the baking service currently works.

Other Items

[1:14-2:03] Mesh uploads: recognising linkset object names: as mentioned in my previous update, when uploading mesh objects, only the name of the root item in a linkset is recognised, everything else is simply “object”, rather than carrying over any naming convention used when creating a model (e.g. “dog”, “dog_head”, “dog nose”, “dog_tail”, etc., or some variation of more useful naming). Various requests have been made to change this for consistency of item naming. The Lab has been looking into this, and a problem is that the server itself ignores any linkset object names outside of the root object. This means that preserving object names is more complex than had been hoped, although investigations on what might be done are ongoing.

[38:08-39:20] *JOKE**: comments on mirrors and raytacing: do not take seriously! An explanation is supplied.