2018 SL project updates 24/2: CCUG meeting summary w/audio

MindPillars, a Scottish themed Sim; Inara Pey, May 2018, on FlickrMindPillars, a Scottish themed Simblog post

Updated on June 15th: to include planned RC channel for Animesh deployment – see notes below. 

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

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

Animesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

Resources

Current Status

It now appears that Animesh could be arriving on the server-side release channels on the main (SLS) grid as early as week #25 (week commencing Monday, June 18th, 2018). There are caveats to this: the status of issues with the viewer being one of them – there are certain issues the Lab is focused on, which they would ideally like to have some fix / workaround in place for prior to deploying the Animesh simulator code to Agni.

Update: At the TPVD meeting on Friday, June 15th, Oz Linden indicated that if the Animesh simulator code is deployed to an RC in week #25, it will most likely go to BlueSteel.

Current Viewer Issues

Encroachment / Position / Offsets: this is to ensure that the visual position of an Animesh object is not too far offset from its position as calculated by the simulator (e.g. using things like animation offsets to alter the visual position of all or part of an object). The fix for this is to force the bounding boxes for all joints and the meshes attached to them to remain within a specified distance – most likely 3 metres, although this is still TBC – from the location where the simulator has calculated the object should be.

This update should be in the next update to the Animesh project viewer, and will also utilise new infrastructure on the back-end to allow smarter tracking of the bounding boxes for rigged meshes. This be being done by tracking bounding boxes on a per joint basis, and then transforming them. While it can take a “noticeable” mount of time to do this, Vir’s belief is that it doesn’t unduly impact performance, although if it does become an issue, it may be re-thought.

Concerns were expressed that this would limit the scaling of Animesh creations. Vir states this shouldn’t be the case – the restriction is not ties to scale, but to position. So, for example, a dragon could still be 60 metres in length / height,  but the encroachment fix would mean where it appears in people’s viewers cannot be offset more than 10 metres from where the simulator calculates its actual position to be as a static mesh.

Z-Offset Height Setting: until now the z-offset height setting that can be specified when uploading a mesh to Second Life has been ignored when using meshes with it set to Animesh objects (the offset only works when the mesh is attached to and avatar).

It is hoped an update to fix this will be in the next project viewer update, which should appear before the server-side Animesh code arrives on an Agni RC channel.

