The following notes are taken from the Content Creation User Group meeting, held on Thursday, December 14th, 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. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.
Bakes on Mesh
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.
[1:54-3:40] Testing of the updated baking servers to handle 1024×1024 is now complete. Originally, it had been thought that the Bakes on Mesh would require changes to objects themselves when using 1024×1024 textures, which would have required simulator updates as well.
The approach now being taken is the let the viewer recognise when 1024×1024 textures are being handled via the texture UUID, which should hopefully eliminate any simulator side updates as well in order to get the service running. However, this does raise the question of how to make the system avatar transparent / invisible without continuing to rely on an alpha mask – right now the Lab is looking at a number of possible approaches.
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”.
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).
- Animesh User Guide
- Animesh test content
- Animesh LSL methods:
- Animesh feedback thread
- JIRA filter for Animesh
Appearance Service Update
[4:28-6:18] The appearance services has to perform a number of calculations based on the mesh attachments an avatar is wearing. For example, these calculations are run to try to ensure an avatar appears to stay reasonably on the ground when wearing a rigged mesh which might otherwise alter the avatar’s centre position above the ground.
These calculations don’t work particularly well for Animesh attachments, as they have their own skeleton, so the appearance service has been updated so it can differentiate between Animesh and non-Animesh attachments for the purposes of calculating and avatar’s height. The update is being tested on Aditi, and also includes a fix for rigged mesh attachments being incorrectly handled.
- Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
- Animesh objects now display animation information for objects you have permission to view.
- Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
- Fix for Animesh attachment getting removed after teleport.
- Fix for some of the cases where animesh graphics state could get corrupted.
- Various clean-ups and optimisations.
[6:32-7:30] There is also a forthcoming fix to the mesh uploader – not in the viewer version above – and mesh attachments with spaces in their names (actually a Collada file issue). In short, the Lab is implementing a similar kind of fix to that used by Firestorm to allows objects with underscores in their names, rather than spaces.
Testing Limits: Tri Count Increased to 50K
[8:07-9:03] There has been a lot of feedback that the 20K tri count limit imposed for testing Animesh is insufficient for some creators. In fairness, some of the complaints appear to be more to do with testing completed Animesh products rather than testing the Animesh capabilities to ensure they work as expected; however, the Lab has relented and increased the testing limit on tri counts to 50K. Again, this isn’t the final limit – it is purely for testing. Final limits – hard or soft, tri, number of attachment, LI, etc., – won’t be addressed until actual load testing and scaling takes place as one of the final steps in the project.
Avatar Animesh Attachments
[12:27-19:40] (with lengthy silences)] Other limits, such as the number of Animesh attachments an avatar can wear (set to one for testing) remain unchanged at this point.
Attahments are seen as an interesting use-case with suggestions that as well as pets, it could be used for further animating hair (as rigged mesh hair can already be somewhat animated with head movements, etc). The latter is something that it was suggested Bento might further achieve (bones allowing). Using Animesh would provide more bones for animating hair, but ensuring animations remain in sync with body movements might be difficult. It could allow hair to be a “pet” (a Medusa-like heads for of snakes).
Attachments for Animesh Objects
[24:45-32:18] Animesh will not support attachment swapping in the initial release – attachments will need to be defined as part of the overall Animesh. Adding / removing attachments is seen as part of the follow-on project.
This section includes discussion of a specific prim-based issue with Animesh encountered by one creator, and a discussion on non-rigged elements of Animesh objects not correctly moving with the rest of an Animesh object (e.g. unrigged eyes failing to properly move with the rest of an Animesh creature’s head).
[19:56-23:00] Vir’s current focus for the project is bug fixing. These include:
- Some Animesh objects seeming to disappear when in their static (non-animated) state.
- Left-click interactions with Animesh: it’s possible to right-click and Touch an Animesh object via the menu, but left-click interaction currently isn’t possible. Left-clicking on multiple Animesh objects to select them also isn’t possible at present.
- Animesh LOD selection: currently the selection of the LOD for displaying an Animesh is the same as used for avatars; Vir’s feeling is that Animesh should use the same selection process as for in-world mesh objects.
- Animesh objects do not always update correctly when camming onto them.
There are also a couple of feature requests that are still being considered around LSL capabilities.
- [34:23-35:22] Avatar skeleton as its own asset type? This has previously been discussed in the Bento project, and while an interesting idea, is seen as being a large amount of work and crosses into the realm of arbitrary skeletons, which could complicate the user experience (e.g. items working with one type of skeleton, but not another). As such, it remains something the Lab isn’t currently considering, although it may be something they will look at in the future.
- [39:49-52:06] Discussion on rez-on-entry resource caps, issues of Animesh animations starting / stopping correctly, and how updates are handled – how people see an Animesh that is already in a region being animated can depend on the frequency of the animation updates. The potential need for a shape to effectively place bones / attachments.
- [54:35-end] Discussion on feature request BUG-139203 tri counts / land impact / LODs and issues / exploits.