Tag: Content Creation 2017

SL project updates 51/2: CCUG and viewer

Posted on by Inara Pey
Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, December 21st, 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. However, the first part of the meeting is absent the video, so I’ve included two audio extracts of salient points raised, taken from my own audio recording of the meeting. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

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

Bug Stomping

  • Animation Playback issues: as highlighted at the December 14th meeting, animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This had been considered a viewer issue, but could equally be a simulator / viewer race condition wherein the viewer is receiving animation information before it knows what to do with it (and so is ignoring it). Vir is still looking into this.
  • Object Selection issues: this isn’t just an Animesh issue per se. Historically, selecting multiple animated objects (or an avatar) so they are displayed as wire frames has been handled “extremely inefficiently”, impacting local frame rates. A fix is in hand for this, and will be in the next update of the Animesh project viewer.

Animesh Release ETA and Limits

There is still no indication of a release date for Animesh. Work still to be completed / carried out includes:

  • Bug fixing, including the two issues noted above.
  • Performance profiling (tri, count, LI, etc., limits evaluation, etc.).
    • It is worth repeating (again) that the current limits of tri count, LI, and number of attachments are purely for the purposes of performance testing, they are not the “final” limits for Animesh, some of which will hopefully be somewhat more relaxed / reflective of server / viewer capabilities when scaling Animesh use within a region.

The initial tri count limit (again, set for testing purposes only) was increased from 20K to 50K with the current project viewer release (version 5.0.10.330058, at the time of writing). As noted in my week #50 update, this increase had been requested for some time – although it appeared to be wanted more for testing proposed Animesh products, rather than testing the basic Animesh capabilities. Zooby’s has since issued a video of one such new product, involving both a wearable cat avatar, and which is also intended to support the avatar being used as an in-world Animesh object, once Animesh is released.

Animesh Use Cases

The focus for Animesh among creators thus far has been for avatars (NPCs), and creatures, pets and things like mechanoids (both free-roaming and wearable). However, there is potential for Animesh to be used for landscaping as well: tree boughs / grass moving in the wind, water features, etc., and the Lab is interested in discovering how much appetite there is among creators to use Animesh in this way, particularly when it comes to profiling performance and limits.

Skeleton Use and Bone Naming Convention / Parenting

An extensive discussion on using the skeleton bones.

[0:00-10:36] When talking in terms of unique Animesh objects, the skeleton can be re-purposed to suit the need, and not all the bones need to be animated. So, for example, in a grouping of plants, the leg, arm, wing, and tail bones could be used to animate individual plants (in principle, individual finger bones could be used).

As with any use of the skeleton, the important aspects are preserving the recognised bone naming and parenting hierarchy (although it is possible to constrain bones  / bone groups for specific uses within Blender, then map this back to the SL skeleton, but it requires care and attention with a thorough understanding of the SL avatar).

This is where Animesh is attachments such as hair is of an advantage over hair that simply uses with avatar’s own skeleton. With the latter, the available bones are limited without potentially impacting the ability to wear animated hair with a Bento head (although there are “spare” ear and eye bones which could potentially be used to create an animated ponytail or pigtails).

Using a separate range of bones in Animesh hair offers greater flexibility – but then the issue becomes keeping the animations in the Animesh hair in sync with the movements of the avatar wearing it.

“Dropping” Animesh / Mesh

[11:50-15:31] Worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This has been seen as limited with Animesh pets, etc., where ideally people might want to pick a pet up and carry it and then put it down again (drop it). Making it possible to drop mesh is seen by the Lab as “kind of a hassle to do”, but it’s not currently clear how big or small a hassle it might be, as it would involve additional land impact calculations, physics updates, etc., none of which were given support when mesh was introduced. Thus, it could require  an extensive simulator-side overhaul.

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. 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 mesh surfaces. 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.

Current Progress

Viewer work has paused while some back-end baking service issues are resolved.

Other Items

How the Lab looks at Features

One oft-phrased point-of-view is that the Lab “only” think about features being used in a certain way – and this has at times been voiced for Animesh. Speaking at the meeting, Oz Linden sought to dispel this idea, pointing to the diverse ways capabilities are frequently used in SL.

 

Mesh Uploader