Rigged Mesh Level of Detail / Bounding Box Issues: (BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box.

This is a long-standing issue which Graham and Vir Linden are working on, but a fix is unlikely to be available prior to Animesh arriving on Agni.

Broken Rotations Issues:

  • In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
  • The second problem is that when linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.

The recommendation here (for the time being) is that Animesh objects should have a non-mesh root object, and associate any physics representation to that non-mesh root object.  This should hopefully eliminate the current issues and help ensure that any mesh being propelled via scripts in the root object will move in a predictable manner (.i.e. moves forward when driven forward by a script).

Other Issues

Additional bugs: the above are not the only bugs being looked at, but they are the ones causing the most concern due to the risk of behavioural issues / changes they might cause, together with perceived content breakage, when Animesh starts being deployed to the Main grid. Other issues, which are not seen as having so direct an impact will continue to be looked at ad hopefully resolved as Animesh is tested on the Main grid, together with any other issues which may come to light.

GLOD: there is concern that the global LOD values set by the mesh uploader when creators don’t specify their own custom LODs incorrectly encourages poor optimisation, by rewarding those so decrease the calculated LOD values with lower LI post-upload. The feeling is that the reverse should be true. It’s anticipated that Project ARCTan should help to address this.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

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

Resources

Current Status

A new Bakes on Mesh project viewer arrived on Thursday, June 14th. Version 5.1.6.516270 includes the new “universal” wearable types corresponding to the 5 new bake channels. These are:

  • LEFT_ARM_TATTOO – bakes to the mesh left arm.
  • LEFT_LEG_TATTOO – bakes to the mesh left leg.
  • AUX1_TATTOO – creator definable layer / channel.
  • AUX2_TATTOO – creator definable layer / channel.
  • AUX3_TATTOO – – creator definable layer / channel.

Note that none of these additional wearables can be applied to the system avatar mesh; which continues to use the original six bake channels.

It’s also not clear if alpha layers can mask these new channels at present. If not, that Vir agrees it is something that should be looked at.

Other points of note:

  • There are no plans to extend Bake on Mesh to allow the use of wearable on non-wearable objects. This is because Bakes on Mesh uses the avatar bake service, which is not geared to apply wearables to in-world objects sans an avatar shape.
  • There is no time frame for Bakes on Mesh deployment at the moment; the project is still in the process of being developed, tested and refined with the help of content creators.
  • There is no updated on any form of scripted control for Bakes on Mesh. It hasn’t been ruled out, but no work is currently being done for scripted support.

In Brief

  • Mesh uploader cost formula / calculations: there have been requests to offer a clearer explanation of mesh cost calculations through something like a clarified wiki page. In terms of Animesh, providing guidelines on potential cost is difficult, as the actual conversion of a mesh to an Animesh takes place post upload.
    • One suggestion to help estimate Animesh costs is to add an Animesh model type to the drop-down list of object types in the mesh uploader.
  • Bento .BVH animation issue: the .BVH format allows for custom joint names for animations in addition to the default joint names. One such custom schema is to prefix joint name with “avatar_”. However, it has recently come to light that while the use of “avatar_” on pre-Bento joints works, trying to upload animations using any of the Bento bones prefixed with “avatar_” results in either an error message on upload (the SL viewer) or the animations uploading, but then being ignored on playback (tested with Firestorm). A JIRA bug report has been requested for this.
Advertisements

2018 SL project updates 22/2: CCUG meeting w/audio

Soul2Soul Med; Inara Pey, May 2018, on FlickrSoul2Soul Medblog post

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

Animesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

Resources

Current Status

Server-side support should now be largely “done”. There remains one issue awaiting resolution. Once this has been cleared, discussions will start on wider deployment of the code – potentially Aditi first, then to an RC channel on Agni (the Main grid). Still no release date due to ongoing work on the viewer.

Rigged Mesh Level of Detail / Bounding Box Issues

(BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box.

A new approach to resolving this is being attempted which involves removing non-rigged mesh asset sizes from the rigged mesh bounding box.This will not involve changes to avatar scaling / height calculations. If it works, it should result in better bounding boxes for avatars and rigged mesh attachments in general, not just for Animesh. Currently, it is awaiting some back-end updates.

Avatar Limits and Cost Calculations

These were revised several weeks ago – see the link to Vir’s update in the resources list above – and are unlikely to change. At the previous CCUG meeting, there was some discussion over the streaming cost calculation for the Medium LOD, but again, this will not be changing.

Vir reminded people that the ARC calculation for Animesh is now related to the streaming cost calculation (as per the current project viewer – version 5.1.4.515420 at the time of writing). It therefore shouldn’t be subject to quite the same kinds of issue related to scale-based distortions as previously. It may also go through further tweaks.

On a broader note, costs (streaming, impacts, etc.), are going to be looked at as a part of a separate (to Animesh) project – Project ARCTan – see below.

Broken Rotations Issues

These comprise:

  • (BUG-139251), some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
  • When linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.

No updates on these were available at the meeting.

Joint Offset Constraint

Setting (either deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results. To prevent this, a 5m joint offset constraint was introduced in the project viewer. This has / will be now backed out as it has been seen as overly restrictive. An alternative solution will be sought, and Vir hopes that having a fix for the bounding box issue (above) will help in this.

Animesh and Attachments

There has been confusion over Animesh and attachments. In brief:

  • One one Animesh object can be attached to an avatar at a time.
  • Animesh objects, while they have a skeleton, do not support avatar-style attachments. Instead, additional objects (e.g. a collar for an Animesh puppy) should be made a part of the Animesh linkset, and then driven by the Animesh skeleton / scripted animations within the Animesh (although objects in n Animesh linkset could be animated by their own scripts / animations if required).
  • The above has been discussed at length in previous meetings, due to concerns as to how No Mod Animesh items could be made to work with different options (e.g. a puppy wearing different styles of collar).

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

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

Resources

Additional Bake Channels

Anchor Linden has been working to adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators). All of these had been intended to be extensions to the tattoo layer. However, in testing, it was found that feeding a wearable layer with these new channels to a viewer without the necessary support to use the channels, the viewer gets “unhappy”.

To avoid this, this Lab has opted to create a new wearable type which will know about these new bake channels. It will sit above the tattoo layer and below the clothing layers.  This should allow those wishing to make use of the new channels to do so without risk of impacting older viewers, which will simply ignore any new wearable layer they’ve not previously encountered. The flip side is, this extends the amount of work required to introduce a new wearable to the inventory service, in additional to the simulator, appearance service and viewer changes already required were the tattoo layer to be used.

A name for the layer has yet to be determined – but “universal” is under consideration – although Rider Linden (with tongue firmly in cheek) suggested “Bob”.

Scripting Support for Bakes On Mesh

No decision on whether this will be addressed, or if it is to be addressed, whether it will be a part of the initial release.

Continue reading “2018 SL project updates 22/2: CCUG meeting w/audio”

2018 SL project updates 21/2: Content Creator User Group

La Clef des Champs; Inara Pey, May 2018, on FlickrLa Clef des Champsblog post

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

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.

Current Status

  • Work is continuing on moving towards a main (Agni) grid deployment of the server-side code to support Animesh.
  • Everything has been through QA, and there is a remaining issue with validating attachments. This is liable to require an additional fix.
  • It is likely that the simulator code will initially be deployed grid-wide on the beta (Aditi) grid for a shakedown period, prior to starting its deployment to the main grid through the usual process of RC deployments ahead of a full deployment.
  • There are still a number of issues that are TBD within the viewer:
    • Broken Rotations Issue: two potentially related problems.
      • In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
      • The second problem is that when linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.
      • What is to be done about this still hasn’t been determined, although the Lab has been playing with playing the physics shape in the root of the object.
    • Rigged Mesh Level of Detail / Bounding Box Issues: (BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. Graham linden has been working on some fixes for this which should improve accuracy and performance, but further work may be required. Once this has happened, there will be a further update to the project viewer.

Additional Animesh Discussions

  • Animesh Complexity: there is a further update to come to the Animesh complexity values (Advanced menu > Performance Tools > Show Avatar Complexity – applies to both avatars and Animesh objects in the project viewer). This should fix some inconsistencies in the reported values.
  • Animesh updated limits and cost formulas discussions:
    • Land Impact: streaming cost: some have questioned with some question with the 50% bounding on LODs could be more stringent. Vir’s view is that 50% is sufficient to allow for a broad range of capabilities among creators, and being more stringent could simply result in a greater addition to land impact, which could affect the use of Animesh. There is an argument that some models require 75% bounding between the high and medium models.
    • Triangle count limit: There have been requests for further changes to the triangle count limit (e.g. allowing land owners to somehow be able to change it). As the limit was raised to 100,000, it is unlikely to be changed again before Animesh is deployed, and the idea of land owners being able to adjust it is seen as potentially in inconsistencies in how Animesh works in different locations. If it is seen that there is a need to raise the tri count limit, it will be done globally.
    • Avatar attachments: due to performance concerns, the limit of only one Animesh attachment to an avatar at any given time is not going to be changed ahead of Animesh deployment, but might be revisited in the future.
  • Animesh ignores SL scale settings:  this is a result of how rigged meshes are handled – scaling doesn’t matter for worn mesh items, as other mechanisms are available for avatar scaling (e.g. the shape sliders, etc.). As these mechanisms aren’t available for Animesh in the initial release (e.g. there is no actual body shape associated with Animesh objects, ergo, no sliders), scaling is dependent upon custom joint positions.
    • Including more capabilities, such as possibly associating a body shape with an Animesh object, is seen as being a follow-on project to come some time after the initial release.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

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

Resources

Additional Bake Channels

Anchor Linden is continuing to work on adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators) and the associated tattoo layer UI support to the viewer to allow them to be used.

This is a three-way set of updates, requiring changes to the appearance service, the simulator and the viewer. This, combined with concerns over maintaining backwards compatibility in the appearance service means that getting the work to a testable state is taking a little longer to achieve.

In the meantime, the changes to the appearance service seem to have caused a glitch which can make some avatars appear to be wear “black skirts” when seen on the Animesh test regions Aditi. This will hopefully be corrected soon.

In Brief

Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette).

Graham Linden is now looking at the issue, however, the release of Animesh is not contingency on the basis of any fix, which will probably be part of the ongoing rendering updates Graham is working on.

Rigged / static meshes using transparencies (blended or masked) tend to cast an incorrect shadow

Imposter Clipping: imposter avatars can appear “clipped”. This appears to be related to the problem of not having a good real-time bounding box associated with rigged meshes (which can result in some meshes appearing clipped as well). This is being looked at, and the hope is that if a better means of defining the bounding box for rigged meshes can be found, it will resolve the importer issue. However, the release of things like Animesh are again not contingent on a fix for this issue being implemented.

 

2018 SL project updates 20/2: Content Creator User Group w/audio

Bay of Dreams; Inara Pey, April 2018, on FlickrBay of Dreams – Blog post

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

Audio extracts from the meeting are included, where relevant. Please note, however, that Vir’s microphone occasionally seemed to cut out while I was recording, so some of his comments may sound a little choppy.

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.

Project Viewer

The Animesh project viewer was updated on Tuesday, May 15th to version 5.1.4.515420. This update comprises:

  • Bug fixes, including improved handling of animation notifications which should result in fewer cases of animations failing to display for some Animesh objects.
  • New checks on when a skeleton is needed for a nominally Animesh object  – now one should be present only when the linkset contains at least one rigged mesh, and this should update correctly when link/unlink operations take place, or other state changes.
  • The ARC calculations for animesh objects has also been updated based on some feedback with the previous build.

Alongside of this there has been a simulator update in support of some of the changes in the viewer (e.g. with regard to animation notifications and updates). Also, to help with persistent across things like region crossings and region restarts, animation information is now stored in the state of the Animesh object itself, when it gets serialised. However, there are reports the animation data is lost on a SHIFT-copy action.

Server-Side Work

As well as the simulator updates for Animesh mentioned above, the Lab is continuing with QA work on server-side support for Animesh to prepare it for deployment to the main (Agni) grid. However, no ETA as yet for the server-side code.

Remaining Major Issues

Rigged Mesh Level of Detail / Bounding Box Issues:This has been the subject of several recent CCUG report in these pages, and is the subject of BUG-214736. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.

Investigations had led to questions in the Lab of how to get things to behave correctly while recognising there may be broader performance issue that need to be addressed. So Graham Linden has been trying to make sense of what might be pulled into the current Animesh project to improve things and what might require a deeper dive into performance in general as a separate piece of work. So at present this remains in the category of “to be determined” in terms of moving to making Animesh available on the main grid.

Joint Offset Constraints: It’s been noted that setting (deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results (the cited example is an Animesh test bear on Aditi appearing to stand 75 metres off the ground when not animating). This has led the Lab to consider constraining he distance a joint can be offset to no more than 5 metres for Animesh objects. However, as this is recognised that doing so could break existing content, a more elaborate solution is still being investigated by the Lab.

Adjacent Regions and Animesh Animations: There is an issue where Animesh objects in adjacent regions fail to animate from a avatar’s perspective when someone logs-in. This is thought to be a handshaking / viewer update issue. Essentially, it can take up to a minute for adjacent regions to understand an agent (avatar) in another region can “see” objects within it, and needs to start sending animation updates to the viewer controlling that avatar.

90-degree Rotation Issue: It’s been noted that when converting some static mesh objects to Animesh, the visual mesh appears rotated through 90 degrees when seen in the Animesh viewer. However, the physics mesh doesn’t have the same rotation applied, leaving it perpendicular to the visible mesh – see BUG-139251.

This appears to be related to the fact that the viewer expects the mesh to be aligned to +x=forward – whereas mesh creation tools such as Blender and Maya don’t – by default – use the same orientation. As the issue only affects some mesh (and in theory could be corrected by setting the required rotation in mesh building tools), Vir asked the question if this is something that should be addressed in the viewer.

  • If this issue isn’t addressed in the viewer (which is where it manifests), it potentially means a good proportion of existing content which might otherwise be converted to Animesh will exhibit the same issue when associated with an avatar skeleton, possibly eliminating it from use as Animesh.
  • If the issue is to be addressed in the viewer, the problem is how to apply the logic to ensure mesh items which don’t exhibit the physics rotation issue don’t end up exhibiting the issue as a result of the fix being incorrectly applied.

Z-Axis offset un the Mesh Uploader: This currently doesn’t work when a  skeleton is applied to a mesh object.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

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

Resources

Additional Bake Channels

Anchor Linden is investigating adding further channels to the Bake Service in addition to those recently added, again specifically for use with Bakes on Meshes (they will not work with the system avatar). These will hopefully comprise:

  • Separate channels for the left arm and left (currently these are mirrored from the avatar’s right side) to allow for asymmetrical avatar options.
  • Three additional “general purpose” channels to be defined and used as required by creators.

These channels will eventually be surfaced as tattoo layers in the viewer, which will have an updated UI for creating new layers.

Injecting Texture Information into the Bake Stack

There has been a request to allow applier creators to use a scripted means to “inject” textures into the Bake Service via a script (see BUG-216137).

It has arisen out of concern that Bakes on Mesh a) won’t offer the same ease-of-use as HUD-based appliers many users are familiar with; b) it could make the majority of existing applier systems obsolete as mesh head / body creators move towards less complex “onion layer” designs, requiring applier makers to completely re-work all of their existing clothing options. Offering a means to provide Bakes on Mesh with a similar capability as applier systems and allow applier makers to more easily update their existing systems. However:

  • The proposed solution is a non-starter, as the Outfit system on which the Bake Service relies, has no notion of textures. Thus, offering a means to “inject” textures into the bake stack essentially creates a separate (and potentially conflicting) representation of the bake stack.
  • If it is seen that a more applier-like approach to Bakes on Mesh, any solution will form part of a follow-up project, rather than being part of the initial implementation.

 

