Bay of Dreams – Blog post
The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, May 17th, 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.
Audio extracts from the meeting are included, where relevant. Please note, however, that Vir’s microphone occasionally seemed to cut out while I was recording, so some of his comments may sound a little choppy.
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.
Project Viewer
The Animesh project viewer was updated on Tuesday, May 15th to version 5.1.4.515420. This update comprises:
- Bug fixes, including improved handling of animation notifications which should result in fewer cases of animations failing to display for some Animesh objects.
- New checks on when a skeleton is needed for a nominally Animesh object – now one should be present only when the linkset contains at least one rigged mesh, and this should update correctly when link/unlink operations take place, or other state changes.
- The ARC calculations for animesh objects has also been updated based on some feedback with the previous build.
Alongside of this there has been a simulator update in support of some of the changes in the viewer (e.g. with regard to animation notifications and updates). Also, to help with persistent across things like region crossings and region restarts, animation information is now stored in the state of the Animesh object itself, when it gets serialised. However, there are reports the animation data is lost on a SHIFT-copy action.
Server-Side Work
As well as the simulator updates for Animesh mentioned above, the Lab is continuing with QA work on server-side support for Animesh to prepare it for deployment to the main (Agni) grid. However, no ETA as yet for the server-side code.
Remaining Major Issues
Rigged Mesh Level of Detail / Bounding Box Issues:This has been the subject of several recent CCUG report in these pages, and is the subject of 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.
Investigations had led to questions in the Lab of how to get things to behave correctly while recognising there may be broader performance issue that need to be addressed. So Graham Linden has been trying to make sense of what might be pulled into the current Animesh project to improve things and what might require a deeper dive into performance in general as a separate piece of work. So at present this remains in the category of “to be determined” in terms of moving to making Animesh available on the main grid.
Joint Offset Constraints: It’s been noted that setting (deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results (the cited example is an Animesh test bear on Aditi appearing to stand 75 metres off the ground when not animating). This has led the Lab to consider constraining he distance a joint can be offset to no more than 5 metres for Animesh objects. However, as this is recognised that doing so could break existing content, a more elaborate solution is still being investigated by the Lab.
Adjacent Regions and Animesh Animations: There is an issue where Animesh objects in adjacent regions fail to animate from a avatar’s perspective when someone logs-in. This is thought to be a handshaking / viewer update issue. Essentially, it can take up to a minute for adjacent regions to understand an agent (avatar) in another region can “see” objects within it, and needs to start sending animation updates to the viewer controlling that avatar.
90-degree Rotation Issue: It’s been noted that when converting some static mesh objects to Animesh, the visual mesh appears rotated through 90 degrees when seen in the Animesh viewer. However, the physics mesh doesn’t have the same rotation applied, leaving it perpendicular to the visible mesh – see BUG-139251.
This appears to be related to the fact that the viewer expects the mesh to be aligned to +x=forward – whereas mesh creation tools such as Blender and Maya don’t – by default – use the same orientation. As the issue only affects some mesh (and in theory could be corrected by setting the required rotation in mesh building tools), Vir asked the question if this is something that should be addressed in the viewer.
- If this issue isn’t addressed in the viewer (which is where it manifests), it potentially means a good proportion of existing content which might otherwise be converted to Animesh will exhibit the same issue when associated with an avatar skeleton, possibly eliminating it from use as Animesh.
- If the issue is to be addressed in the viewer, the problem is how to apply the logic to ensure mesh items which don’t exhibit the physics rotation issue don’t end up exhibiting the issue as a result of the fix being incorrectly applied.
Z-Axis offset un the Mesh Uploader: This currently doesn’t work when a skeleton is applied to a mesh object.
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.
Resources
Additional Bake Channels
Anchor Linden is investigating adding further channels to the Bake Service in addition to those recently added, again specifically for use with Bakes on Meshes (they will not work with the system avatar). These will hopefully comprise:
- Separate channels for the left arm and left (currently these are mirrored from the avatar’s right side) to allow for asymmetrical avatar options.
- Three additional “general purpose” channels to be defined and used as required by creators.
These channels will eventually be surfaced as tattoo layers in the viewer, which will have an updated UI for creating new layers.
Injecting Texture Information into the Bake Stack
There has been a request to allow applier creators to use a scripted means to “inject” textures into the Bake Service via a script (see BUG-216137).
It has arisen out of concern that Bakes on Mesh a) won’t offer the same ease-of-use as HUD-based appliers many users are familiar with; b) it could make the majority of existing applier systems obsolete as mesh head / body creators move towards less complex “onion layer” designs, requiring applier makers to completely re-work all of their existing clothing options. Offering a means to provide Bakes on Mesh with a similar capability as applier systems and allow applier makers to more easily update their existing systems. However:
- The proposed solution is a non-starter, as the Outfit system on which the Bake Service relies, has no notion of textures. Thus, offering a means to “inject” textures into the bake stack essentially creates a separate (and potentially conflicting) representation of the bake stack.
- If it is seen that a more applier-like approach to Bakes on Mesh, any solution will form part of a follow-up project, rather than being part of the initial implementation.
Inara Pey: Living in a Modemworld 