[18:15-22:44] Cost calculation issues: discussion on mesh upload costs noted in the viewer. These have long been an issues, where costs can alter due to the same model being automatically decimated differently with each upload, etc. These are most likely the result of errors in the calculations framework, and they are something the Lab is aware of, and might be the result of the removal of the SLM file from the uploader, which caused problems of its own. Those who wish to test whether the cost calculation issue is reduced by using the SLM file can do so by setting the MeshImportUseSLM debug to True.

[23:32-24:22] Mesh object names: Vir reminded people due to a limitation with Collada .DAE files mesh objects for upload via the official viewer cannot currently have spaces in their names. However, the Lab will be adopting the Firestorm work-around for this by allowing the use of underscores in object file names.

Bone Offsets

[26:44-29:18] Bone offsets: Vir points to an issue he encountered with an avatar model using a 75m offset for the mPelvis bone which, every time the offset was calculated, would cause the object to vanish from his screen until Reset Skeleton was used. This prompted the question whether should bone offsets have a constraint of bone offsets – such as no more than 5 metres, as is the case when offsetting using animations.

SL Viewer

  • The Wolfpack RC viewer (containing no functional changes to the current release viewer) updated to version 5.0.10.330113 on Wednesday Novermber 20th, 2017.
  • Nalewka Maintenance RC updated to version 5.0.10.330123 on Thursday, December 21st, 2017.

These likely mark the last viewer updates for 2017, leaving the rest of the viewer pipeline as follows:

 

SL project updates 50/2: Content Creation User Group

Posted on by Inara Pey
Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

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

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. 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 mesh surfaces. 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.

Current Progress

[1:54-3:40] Testing of the updated baking servers to handle 1024×1024 is now complete. Originally, it had been thought that the Bakes on Mesh would require changes to objects themselves when using 1024×1024 textures, which would have required simulator updates as well.

The approach now being taken is the let the viewer recognise when 1024×1024 textures are being handled via the texture UUID, which should hopefully eliminate any simulator side updates as well in order to get the service running. However, this does raise the question of how to make the system avatar transparent / invisible without continuing to rely on an alpha mask – right now the Lab is looking at a number of possible approaches.

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

Appearance Service Update

[4:28-6:18] The appearance services has to perform a number of calculations based on the mesh attachments an avatar is wearing. For example, these calculations are run to try to ensure an avatar appears to stay reasonably on the ground  when wearing a rigged mesh which might otherwise alter the avatar’s centre position above the ground.

These calculations don’t work particularly well for Animesh attachments, as they have their own skeleton, so the appearance service has been updated so it can differentiate between Animesh and non-Animesh attachments for the purposes of calculating and avatar’s height. The update is being tested on Aditi, and also includes a fix for rigged mesh attachments being incorrectly handled.

Viewer Status

[6:21-8:01] The Animesh project viewer updated to version 5.0.10.330058 on Monday December 11th. This updates includes the following changes:

  • Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
  • Animesh objects now display animation information for objects you have permission to view.
  • Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
  • Fix for Animesh attachment getting removed after teleport.
  • Fix for some of the cases where animesh graphics state could get corrupted.
  • Various clean-ups and optimisations.

[6:32-7:30] There is also a forthcoming fix to the mesh uploader – not in the viewer version above – and mesh attachments with spaces in their names (actually a Collada file issue). In short, the Lab is implementing a similar kind of fix to that used by Firestorm to allows objects with underscores in their names, rather than spaces.

Testing Limits: Tri Count Increased to 50K

[8:07-9:03] There has been a lot of feedback that the 20K tri count limit imposed for testing Animesh is insufficient for some creators. In fairness, some of the complaints appear to be more to do with testing completed Animesh products rather than testing the Animesh capabilities to ensure they work as expected; however, the Lab has relented and increased the testing limit on tri counts to 50K. Again, this isn’t the final limit – it is purely for testing. Final limits – hard or soft, tri, number of attachment, LI, etc., – won’t be addressed until actual load testing and scaling takes place as one of the final steps in the project.

Avatar Animesh Attachments

[12:27-19:40] (with lengthy silences)] Other limits, such as the number of Animesh attachments an avatar can wear (set to one for testing) remain unchanged at this point.

Attahments are seen as an interesting use-case with suggestions that as well as pets, it could be used for further animating hair (as rigged mesh hair can already be somewhat animated with head movements, etc). The latter is something that it was suggested Bento might further achieve (bones allowing). Using Animesh would provide more bones for animating hair, but ensuring animations remain in sync with body movements might be difficult.  It could allow hair to be a “pet” (a Medusa-like heads for of snakes).

