The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, May 31st, 2018 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.
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.
- Animesh User Guide
- Animesh test content
- Animesh LSL methods:
- Animesh – Updated Limits and Cost Formulas
- Animesh feedback thread
- JIRA filter for Animesh
Server-side support should now be largely “done”. There remains one issue awaiting resolution. Once this has been cleared, discussions will start on wider deployment of the code – potentially Aditi first, then to an RC channel on Agni (the Main grid). Still no release date due to ongoing work on the viewer.
Rigged Mesh Level of Detail / Bounding Box Issues
(BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box.
A new approach to resolving this is being attempted which involves removing non-rigged mesh asset sizes from the rigged mesh bounding box.This will not involve changes to avatar scaling / height calculations. If it works, it should result in better bounding boxes for avatars and rigged mesh attachments in general, not just for Animesh. Currently, it is awaiting some back-end updates.
Avatar Limits and Cost Calculations
These were revised several weeks ago – see the link to Vir’s update in the resources list above – and are unlikely to change. At the previous CCUG meeting, there was some discussion over the streaming cost calculation for the Medium LOD, but again, this will not be changing.
Vir reminded people that the ARC calculation for Animesh is now related to the streaming cost calculation (as per the current project viewer – version 126.96.36.1995420 at the time of writing). It therefore shouldn’t be subject to quite the same kinds of issue related to scale-based distortions as previously. It may also go through further tweaks.
On a broader note, costs (streaming, impacts, etc.), are going to be looked at as a part of a separate (to Animesh) project – Project ARCTan – see below.
Broken Rotations Issues
- (BUG-139251), some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
- When linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.
No updates on these were available at the meeting.
Joint Offset Constraint
Setting (either deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results. To prevent this, a 5m joint offset constraint was introduced in the project viewer. This has / will be now backed out as it has been seen as overly restrictive. An alternative solution will be sought, and Vir hopes that having a fix for the bounding box issue (above) will help in this.
Animesh and Attachments
There has been confusion over Animesh and attachments. In brief:
- One one Animesh object can be attached to an avatar at a time.
- Animesh objects, while they have a skeleton, do not support avatar-style attachments. Instead, additional objects (e.g. a collar for an Animesh puppy) should be made a part of the Animesh linkset, and then driven by the Animesh skeleton / scripted animations within the Animesh (although objects in n Animesh linkset could be animated by their own scripts / animations if required).
- The above has been discussed at length in previous meetings, due to concerns as to how No Mod Animesh items could be made to work with different options (e.g. a puppy wearing different styles of collar).
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.
This work does not include normal or specular map support, as these are not part of the existing baking service.
Additional Bake Channels
Anchor Linden has been working to adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators). All of these had been intended to be extensions to the tattoo layer. However, in testing, it was found that feeding a wearable layer with these new channels to a viewer without the necessary support to use the channels, the viewer gets “unhappy”.
To avoid this, this Lab has opted to create a new wearable type which will know about these new bake channels. It will sit above the tattoo layer and below the clothing layers. This should allow those wishing to make use of the new channels to do so without risk of impacting older viewers, which will simply ignore any new wearable layer they’ve not previously encountered. The flip side is, this extends the amount of work required to introduce a new wearable to the inventory service, in additional to the simulator, appearance service and viewer changes already required were the tattoo layer to be used.
A name for the layer has yet to be determined – but “universal” is under consideration – although Rider Linden (with tongue firmly in cheek) suggested “Bob”.
Scripting Support for Bakes On Mesh
No decision on whether this will be addressed, or if it is to be addressed, whether it will be a part of the initial release.