2018 SL project updates 17/3: Content Creator User Group

Dragons by Wanders Nowhere, used in Animesh tests

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

Animesh Project

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.

Server-Side Updates

Vir believes the Lab is pretty close to a final set of Animesh updates for the server side of things. These include support for the Animesh updated limits and cost formulas, and it is expected that QA will be starting soon on the code in readiness for clearing it for deployment to the Main grid, Agni.

Joint Offset Constraints

One of the reasons the Lab is discussing constraining joint offset is an Animesh bear developed for testing purposes (and which can be found on the Aditi Animesh test regions) which sits some 75 metres off the ground, that’s due to a bad offset being set within the mesh and used with the mPelvis bone, which comes into play when the mesh isn’t being animated.

The bear itself was created as the SL10B wearable avatar, and so demonstrates what can happen with existing wearable content with such errors (which would not become apparent while the mesh is become worn, as the avatar tends to always be in a state of animation) is converted for use as Animesh.

Constraining the distance joints can be offset (say to 5 metres) offers one means of preventing this kind of problem; however, it is recognised that doing so could break existing content – such as the very tall avatar models that are available. Therefore the Lab is considering this an other, more complex options – such as doing something with the bounding box.

Animation Playback Issues

Some are still having Animation playback issues with Animesh objects, notably on initial rezzing or following a region crossing. The advice is it increase the number of animation updates being sent out.