Attachments for Animesh Objects

[24:45-32:18] Animesh will not support attachment swapping in the initial release – attachments will need to be defined as part of the overall Animesh. Adding / removing attachments is seen as part of the follow-on project.

This section includes discussion of a specific prim-based issue with Animesh encountered by one creator, and a discussion on non-rigged elements of Animesh objects not correctly moving with the rest of an Animesh object (e.g. unrigged eyes failing to properly move with the rest of an Animesh creature’s head).

Bugs Focus

[19:56-23:00] Vir’s current focus for the project is bug fixing. These include:

  • Some Animesh objects seeming to disappear when in their static (non-animated) state.
  • Left-click interactions with Animesh: it’s possible to right-click and Touch an Animesh object via the menu, but left-click interaction currently isn’t possible. Left-clicking on multiple Animesh objects to select them also isn’t possible at present.
  • Animesh LOD selection: currently the selection of the LOD for displaying an Animesh is the same as used for avatars; Vir’s feeling is that Animesh should use the same selection process as for in-world mesh objects.
  • Animesh objects do not always update correctly when camming onto them.

There are also a couple of feature requests that are still being considered around LSL capabilities.

In Brief

  • [34:23-35:22] Avatar skeleton as its own asset type? This has previously been discussed in the Bento project, and while an interesting idea, is seen as being a large amount of work and crosses into the realm of arbitrary skeletons, which could complicate the user experience (e.g. items working with one type of skeleton, but not another).  As such, it remains something the Lab isn’t currently considering, although it may be something they will look at in the future.
  • [39:49-52:06] Discussion on rez-on-entry resource caps, issues of Animesh animations starting / stopping correctly, and how updates are handled – how people see an Animesh that is already in a region being animated can depend on the frequency of the animation updates. The potential need for a shape to effectively place bones / attachments.
  • [54:35-end] Discussion on feature request BUG-139203 tri counts / land impact / LODs and issues / exploits.

 

SL project updates 48/2: Content Creation User Group

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi

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

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” →

SL project updates 46/2: Content Creation User Group

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi

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

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.

 

SL project updates 45/2: Content Creation User Group

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi

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

Viewer Progress

[3:51-5:33] The project viewer updated to version 5.0.9.329815 on Thursday, November 9th.

  • The major change is that Animesh linksets can now include non-rigged items (e.g. prims), and allow the root objects to be a prim rather than a rigged mesh.
  • Animesh objects should now render the same way as mesh attachments and generate shadows.
  • The viewer also includes a number of bug fixes.

[42:25-44:50 + text chat] However, while the root of an Animesh object can now be a prim, this doesn’t mean mesh objects such as pets can be dropped in-world (e.g. so someone could “pick up” their Animesh pet, carry it, then put it down again somewhere else), because the code required for “dropping” mesh is not provided on the simulator on the ground that dropping meshes can cause physics issues.

Animesh Attachments

Note: there is an extensive discussion in text chat around this subject from the 13:00 minute mark which continues throughout the meeting.

[12:59-18:06] One of the major subjects of discussion with Animesh is enabling attachments to be added to existing Animesh objects (see here and here). In short, many pets and characters are created as No Modify objects, to help protect their capabilities. Thus, as No Mod objects, Animesh characters cannot be accessorized (the owner of an Animesh horse cannot add  / remove a saddle from an Animesh horse, for example). As Piscine Mackenzie explains in the forum, with highlights by Medhue Simoni, making Animesh pets  / characters Modify opens them to the risk of exploitation.

