Category: SL User Group Meetings

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, June 8th, 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.

A video recorded at the meeting by Medhue Simoni is embedded at the end of this update, my thanks to him making it available. Timestamps in the text below refer to this recording. The meeting was disrupted by three region crashes, and this is reflected in the stream recording.

Asset HTTP Viewer

[2:50] The Asset HTTP RC viewer (version 5.0.6.326593 at the time of writing) has an update with LL’s QA. As noted in my last TPV Developer meeting update, this includes the new viewer update management code. It is now expected to appear in the release channel and an RC update in week #24 (week commencing Monday, June 12th).

Animated Objects

[3:18] Vir is continuing to work on the animated objects project, and now has an internal version of the viewer that hooks-up to a correctly configured simulator. It is still some way from being ready to be offered as a project viewer, however.

Skeleton Positioning

[4:09] One issue to be considered with animated objects using the avatar skeleton is where the skeleton is supposed to be positioned. Avatars are placed by the simulator providing information on where the agent is, and the bones are then positioned and things like hover height are applied, and whatever rigged objects are being worn are positioned relative to the skeleton’s position. With an animated object, the reverse is true: the object has a defined location, and some means needs to be found for the system to position the bones accordingly; it’s not currently clear how this should be done.

Vir has tried experimenting using the mPelvis bone, and aligning that with the object’s position, with mixed results. So, should the Lab simply pick a convention and have people build their animated objects accordingly, or should a smarter, more adaptive solution be sought?

Collisions

[10:50] Collisions (being struck by avatars, other objects). Collision detection isn’t currently carried out in SL for skinned objects, however, Vir is considering calculating collisions based on the collision volume of the skeleton, although this has yet to be investigated.

Setting a Prim as Object Root

[11:19] Cathy Foil has suggested using a prim as the root for an animated object, with the skeleton positioned relative to that prim. This has the advantage of potentially allowing the skeleton, as a child linkset of the root, to have physics; further, the prim could be set statically at a fixed location in a region, and the skeleton  / object animated to roam independently or it could be scripted to move (and even use Pathfinding), with the animated skeleton / object carried along with it. Thus, it could offered a flexible approach to the problem.

[14:34] One of the things Vir is aiming for is for creators to be able to take existing skinned mesh content and turn it into animated objects, without the need for the model to be re-worked / re-uploaded.

Multiple Rigged Meshes in an Animated Object

[17:38] With his current work, Vir believes it should be possible to have multiple rigged / skinned mesh objects animated by a single skeleton (e.g. so an avatar body can be split into the notional lower body, upper body, head). This could have some interesting uses providing the meshes don’t try to use the same bones.

Frame Rates

[20:05] Vir has had a number of animated objects running at the same time, and he has not seen a significant impact on frame rates. However, the caveat here is the relative rendering complexity of animated objects and how that affects client-side processing. The current hope is that the impact of any given animated object will equate to that of a similarly rigged and complex avatar, so the potential for performance impact is there; it’s just too early in the project to make any definitive statements.

Editing Size

[20:45] At the moment, the size of an object is governed by the size of the skeleton; it could be more flexible if the size of the objects could be set / edited, and this determines the size of the skeleton. This might, for example, be done by sizing the skeleton to the object’s bounding box (which adjusts as the object is resized). However, it’s again too early in the project to offer a definitive way this might be done.

[23:12] Cathy points out that having a root prim for an animated objects, sizing them could be tied to the size of the root prim. So, for example, doubling the size of a root prim would double the size of the object.

Applying Baked Textures to Mesh Avatars

[33:41-35:45] A short explanation of this project for those unfamiliar with it. In brief, a means to apply composited textures bakes (skin, tattoo, clothing layers, etc), to mesh bodies using the SL baking service, with the aim of potentially reducing the complexity of avatar bodies.  This work is being carried out alongside of animated meshes, but is not dependent upon that project (or vice-versa).

[29:06] Updates to the baking service to support baking textures on mesh avatars has now started. This is currently infrastructure work – updating the baking service to a newer version of Linux, etc.

After this, the first step in getting the service to work with mesh bodies will be updating it to support 1024×1024 textures and producing a corresponding viewer update. Once the latter is available for testing, then the Lab will be ready to look at the feature set for supporting bakes on mesh.

Materials Support and the Baking Service

[30:30] There may be a misunderstanding circulating that the baking service will “disable” materials on meshes. This is not the case.

The baking service has never supporting materials processing, and the work to enable texture baking on meshes will not include extending the baking service to handle materials  – this would be a huge undertaking. However, it will not prevent materials from being used via other means (application directly on the mesh, etc.), or any other way in which materials are used in-world.

The baking service uses is a composited diffuse (texture map). This may be less than is currently possible when using applier systems (which should continue to work alongside bakes on mesh). [40:34] It will also be possible to still manually apply normal and specular maps to an avatar mesh using the bakes.

Baked Texture Delivery to a Mesh / Persistence

[31:53 and 38:47] Once a bake has been completed it would be delivered to the mesh by means of flagging the face to which it is to be applied. This flag will remain persistent, so when the avatar appearance is updated texture will be re-applied to the face, until the face is flagged as requiring a different baked texture.

Arbitrary Use of Bakes

[36:24] As noted in my last Content Creation UG update, there has been some discussion of a more arbitrary use of bake textures and applying them to other objects, but this in not the focus of this current work. However, these ideas might be considered in the future.

Anchor Linden

[41:58] Anchor Linden is a new name at the Lab, and is currently working with Vir, focusing on the texture baking project.

Supplemental Animations

[41:38] The supplemental animations work, designed to overcome issues of animations states keyed by the server-side llSetAnimationOverride() conflicting with one another, is still on the card, just no further movement as yet.

General Discussion

[44-22-end] General discussion: mesh uploads, proper management of LODs, etc.

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.