Land Impact

There is some potential confusion with the land impact reports on the mesh uploader and when calculated for an Animesh object when in-world. The uploader calculates the LI for a mesh based on it being a static object. It is only when the object is toggled to Animesh in-world that the revised formulas for LI and complexity are used. This has in turn lead to issues for creators trying to determine what the likely weightings are going to be for their models prior to update.

There have also been some reports that on conversion, models not obeying the new LOD requirements defined as part of the within the new formula suffer heavy penalties when converted to Animesh.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box  (see BUG-214736). Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.

Graham Linden has been investigating this issue, and now has some updates for the viewer (yet to be integrated with the Animesh project viewer) which should help with this issue and encourage those creator who have, deliberately or accidentally, gaining an advantage from the issue to offers balanced LOD models for their content.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

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

Resources

Current Status

Anchor’s most recent work has been:

  • Completing the work to implement three more tattoo slots of the Bake Service: skirt tattoo, hair tattoo and eyes tattoo.  These are designed to extend the tattoo to the same set of slots as for the underwear and clothing layers, and hopefully make the available slots far more flexible in potential use when applying baked textures to worn mesh.
  • Continuing to work on the skirt layer stacking issue.

The basic functionality of taking system wearable layers and applying them to mesh faces is viewed as working. However, as per my previous Content Creation meeting notes, there is still a lot to be decided on how to progress Bakes on Mesh, particularly in reference to Bakes on Mesh and the applier market, and the overall convenience of Bakes on Mesh for applying textures to worn mesh faces, compared to “ease” of using applier systems for consumers.