One proposal has been put forward via feature request BUG-139168. Vir Linden has also put forward a number of ideas. Of these, the mod key proposal (2nd bullet point in Vir’s notes and somewhat aligned to BUG-139168) is seen as a potential solution, with LlAllowInventoryDrop used to avoid the need for the root Animesh object having to be modify (and leaving it exposed to the exploits outlined by Piscine and Medhue). Vir is currently seeking further feedback from people on this being a possible approach, or if there are other potential alternatives.

  • [21:11-22:51] Two concerns on this approach are that a) any scripted mod key capability could be withdrawn at any time by the creator, potentially leaving users with broken content. However, there is no obvious means of safeguarding against this (unless it is made some kind of one-time function operation by the Lab, if possible); b) there is a risk the mod key could be accidentally exposed / leaked in being shared between those using it.
  • [25:52-26:12] The most “obvious” means of handling this issue would be to implement a change to the permission system to cater for the specific user-case of allowing attachments to be added to Animesh objects. However, the Lab is hesitant to consider such changes due to the risk of unintended impact, risk of content breakage, etc. As such a precise proposal on how to update the permissions system and the use cases it would meet would have to be properly defined for consideration.
  • [28:15-30:40] A suggestion is made to have a new flag “only allow scripts compiled by the object creator run on this object”. However, this could limit cases where models are built by one person, animated by another and scripted by someone else, or situations where a creator is using full permission scripts sold by another creator, etc., and so seen as potentially less than ideal.
  • [56:07-1:01:56] Determining whether Animesh attachments capabilities (e.g. using the mod keys idea) can or cannot be implemented relatively easily is seen by the Lab as a critical aspect to moving Animesh towards a release. If doing so proves problematic, the project will likely move ahead without such a capability being implemented. In the meantime, as there isn’t currently an available solution, creators are advised to handle Animesh the same as any other product they are developing for the time being, and focus on Animesh at the functional level.
    • [1:01:57-1:05:05] An example of complexity is defining how a mod keys capability would work. If it is limited to one specific group of people creating a poduct line, it is relatively easy to control. However, if a creator wants too support an ecosystem whereby other creators can all offer attachments for a product, then it becomes far more complicated in terms of keeping the mod key secure.

Given the complexity of this subject, continued discussion through the Animesh forum thread is encouraged.

Animation Playback Speed

[51:47-52:37] It has been noted that the speed of the animation depends on the distance from the viewer’s camera to the animated object – see BUG-134259 and this MP4 (note particularly the two elephants). This appears to be the result of the debug UseAnimationTimeSteps being set to TRUE (default viewer behaviour). Setting it to FALSE fixes the issue, and doesn’t appear to cause any other performance impacts.

Land Impact and Other Limits

[54:53-56:05] It’s unlikely that the current baseline limits (LI, tri count, rendering), will be altered  until there is confidence that the viewer functionality is relatively stable in terms of features, bugs, etc., at which point reliable performance testing can begin. Once this point is reached, then the Lab will be able to gather reliable data in order to start adjusting / potentially relaxing the limits.

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

[8:25-10:32] Rider Linden is “very close” to removing the old windlight environment code from his EEP version of the viewer, allowing it to use all the new EEP assets, allowing the local environment to be set via windlight inventory assets.

Once this can be done, test regions capable of supporting the assets will be established on Aditi (the beta grid), and a project viewer will be made available for more general testing.

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

Current Progress

[35:41-36:33] The performance testing has been carried out, and the results point to the need for additional bake host servers to account for the additional load in handling the higher resolution textures.

Other Items – In Brief

  • [36:30-37:29] Region crossing loads: the question is asked about what is the biggest load / cause of lag on region crossings (direct or TP). The short answer is scripts. That is, suspending them, saving their state, packaging them, handing them off to the next simulator, unpacking them alongside everything else (e.g. the avatar and / or vehicle they are running against), setting them back to running from their saved state. Obviously, the more individual scripts an avatar (+ vehicle, where used) is running (regardless of individual script size), the bigger the load placed on the hand-off process / receiving region.
  • [47:03-47:19] Materials system update: this is frequently requested, but currently the Lab do not have any plans to revisit the materials system.
  • [49:32-49:45] Cannot pathfind through a hollow object – intentional? Short answer – yes; physics simulations going into concave objects is expensive
  • [49:45-50:18] Will RenderVolumeLOD be revisited? – Short answer – yes, as a part of the work in re-evaluating rendering costs, land impact, etc.

 

SL project updates 43/2: Content Creation User Group

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi!

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

Audio extracts are provided to provide additional content. Note that some of the audio extracts have been gathered from various points in the meeting and presented here as a concatenated whole by subject heading for ease of reference.

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).

General Status

  • The project viewer is now available, and testing can be carried out on  5 regions (4 Moderate + 1 Adult) on Aditi: Animesh1, Animesh2, Animesh3, Animesh4 and Animesh Adult.
  • Feedback can be offered through the Animesh forum thread, while specific issues, bugs, and / or feature requests related to the project should be made via JIRA.
  • A filter for raised JIRA reports is available.

