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.

 

Advertisements

One thought on “2018 SL project updates 21/2: Content Creator User Group

  1. “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.”

    I quit attending the meeting exactly for this reason: incompetent “creators” claim so many triangles because they don’t know any better. 50% reduction on each lower LoD is a common, perfectly working standard for most, if not all, games. Not to mention the triangle limit being already quite high as it is, 100K triangles is a LOT already, and with that allowance i can make 2,5 full avatars, how is it possible that for one object 100K triangles can’t suffice? SL is NOT a modern platform and can’t afford that much. This kind of people should be kicked off the meeting at the first BS of the caliber i could hear from them and be not allowed to make content at all. It is easy to hit the smooth button to have all geometric detail so that they can release at machine-gun-like rates, but at what cost? These are platform smashers, lag creators and miserable modelers, nothing more. They claim more geometry at a fixed 1 Land Impact for anything, and therefore they came out with the GREAT idea that LoDs are irrelevant, set all of them to zero and tell their customers to raise the LoD factor in the viewer “because SL can’t any better”. Who buys this stuff pays for having a heavier, lag immersed SL with a crappy frame rate because that content is “cool”, made by “pros”. Bah… these customers should be aware that the price they pay doesn’t end witht he transaction, each single frame of their SL is also costing them a overloaded GPU which in turn will die earlier. But hey, that is next gen, super cool , high quality/polygons object, it is more professional than my average poly content. Keep going this direction, and you will kill SL earlier than its due time.

    Like

Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.