Category: SL User Group Meetings

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, May 25th, 2017 at 1:00pm SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are available on the Content Creation User Group wiki page.

Audio extracts are provided within the text, covering the core points of the meeting. Please note, however, that comments are not necessarily presented in the chronological order in which they were discussed in the meeting, but are ordered by subject matter.

A video recorded at the meeting by Medhue Simoni is embedded at the end of this update, my thanks to him making it available. However, do not that this cuts out mid-way through the meeting. Timestamps in the text below refer to this recording.

Applying Baked Textures to Mesh Avatars

[1:54] This was announced as a new project – see my separate update for details.

The meeting saw additional questions asked about the baking service, which are summarised below.

Will the Baking Service Support Animated Objects?

• Not initially. Baked textures are only relevant to your Current Outfit Folder (COF), affecting your appearance only. Animated objects will not have any notion of a COF (as they do not have an associated inventory structure as avatars do), so whose textures would an animated object show?
• Also, even if you could assign your own COF-defined appearance to an animated object, it would only be valid until you change your own appearance, which would discard the bake used by the object, probably leaving it blank.
• One solution might be allowing arbitrary textures to be sent to the baking service (see below). Another would be to allow animated objects to have their own notion of a COF contained within the object itself which the baking service could somehow reference
  • WERE this kind of work to be adopted, this would be Vir’s preferred approach. However, it is not currently a part of either the animated objects project or baking textures on meshes.

Baking Arbitrary Textures

Would it be possible to have a LSL function to request baking arbitrary textures?

• Not as a part of applying baked textures to mesh, although it might be considered in the future.
• However, the baking service could offer considerable flexibility of use were it to be extended, simply because of the way it defines the body area (head, upper body, lower body).
• A problem is that, as noted above, baked textures are held only so long as your current avatar appearance defined via your COF is relevant, after which they are discarded. For the system to be useful with arbitrary textures, the resultant composite textures would need more rigorous storage, perhaps as a new asset class or retained in some form of “temporary” texture store – either of which would have to be defined and allowed for.
• Thus, the problem is the amount of work involved in extending the baking service and (potentially) the asset handling required to support it.

HTTP Asset Viewer

[4:22] The HTTP Asset viewer was updated to version 5.0.6.326593 on Friday, May 26th. This update primarily bring the viewer to parity with the recently promoted release viewer, and so primarily comprise the revised region / parcel access controls, and the updates to Trash emptying behaviour.

Supplemental Animations

[6:53] As well as working on animated meshes, Vir is now also working on the LSL side of supplemental animations alongside of LSL changes need for animated objects. The work is designed  to overcome issues of animations states keyed by the server-side  llSetAnimationOverride() conflicting with one another.

Animated Objects

Current Project Status

Vir has got basic prototyping working in a “hacked up” single version of the viewer. He’s now working on the shared experience – how is an animated object seen by multiple viewers.

There is still no details on what limits beyond land impact which may be applied to animated objects (e.g. number of animated objects – not avatars – permitted per region type, etc), as there is not at this point any solid data on potential performance impact to help indicate the kind of limits which might be required..

Number of Allowed Animation Motions

[8:52] Currently, SL supports a total of 64 animation motions playing at one time per agent (hence walks, arm swings, wing flaps, tail swishes, etc., all of which can happen at the same time). It’s not been tested to see how much of an actual load running multiple animations places on a system. The limit might have to be changed as a result of animated objects – or it might not; it’ll come down to testing.

Other Items of Discussion

Avatar Scaling

[12:24-video end] There is a lengthy discussion on avatar scaling.

• Essentially, the size slider works within a certain range; go beyond this, and distortions of body parts (e.g. facial features) can start to occur, as some sliders stop working properly.
  • Obviously, it is possible to scale avatars using animations, but again, doing so also doesn’t play nicely with the sliders.
• This problem is particularly impactful with Tiny and Petite  avatars (although it also affects really large avatars). One workaround is to upload a mesh without joint positions of the affected bones, but this causes breakages in the mesh.Thus, having a slider which could handle the avatar’s scale over a broader range might be beneficial. However:
  • Changing the definition of the current scale slider to work over a broader range isn’t an option, due to the risk of existing content breakage.
  • Adding a new “global scale” slider to the system might be possible. However, while its is relatively simple at the viewer end of things, SL is already close to its limit of 255 sliders, and any additional global slider will require significant changes to the back-end.
• A further problem is motion is not affected by scale, but is keyed to the current avatar size range. So, additional work would be required to the locomotion system to ensure the distance covered by an avatar’s stride is consistent with its size, adding further complexity to any changes.
• Also, the ability to scale avatars would also require using rotations only, as any use of translations could result in locomotion issues noted above (e.g. so a really small avatar would appear to zip along at 100s of miles an hour), and rotation-only animations are somewhat limiting.

BUG-20027: Allow joint-offset-relative translations in animations

Created during the Bento project, this feature request was originally closed as something the Lab could not implement. It has now been re-opened as people wanted to add further feedback to it. So, if you have an interest – please go and comment on the JIRA.

Cost of Animating via Bones vs. Using Flexis

The Lab views animating via flexis as being very inefficient, but have no numbers for a direct comparison to the cost of animating bones.

Improving IK Support

General requests have been made for SL to better support Inverse Kinematics (IK) to add greater flexibility of joint / extremity positioning. Vir has requested that if someone could start a feature request JIRA, open for comments, on what might be sought, it would be helpful.

Next Meeting

The next CCUG meeting will be Thursday, June 8th, 2017.

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, May 18th, 2017 at 1:00pm SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are available on the Content Creation User Group wiki page.

