Category: SL User Group Meetings

The majority of the following notes are taken from the Content Creation User Group meeting, held on  Thursday, November 30th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

Viewer Status

[0:13-1:06] The Animesh Project Viewer should be updated soon, bringing it into parity with the new release viewer (see below). This update will also include a couple of bug fixes.

Non-Rigged Root Items

[6:25-11:12] A short discussion on the ability to include non-rigged objects in an Animesh, such as an invisible prim as the root. This ability was recently added, but hasn’t been extensively exercised as yet. It sparked a look at BUG-139336, with Vir agreeing that the proposal need to be re-examined, as he is not sure if a scripted offset is the best answer, or whether allowing a manual offset through the build tools might be better. This feeds into a later conversation [35:27] about having LSL capabilities for all edit capabilities – and the risk of over-use of options as a result, simply because they can be automated – and the benefits of only making new capabilities (such as BUG139336) only available through LSL, where it might not be obviously to many, rather than being made visible through a build option.

Mod Keys

This was the subject of extensive discussions at the previous CCUG meeting. However, Vir again confirmed that it is viewed as something outside of the immediate Animesh project.

Performance Testing

[12:00-22:00] This is also a popular topic, and Vir re-iterated that it will be done, once the Lab feels this iteration of Animesh is “feature complete”. While he believes this is pretty much the case (allowing for bug fixes), he’d still rather hold off on testing a little longer. In the meantime, there continue to be calls for the current limits on tri counts, Land Impact, etc., to be relaxed to give people greater freedom to design Animesh. Vir is hesitant to do this, as he’d rather start from a constrained baseline with more structured testing to ensure sensible limits are arrived at which can be sustained across the entire grid when Animesh goes live.  Given the way that current mesh avatars are some of the more render-intensive (and viewer performance hitting) objects within Second Life, his concern is perhaps understandable.

[36:35-46:30] Some would like to see the tri limit raised to around 50K to allow for testing of products, rather than testing Animesh itself. This seems to be a little premature. However, Vir is going to discuss the potential for an tri limit increase with Alexa.

[22:42-27:53] A discussion on Animesh scaling, animation size and LOD. If an Animesh is based around a 0.5 cube, but the associated mPevlis bone is scaled to allow a 60-metre tall Animesh, what are the LOD calculations based on: the visible size of the object / distance from it, or the size of the root prim / distance from it (which would cause the Animesh to decay faster as the camera moves away from it).  Vir believes it should be based on the displayed dimensions, but notes there are already issues with meshes load the correct LODs.  As such, he’ll look into it some more.

[28:18-30:00] Further discussion on Animesh Land Impact, the arbitrary / testing only nature of the current 200 LI limit, toggling Animesh items on / off to help reduce LI, the potential of having a separate LI for Animesh objects compared to other in-world objects, and the complexities of doing so, were it to be pursued.

[30:56-32:46] LSL function for converting objects to Animesh and back – suggested as a means of lowering LI on items (so someone could use scripted controls to switch between, say, the active Animesh animals on their land. Again, Vir feels people might be getting a little too hung-up on the LI (and other limits) too early.

[46:42-51:50] Brief discussion on model orientation. As previously noted, Second Life expects a mesh to be X- oriented, so the front of the mesh is aligned to the X-axis. Blender can sometimes orient to the Y-axis. As a known bug, Vir is hoping it can be resolved through Blender, rather than by diving into the viewer code.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

Current Status

[1:18-409] Rider Linden is working on the server-side updates so the simulator can support the new environment settings used by the viewer. When this is done, he’ll be working on saving the environment settings as inventory objects. The first implementation of these objects will be as day cycles, skies, and water – and are set-up to be expanded in the future.

There should hopefully be project viewer available (testing most likely on Aditi) after the Christmas / New Year break.

Continue reading “SL project updates 48/2: Content Creation User Group” →

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, November 16th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh feedback thread
• JIRA filter for Animesh

Mod Keys Proposal

For background information on this, please refer to the forum posts by Piscine Mackenzie and Medhue Simoni, together with feature request BUG-139168, together with my notes from the more recent CCUG meetings.

[0:46-2:53] The proposed scripted mod key capability to allow attachments to be made to No Mo Animesh characters has now been determined to be a much more extensive piece of work than originally thought, and so will not be implemented as a part of the initial Animesh project.

However, the Lab will be tackling it as a project in its own right “some time in the future”.

Remaining Bugs / Remaining Items

[3:32-4:55] The list of remaining bugs/ items to be looked at is summarised as:

• A couple of crash bugs in the viewer to be fixed. These are related to switching between the animated and non-animated states with an Animesh object.
• Code optimizations need to be completed and the Animesh code in general requires some clean-up.
• LOD rendering issues on Animesh objects needs to be fixed.
• Animesh imposting needs to be fixed.
• Left-clicking on rigged mesh doesn’t work well, and this applies to Animesh objects as well (right-click Touch should work), so needs to be addressed.
• Performance analysis needs to be carried out to determine necessary / best adjustments to costs / limitations (LI, tri count, complexity).

[4:56-5:45] Baking service updates: there is a couple of bugs in the baking service Anchor Linden is currently investigating, and which need to be resolved for Animesh. One of these can cause incorrect adjustments to be made to an avatar’s height calculation when an Animesh object is attached.

Any other issues people have noted not already filed via the JIRA (see the link to the JIRA filter, above), should be filed as bug reports ASAP.

Costs and Limits

[7:30-8:25] One of the reasons limits need to be examined is that currently, is that LI calculations are based on an object’s scale, whereas the LOD is effectively based on the rigged scale, potentially allowing the cost of the objects to be gamed between the two. This is in part the reason why the Lab has opted for tri counts being a limit with Animesh. However, Vir would like to get a fix in to prevent this kind of gaming; the problem here being the potential for breaking existing content.

[8:25-9:19] Testing will hopefully allows the cost of Animesh objects to be more defined by their complexity than on a fixed land cost, which will be a much smaller component in the overall limits than currently the case 200 LI), and will likely be a “base” LI based on the impact of the avatar skeleton.

