2018 UG updates #17/3: Content Creator User Group

Dragons by Wanders Nowhere, used in Animesh tests

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.

Animesh Project

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.

Server-Side Updates

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.

Land Impact

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

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.

This work does not include normal or specular map support, as these are not part of the existing baking service.


Current Status

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.

Next Meeting

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.


2 thoughts on “2018 UG updates #17/3: Content Creator User Group

  1. A big part of the Bounding-Box/LOD problem is that the Avatar Complexity calculation doesn’t allow for the increased distance. Since the latest Firestorm started providing LOD info, I’ve been taking the rigged-mesh distances into account, and trying to avoid using too many triangles that would be useless detail. And I seem to have an OK bounding box. The result is incredibly low Complexity/Display-Weight.

    If this only affects “excessive” bounding boxes the fix might not affect me. Fixing the calculation would give everyone an order-of-magnitude Complexity increase. My avatar would be tolerable, but most I see would be between 400k and 800k. If that happens, the complexity-slider in the viewer will become unusable. The scaling starts getting very lumpy over about 200k, and so a new calculation would hit most existing avatars.

    If there’s a change, and TPVs are slow to update, as a Linux user I am going to be struggling. But I strongly suspect the misleading calculation, and lack of Marketplace support for Complexity, are behind a lot of the lag that plagues busy areas.

    I maybe ought to try to get to one of these meetings. But I don’t speak JIRA, and suggesting “submit a JIRA” will likely put me in Doug Piranha mode. I might use… …sarcasm.


    1. Beq has actually covered the LOD / distance issue as a part of her investigations, so it’s something the Lab have in front of them as well. Avatar Complexity is being re-examined as a part of Project ARCTan (currently in its initial phases) – so hopefully some of these issues will be addressed more deeply as that work progresses. As it is, Graham Linden has been looking at the problems from an Animesh perspective, and he’s heading-up the ARCTan work.

      More information for creators / users has – in the past – been a topic of conversation at the CCUGs (although these have more recently been dominated by discussions on Bakes on Mesh / use of the Bake Service with worn meshes), so offering ideas and feedback on this subject at a meeting is not entirely out-of-the-question.

      As to the JIRA – it is a mystery to many, including some who routinely attend these in-world technical office hours. However, there are a lot of folk with JIRA-fu willing to help within filing. Also, I’m in the middle of putting together a 3-part tutorial on raising bug reports and feature requests via the SL JIRA, which should be appearing in these pages very soon, which I hope will help people overcome their JIRA fear.


Comments are closed.