Audio extracts are provided within the text, covering the core points of the meeting. Please note, however, that comments are not necessarily presented in the chronological order in which they were discussed in the meeting. Instead, I have tried to place a number of related comments by Vir on specific topics into single audio extracts and with their associated notes, in the hope of making those topics easier to follow, and without changing the context of the comments themselves.  If you would prefer to listen to the discussion and comments in the order the meeting unfolded, I have embedded a video recorded at the meeting by Medhue Simoni. My thanks to him making it available.

Supplemental Animations

While this is now an adopted project, the focus has been on animated objects, and so there is no significant progress on this work at present.

Applying Baked Textures to Mesh Avatars

No movement on this.

Animated Objects

Vir has spent most of the week since the last meeting working on animated objects and developing prototypes and looking at proof-of-concept to see how objects might be animated using the avatar skeleton. He describes the results thus far as encouraging whilst also pointing out it is still early days with the work, so it is still far too early to determine what the final architecture will be.

The viewer already has a notion of an avatar without a human operator, which is notably seen when uploading an avatar mesh or animation. This notional avatar isn’t rendered graphically, but is oriented using transforms so that an object can use it as a source of joint motions. This is not necessarily how things will work with any finished product, but it is enough to demonstrate what might be possible.

Currently, Vir is working with single object rigged meshes, and would be happy to receive similar models, preferably with associated animation, if people have anything they believe would be useful for helping with these tests.

It is hoped that “being animated” will be an additional property which does not require a new mesh upload option, so that any rigged mesh for which you have Edit permissions for can be set to use the property  so that it can be driven by its own animations.  Currently:

• This will likely mean the object will no longer be attachable to an avatar
• It has yet to be determined if this property will be a new prim type or an additional field added to an existing object, etc
• It will not require any changes to the current mesh uploader; the property to convert a mesh to an animated object can be set post upload.

A suggestion was made that the animated mesh should use its own skeleton when independently rezzed in-world, but a sub-set of a controlling avatar’s skeleton if it is attached. This would allow things like animated horses to be rezzed in-world and then sat on for riding or pets to be “picked up” and carried,  as is currently the case with some scripted animals already.

The testing carried out thus far hasn’t looked at animated attachments, although Vir appreciates the potential in having them. However, there are concerns over potential additional performance impacts, the risk of bone conflicts (what happens if your avatar is already using one or more bones some something and these same bones are used by an animated attachment).

While not ruling the potential out, Vir’s tests so far haven’t encompassed animated attachments to determine what issue might arise.  There are also other factors involved in avatar control which need to be looked at with animated objects: hover height, offsets, position, etc., all of which might affect how an animated object might be seen / behave.

Scripting / LSL Commands

The current work has not so far looked at LSL commands or command sets for the new capability. However the intent remains that scripts for controlling an animated object will be held within the inventory for that object, and able to call animations for the object also contained within the object’s inventory, so things are not straying too far from what can already be doing vis scripted control of in-world objects.

Performance Impact

Similarly, it is hard at this point to know what the likely performance hit might be. Bento has shown that adding more bones to the avatar skeleton doesn’t create a notable performance hit, so providing a skeleton for in-world objects shouldn’t cause any greater impact than a basic avatar. However, associating a rigged mesh object with than skeleton, then animating the joints, etc., will have an impact, particularly if a lot of animated objects are used in any given place.

This is something that will be looked at in greater detail once there is a project viewer available for testing alongside any server-side updates, although the Lab doesn’t intend to make it easy for a region to be spammed with multiple versions of an animated object, and this may in part be linked to the Land Impact associated with such objects.

Attachment Points on Animated Objects and Linksets with Animated Objects

While attachment points are also joints within the skeleton being used by an animated object, and so can be animated, they would not actually support having other objects attached to them, as the animated object doesn’t have links to other objects in the way an avatar does.

An animated objects could be a linkset of rigged meshes which are identified as a single object, with all of the rigged meshes referencing the same skeleton. Things might be more difficult if static mesh objects form a part of the object, as it is not clear how the positioning of these would be controlled, and more testing is required along these lines.

Body Shapes and Animation Scaling

Requests were made to allow animated objects to have body shapes (which would allow slider support, etc.), and  / or animation scaling.

Because of the changes that would be involved in both, coupled with the potential for conflicts in the case of animation scaling, Vir does not see either as being part of this work – as previously noted, assigning a body shape to an animated object would impact a number of other back-end systems (such as the baking service), adding significant overheads to the project.

As such, the Lab would rather keep the work focused, building on something that could be rolled-out relatively quickly, and then iterated upon. However, one option that might be considered is having some kind of root node scale, based on the scale of the animated object that would size the skeleton to the scale of the object, rather than vice versa, possibly by altering how the mPelvis bone is managed for such objects.

[56:37-1:02:30] The final part of the meeting delved into the relative efficiency of mesh and sculpts, and matrix maths on CPUs / GPUs, and the complexities of rendering animated objects, together with a reminder that object rendering costs are currently being re-examined.

Other Items

In-World Mesh Editing?

[41:00-55:55] Maxwell Graf raises the idea of having a simple in-world mesh editor / enhancements to the editing tools which would allow creators to adjust individual face, edge or point in an object, presenting a reason for mesh creators to spend more time in-world and which might allow non-mesh builders more flexibility in what they can do as well.

The current toolset  – mesh uploader and editing tools – would not support such a move. There are also a number of potential gotchas on a technical level which would need to be understood and dealt with, and in order for the Lab to consider such a project, any proposal would have to consider the smallest subset of capabilities available in dedicated mesh creation / editing tools like Blender and Maya that would be useful to have in-world, so that it might be possible to define the overall scope of the work required in terms of resources, etc., and what the overall return might be on the effort taken.

Based on the conversation, Max is going to try to put together a feature request / proposal, even if only for the purposes of future discussion.