[9:39-10:14] The eventual cost might be a combination of a base land impact and a complexity multiplier, although there are issues here with rigged objects being treated as unrigged when calculating rendering costs, which needs to be addressed.

[10:21-10:52] Vir is wary of making too many changes on impact / cost calculations just for Animesh, as there is a broader project to improve complexity cost calculations in general, which is currently on hold pending the introduction of Animesh.

[41:31-43:28] tri count vs Land Impact: in line with the above, Vir is not convinced that “just letting the Land Impact” determine if an Animesh can be rezzed is viable, as has been suggested. There are sufficient issues with the current avatar complexity calculations that, when fixed, could mean that even if a tri count is discounted as a direct Animesh constraint, avatar models converted to Animesh would still be prohibitively expensive from a complexity standpoint.

[43:47-45:16] As with mesh currently, Animesh will not bypass the accounting system if made temp-on-rez.

[45:23-54:50] More discussion on limits / costs, the need for testing, and on the Lab’s approach to preferring to apply costs over limits and the ability for users to determine what they see (as with avatar complexity / Jellydolls), balanced by a desire to get people to think more in terms of optimising their content. Part of the tension with limits / costs seems to be creators are unwilling to develop content, push at the current (arbitrary limits), etc., out of concern that the effort spent building and testing could be wasted / the Lab is hoping people will build, test (and even break) things (including the viewer) so a more accurate assessment of limits can be made prior to release, with the option of making further adjustments further down the road, if necessary.

[54:53-56:11] Would it be possible to have different tri count limits for worn Animesh vs rezzed Animesh – higher for the former compared to the latter? Possibly, but tricky.

Animesh as a Build Floater Option Discussion

[19:28-40:00] A lengthy discussion on having Animesh a toggle feature in the Build floater, rather than something set on upload, and how that might discourage makers of modifiable avatars from producing “Animesh versions” because users could in theory get a set of suitable scripts and animations and attempt to use them with the versions they already have.

The discussion is lengthy, and involves numerous issues, including the extent to which users trying to convert things themselves over buying a “dedicated” Animesh creation (would scripts and animations intended to animate an elephant really work that well in a tiger, for example?); creators’ rights vs. users’ rights with mod items; the decision process behind making the Animesh option a Build floater tool (e.g. it is in keeping with the permissions system – if an item if modifiable, it should include converting it to Animesh, if appropriate; it could help speed the adoption of Animesh – creators could release kits to convert their existing products, rather than entire new products, etc). The overall consensus appears to be having the option in the Build floater is better than trying to restrict it.

Animesh Sitting

[56:28-56:58] As discussed in past meetings, Animesh bodies will not be able to sit in the same manner as an avatar (by being made a child of the object on which it is sitting). Animesh should be able to adopt a sitting animation it contains, like a ground sit, however). The latter obviously won’t give the same flexibility as the former.

Bakes on Mesh

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. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

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

[11:47-12:55] Again, this is a separate project to Animesh, and neither is contingent upon the other. However, using bakes on mesh with Animesh objects will likely come after any follow-on Animesh project to the current work, as Animesh objects will require some notion of an avatar shape to work with the baking service.

[12:56-14:22] There are no plans at present to offer LSL functions or a script API for bakes on mesh, due to the complexities of the baking service. If such a capability is seen as needed, a feature request JIRA explaining why and the benefits should be submitted.

[16:35-19:12] The goal is to have the baking service work in such a way that creators can use the Appearance floater to assign the use of baked textures to object faces which correctly correspond to the different avatar elements (so for example, an upper body composite texture is correctly applied to the upper body faces on a mesh avatar). Once this has been set, users selecting the clothing layer would then see it correctly applied to their avatar in the same way as clothing layers are applied to the system avatar.

Next Meeting

The next CCUG meeting will be on Thursday, November 30th (week #48), due to week #47 being US Thanksgiving week, and the Lab taking a holiday break on Thursday, November 23rd / Friday November 24th.