Internal discussions about some of the ideas raised around this  – such as being able to inject textures into the Bake Service via script – are still be discussed within the Lab as a result of the concerns raised at the previous CCUG.

Bakes and UV Maps / Spaces

Bakes on Mesh has generated a lot of discussion on the effectiveness of custom UV maps and the Baking Service – UV maps being the thing that take was are essentially 2D textures and “wrap” them around a mesh object. In brief:

  • The system avatar has a set of pre-defined UV spaces associated with it. These are used by many of the mesh body makers, and so using system clothing layers via the Bake Service should work on these. Mesh heads tend to be different, and so issues can occur trying to apply skins, etc., to them.
  • The Lab’s view is that there’s no reason in principle why the baked textures must use the system UV space. So, for example, and providing none of the system avatar layers (such as the skin) are to be visible, it should be possible to use a set of tattoo layers defined in a specific mesh body’s UV space which can then be passed through the Bake Service and applied to a set of mesh faces regardless of the system UV space.

  • An issue here is that only tattoo layers can be used with custom UVs, as all other layers have “holes” in them designed to reveal the system avatar skin, allow for eyelashes, etc.  Therefore, it is not currently possible to re-purpose a shirt layer, for example.  Cathy Foil expanded on this, and on the use of system UV space with mesh bodies.

  • Vir expanded a little on the idea that some of the clothing layers that have more “intelligence” built-in (e.g. alpha masking support), hence why they would not work with custom UVs and it would be necessary to use tattoo layers for the textures and re-name them.

