Day: July 20, 2018

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, July 19th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Note that the audio presented here may not be in the exact order of discussion during the meeting; as subjects were at times returned to following their initial discussion, I have attempted to bring together key points of discussion by topic / subject matter. Also, please note that audio drop-out when Vir is speaking appears to be an ongoing problem at his end.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Rotation Issues

These cover a couple of issues:

• In one (BUG-139251), when 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.
• The second problem is that 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.

Both of these problems pre-date Animesh, but have been effectively “hidden” because until now, rigged meshes could only be attached to an avatar, effectively masking the issues.

As a part of the approaches to fix these issues, Beq Janus and Elizabeth Jarvinen (polysail) have contributed code to correctly apply the bindpose matrix within the viewer. This code is in the latest version of the Animesh project viewer, which should be available soon, and should cover legacy content not corrected by similar fixes incorporated into Avatasr for new uploads (see my week #26 CCUG summary for more on this).

LOD Issues

Vir is currently working on the server-side issues, but once those have been resolved, his plan is to work on the viewer-side LOD issues, including BUG-224971 and the Dynamic bounding box issues (see my week #25 summary). Once he has completed testing the fixes for these, the hope is that the Animesh viewer can move to RC status.

Mesh Physics Shapes Issues

The deployment of Animesh to the RC server channels has revealed a couple of issues which need to be resolved:

• Not all of the mesh information the server is required to “remember” is being properly retained.
• Code within the Animesh update appears to be causing some in-world mesh objects to use the wrong physics shapes.

In Brief

• Concern was raised whether Maya could be used to produce Animesh, given the rotation fixes seem to apply to Blender / Avastar. As Far as Cathy Foil (creator of Mayastar) is aware, meshes created in Maya / Mayastar can be converted for use as Animeshes.
• Animesh does not support custom bones – it works purely with the Bento skeleton, which does allow for bone re-purposing.
• BUG-225063 reports that the latest Animesh project viewer fails to display meshes at times, while older Animesh code can cause meshes to display incorrectly. Vir believes the issue may be linked to one he has been addressing, and believed to be caused by an uninitialised variable. The fix for this should be in an upcoming release of the viewer.

• BUG-216352 “[Animesh] Issue with animations not rendering if they were stopped and started while host object is selected” – this is still being investigated. However, as it only applies to the same animation, rather than all animations, the issue isn’t regarded as a blocker for Animesh.

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 Bake  Service.

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

Some people have been reporting some “excitement” when using the new universal bake channels for Bakes on Mesh in regions that don’t have the server-side support for Bakes on Mesh. These issues will likely require further viewer and server-side changes to fix them.

At a recent LL meeting on Bakes on Mesh it was decided not to implement any additional features at this point in time – so no LSL support prior to the initial deployment. Rather, the Lab would like to get a basic capability out that can be used and tested, then potentially improve on it with further features in time.

As it is, even moving Bakes on Mesh to release candidate status is dependent on a large number of back-end service changes (e.g. the inventory system must be updated to handle the new wearable types; the Appearance and Bake services must be updated, as well and the simulator and viewer updates.

Asa reminder, it will not be possible to use Bakes on Mesh with Animesh creatures / creations, primarily because Bake On Mesh uses the Outfit system, which Animesh currently does not – but may be extended to use in the future.

The question was asked if Bakes on Mesh could be used to texture an Animesh attachment to an avatar, and in theory it would be – but how useful / practical this might be is open to debate.

In Brief

• There will be a CCUG meeting on Thursday, July 26th, however, it comes on top of the SL summit meeting at the Lab (to discuss the SL development roadmap) and  so Vir believes there won’t be too much to report on additional work at the meeting.
• Concern has been raised over the recent DMCA situation involving around 3 makers of mesh heads, and whether Bakes on Mesh will see changes to the SL Terms of Service / guidelines specifically for UV maps (e.g. what is allowed, what isn’t), given that Bakes on Mesh could encourage the use of the basic SL UV maps and result in multiple claims of people “using” someone else’s maps. This concern is being passed back to the Lab’s legal team.
• The latter part of the meeting included a lengthy discussion on animations (adding a function to “instantly” stop an animation / being able to modify animation speeds / priorities in-world; the legitimacy of modifying animations) which also spread to the permissions system (providing  “export” permission to allow people to export “full perm” meshes for direct editing and re-upload and / or implementing a “derivative” permission.
  • Some of the animation discussion touched on the animation discussion may surface as a specific feature request(s).
  • It’s unlikely there will be any large-scale changes to the permissions system in the near future.