Root Prim Object

There have been a number of requests to allow Animesh objects to have a non-rigged mesh (e.g. a prim) as the root object. Vir has been working to make this possible. He’s also looking at the issue of non-rigged mesh links in an Animesh object becoming invisible when the Animesh flag is set.

Limits

As has been mentioned numerous times in these updates, Animesh will have some constraints / limits placed upon it in the interests of the capability not unduly impacting performance. For the purposes of test, these have been set at 200LI and a maximum of 20K tri maximum per Animesh object, and only one Animesh can be attached to an avatar at a time. As data is gathered on performance, etc., it is hoped these can be relaxed; however, some creators are requesting limits such as the tri count be raised sooner rather than later. Vir, understandably, would rather wait until more data has been gathered, rather than randomly changing constraints.

There has been a proposal for an alternative method of account put forward with regards to Animesh – BUG-139203.  Vir also reiterated the likelihood that the Animesh limits, once finalised, will have a smaller emphasis on constants such as land impact or the cost of having one attached, and a greater emphasis on the complexity of the Animesh itself (tri count).

Linksets / Permissions Issues

See also Piscine Mackenzie’s forum post on this.

As currently defined, Animesh does not allow for any avatar-like attachment  / detachment of objects (e.g., allowing a pet cat to wear a hat sometimes); the approach is more along the lines that everything that is intended to form the Animesh is attached as the time to object (/linkset) is flagged as Animesh.

This is because adding an avatar-like means of supporting attaching / detaching objects was seen as too high an overhead in terms of development time frames and complexity – although it is not entirely ruled out as a possible future capability.

In the meantime, scripted means to attach / detach items from an Animesh object is possible, but this requires the base Animesh to be modifiable. As detailed in Piscine’s post, and highlighted in the following post from Medhue Simoni, this opens the door to potential exploits / threat vectors (e.g. compromising a supporting ecosystem for pets / breedables to the potential for launching DDOS attacks against the external servers managing pets and breedables).

Vir recognises the issue, and has stated he’ll look into the in more detail. One possible solution has been suggested via feature request BUG-139168, and a possible scripted workaround has also been suggested – although it potentially has its own problems.

An offshoot of this is that it could lead to people including multiple accessories within the Animesh linkset. The problems here being a) doing so would immediately require much higher tri counts per object even after the current 20K limit is raised; b) it will require alpha swapping to hide / reveal different accessories, creating performance hits; c) it will limit the ability for new accessories to be easily added to creations.

Sitting Animesh Objects

Will it be easy to have Animesh sit on other objects (e.g. to have Animesh “mannequins” which could be used with demos of furniture so couples poses could be checked by just one person, etc)? Short answer: not easily. Sitting on objects is avatar-specific, which, among other things, involves re-parenting the avatar to the object it is sitting on, and there is no means to replicate this when trying to “sit” an Animesh (which the server sees and just another in-world object) on another object.

In Brief

  • Lack of Shadows with Animesh objects: this is a know bug, thought to reside within the rendering pipeline, which has yet to be tracked down.
  • Dropping mesh: as noted in my previous CCUG update, by default, mesh attachments cannot be dropped in-world. This means that the only way to currently “pick up” and “put down” an Animesh pet which can roam in-world / be held, is via inventory. Vir has been looking at this, and it is not any easy fix, requiring server-side work (including with physics handling to ensure things land correctly – such as pet on its feet rather than on its side / head) which may preclude it being dealt within the immediate future.


Medhue examines Animesh. Via Medhue Simoni

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. 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 mesh surfaces. 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.

Current Progress

Load testing with the updated server using 1024×1024 textures is in progress. The next phase is liable to be comparing the load test data with that of an existing baking server using 512×512 textures.

Bakes on Mesh and Animesh

Because of the complexities involved with Bakes on Mesh, it is not seen as a dependency for Animesh, as doing so would greatly extended the time frame for delivering Animesh. The Lab would rather implement both incrementally, rather than try to run everything into one huge project.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds) 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

No major change from my previous work. Rider has been working on a simhost issue unrelated to EEP for much of the time.

Final Notes

  • Those requiring access to the JIRA to comment on files issues / request, can send an e-mail request to LetMeIn-at-LindenLab.com.
  • There is no CCUG meeting on Thursday, November 2nd, 2017. The next meeting will be Thursday, November 9th.