Within the meeting, this led to an extended discussion on UV options – such as the advantage of updating the avatar .LAD file and the viewer appearance editor  to allow the use of custom UVs or the system UV space (via an appearance editor check box) over re-purposing tattoo layers.

It’s like that initially, the Lab will lean towards re-purposing tattoo layers, rather than re-working the avatar .LAD and appearance editor, leaving it to body / head creators to offer updated UV maps for those cases where they don’t precisely follow the space UVs.

Next Meeting

There is no CCUG on Thursday, May 3rd due to a conflict with the Lab’s monthly internal meeting. The next CCUG will therefore take place on Thursday, May 1oth, location TBA.

 

2018 SL project updates 16/2: Content Creator User Group

A rally of (Animesh) raptors on Aditi

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, April 19th, 2018 at 13:00 SLT.  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 summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details.

Initially, the meeting opened on Aditi at the Animesh test regions.however, Voice issues across the beta grid regions resulted in the meeting decamping to the TPVD amphitheatre on Agni, and these notes reflect the meeting from that point onwards, starting at the 7 minutes 19 seconds point in the video.

Animesh Project

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.

Project Viewer

The project viewer with the updated Animesh land impact / tri count formula was released on Monday, April 16th. Version 5.1.4.514468 also brings the viewer to parity with the current release viewer.

Vir’s provides a detailed explanation in the Animesh updated limits and cost formulas forum thread, However, in summary:

  • Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
  • Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
  • Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
    • High LOD: all of the estimated triangle count included in the effective_tri_count.
    • Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.
  • These values are also reflected in ARC (avatar rendering cost) calculations for Animesh items.

[7:23-8:43] The viewer also incorporates a change where it will automatically switch to skeleton based rendering for Animesh as soon as it detects the use of an avatar skeleton in an object, rather than waiting until an animation starts playing on an Animesh object in order to make the switch. It is hoped this will avoid issues between an Animesh object’s static and animated states, which can cause visual glitches when the animation based switch is made. It should also avoid potential exploits with people using multiple Animesh objects without necessarily animating them.

[9:13-9:32] It is believed the majority of bugs for Animesh are now in hand, however if any finds specific issues with the new impact calculations or with the latest project viewer in general, they are asked to file a JIRA bug report.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

[8:44-9:12]  Graham Linden has been investigating these, as has some proposed changes which he and Vir hope to implement in the near future, the implication being these will be folded into the Animesh viewer.

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.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current Status

[10:35-11:05] Rider Linden has been involved in dealing with other issues, which have delayed progress on EEP. He hopes that with this worked cleared, he’ll be able to focus on getting the viewer updates out in a project viewer.

Continue reading “2018 SL project updates 16/2: Content Creator User Group”