The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, April 26th, 2018 at 13:00 SLT. The meeting is 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.
Vir believes the Lab is pretty close to a final set of Animesh updates for the server side of things. These include support for the Animesh updated limits and cost formulas, and it is expected that QA will be starting soon on the code in readiness for clearing it for deployment to the Main grid, Agni.
Joint Offset Constraints
One of the reasons the Lab is discussing constraining joint offset is an Animesh bear developed for testing purposes (and which can be found on the Aditi Animesh test regions) which sits some 75 metres off the ground, that’s due to a bad offset being set within the mesh and used with the mPelvis bone, which comes into play when the mesh isn’t being animated.
The bear itself was created as the SL10B wearable avatar, and so demonstrates what can happen with existing wearable content with such errors (which would not become apparent while the mesh is become worn, as the avatar tends to always be in a state of animation) is converted for use as Animesh.
Constraining the distance joints can be offset (say to 5 metres) offers one means of preventing this kind of problem; however, it is recognised that doing so could break existing content – such as the very tall avatar models that are available. Therefore the Lab is considering this an other, more complex options – such as doing something with the bounding box.
Animation Playback Issues
Some are still having Animation playback issues with Animesh objects, notably on initial rezzing or following a region crossing. The advice is it increase the number of animation updates being sent out.
There is some potential confusion with the land impact reports on the mesh uploader and when calculated for an Animesh object when in-world. The uploader calculates the LI for a mesh based on it being a static object. It is only when the object is toggled to Animesh in-world that the revised formulas for LI and complexity are used. This has in turn lead to issues for creators trying to determine what the likely weightings are going to be for their models prior to update.
There have also been some reports that on conversion, models not obeying the new LOD requirements defined as part of the within the new formula suffer heavy penalties when converted to Animesh.
Rigged Mesh Level of Detail / Bounding Box Issues
Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box (see BUG-214736). Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.
Graham Linden has been investigating this issue, and now has some updates for the viewer (yet to be integrated with the Animesh project viewer) which should help with this issue and encourage those creator who have, deliberately or accidentally, gaining an advantage from the issue to offers balanced LOD models for their content.
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.
Anchor’s most recent work has been:
- Completing the work to implement three more tattoo slots of the Bake Service: skirt tattoo, hair tattoo and eyes tattoo. These are designed to extend the tattoo to the same set of slots as for the underwear and clothing layers, and hopefully make the available slots far more flexible in potential use when applying baked textures to worn mesh.
- Continuing to work on the skirt layer stacking issue.
The basic functionality of taking system wearable layers and applying them to mesh faces is viewed as working. However, as per my previous Content Creation meeting notes, there is still a lot to be decided on how to progress Bakes on Mesh, particularly in reference to Bakes on Mesh and the applier market, and the overall convenience of Bakes on Mesh for applying textures to worn mesh faces, compared to “ease” of using applier systems for consumers.
Internal discussions about some of the ideas raised around this – such as being able to inject textures into the Bake Service via script – are still be discussed within the Lab as a result of the concerns raised at the previous CCUG.
Bakes and UV Maps / Spaces
Bakes on Mesh has generated a lot of discussion on the effectiveness of custom UV maps and the Baking Service – UV maps being the thing that take was are essentially 2D textures and “wrap” them around a mesh object. In brief:
- The system avatar has a set of pre-defined UV spaces associated with it. These are used by many of the mesh body makers, and so using system clothing layers via the Bake Service should work on these. Mesh heads tend to be different, and so issues can occur trying to apply skins, etc., to them.
- The Lab’s view is that there’s no reason in principle why the baked textures must use the system UV space. So, for example, and providing none of the system avatar layers (such as the skin) are to be visible, it should be possible to use a set of tattoo layers defined in a specific mesh body’s UV space which can then be passed through the Bake Service and applied to a set of mesh faces regardless of the system UV space.
- An issue here is that only tattoo layers can be used with custom UVs, as all other layers have “holes” in them designed to reveal the system avatar skin, allow for eyelashes, etc. Therefore, it is not currently possible to re-purpose a shirt layer, for example. Cathy Foil expanded on this, and on the use of system UV space with mesh bodies.
- Vir expanded a little on the idea that some of the clothing layers that have more “intelligence” built-in (e.g. alpha masking support), hence why they would not work with custom UVs and it would be necessary to use tattoo layers for the textures and re-name them.
Within the meeting, this led to an extended discussion on UV options – such as the advantage of updating the avatar .LAD file and the viewer appearance editor to allow the use of custom UVs or the system UV space (via an appearance editor check box) over re-purposing tattoo layers.
It’s like that initially, the Lab will lean towards re-purposing tattoo layers, rather than re-working the avatar .LAD and appearance editor, leaving it to body / head creators to offer updated UV maps for those cases where they don’t precisely follow the space UVs.
There is no CCUG on Thursday, May 3rd due to a conflict with the Lab’s monthly internal meeting. The next CCUG will therefore take place on Thursday, May 1oth, location TBA.