Category: SL User Group Meetings

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

The choppiness in some of the audio segments where Vir’s voice drops out is due to issues with SL Voice.

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

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Release Candidate Viewer

As noted in my Simulator User Group updates and Viewer Release summaries, the Animesh viewer was promoted to release candidate status in week #33 with the release of version 6.0.0.518579 on August 13th, 2018. The three key points of this are that:

• Animesh is one step away from being the de facto viewer release – although this is dependent on a range of factors, including the other RC viewer in the pipeline, the viewer’s performance whilst at RC, etc.
• Animesh capabilities will now naturally be available more widely among users of the official viewer.
• Third-party viewers are now officially allowed to incorporate Animesh in their offerings.

Server-Side

Animesh has been on general release server-side across the grid for the last couple of weeks, and thus far, no problems have surfaced with in. However, this could be due to a relatively low usage of the capability up until now, given it has only be available within project viewers.

Sample Content Rotation

As noted in past CCUG summaries and updates in these pages, a  workaround for rotation issue with uploaded models now means that some of the Animesh sample content provided by the Lab – such as the raptors used in the GIF file I often use to banner these reports – now crab sideways rather than walking forward when seen in the Animesh viewer.  Following a suggestion put forward at the meeting, Vir is going to see if the affected content can be updated so that it moves correctly and can be provided as samples for people wanting to play with Animesh without potentially confusing them.

It’s also been pointed out that the scripts used within the sample content are very specific to that content, and so could lead to problems if people try to pull the scripts and use them as templates. However, Vir is uncertain as to how generic the scripts can be made in order for them to work as templates.

Bugs

There are still a number of bugs the Lab is working on in relation to Animesh. These should be listed in the JIRA filter (link above), and are related to some Animesh editing issues, animation stop / restart issues, and some lagging, possibly due to the underlying skeleton lagging behind the animation playback (so the Animesh isn’t properly oriented as an animation starts to play, for example). Not all of these issues may be fixed before Animesh reaches de facto release status, but Vir is continuing to try to work through them.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

• The ability for region / parcel owners to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
• New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
• There are no EEP parameters for manipulating the SL wind.
• EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
  • These will be an atmospheric effect, not any kind of object or asset or XML handler.
• The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
• EEP will not include things like rain or snow.
• It will still be possible to set windlight local to your own viewer.

Resources

• Project definition document.
• Project summary (this blog).

Current Status

Alex Linden from the product team has been working on internal testing with Rider, and is now in the process of moving the pieces into place to have EEP deployed the Aditi (the beta grid).  Rider believes that a project viewer should be surfacing “very, very soon” as a result.  The plans for the project viewer are:

• • Get the assets support in to the first release.
  • Hopefully include crepuscular rays (“Godrays”) and work on shaders for distance fogging and atmospheric density in the first release of the project viewer as well. However, as these are in fact another shader, they may not make it into the initial cure of the project viewer, depending on how things go.
  • Add the scripted ability to manipulate EEP assets at a later date, but before the viewer progress to RC status.

As well as discussing project progress, Alexa and Rider also indicated some of the things they’ve been playing around with while testing EEP.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

Still awaiting the AIS updates (see below). Once these are in place there are a couple of other back-end pieces that require putting into place.

AIS Update

Both EEP and Bakes on Mesh are awaiting a AIS (Advanced Inventory System) update that will provide the necessary back-end support for both projects on Agni (and Main grid), as each is adding new inventory asset types to Second Life. Currently, it is believed that the work on support for Bakes on Mesh is a little further along to allow it to take advantage of the AIS update, and the latter may start being deployed in week #35 (commencing Monday, August 27th, 2018).

In Brief

• In-world meshes bigger than 64m on an axis: there are no current plans to allow the upload of in-world meshes that exceed the 64m limit.  The main reasons for this are:
  • Vertex resolution: the larger the object, the greater the distance each vertex integer has to span, leading to inaccuracies in positioning (think prim drift for mesh), together with resolution degradation.
  • More particularly, the griefing potential and possible performance issues (e.g. rendering load on the viewer and possible implications for the physics engine).
• Sim surrounds: partially in line with the above (and also ARCTan, below, given the use of sculpts), the Lab is interested in learning more above how people might like sim surrounds to be addressed. Some ideas offered include: making surrounds a specific form of large mesh with physics automatically disabled at upload (possibly used with a special field within the Estate / Region floater they can be “dropped into” to be applied; continuing with sculpts (with their 1 LI advantage over other potential land impact loads & their potential to have a relatively low number of vertices and thus form relatively economical content).
• Project ARCTan: the project to recalculate object and avatar complexity will be progressing, however, it involves input from Graham Linden, who is currently focused on the shader / rendering work for EEP.   However, data collection is continuing.
  • People are starting to question what this will mean for sculpt(ie)s in SL – the majority of which tend to be horribly inefficient in terms of rendering. The short answer to this at the moment is the overall impact hasn’t been determined.
• Real-Time bounding box tracking: the question was asked whether the new bounding box calculations introduced as a part of Animesh will include “unused” joints (e.g. if the hind legs in the skeleton are not rigged to, are they included in the bounding box calculations?). short answer: no; with the exception of the original (pre-Bento) base skeleton joints (as used by the system avatar).
• Next Meeting:  Thursday, August 30th, 2018.

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

The choppiness in some of the audio segments where Vir’s voice drops out is due to issues with SL Voice.

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

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Server-Side

As of the SLS (Main channel) grid deployment on Tuesday, August 5th, the server-side support for Animesh is now grid-wide.

Animesh Viewer

Vir has completed work on the next update to the viewer, which includes a number of fixes and tweaks. This is currently with the Lab’s QA team. If all goes according to plan, this could see the light of day as a Release Candidate viewer. In particular, this update should include a fix for the bounding box / LOD issues previously reported in these summaries.

General Discussion Points

• The LI accounting aspect of Animesh is considered “complete” for the initial release, and no further changes beyond the accounting values Vir has published via the Animesh forum thread are expected.
  • However, there may still be future revisions to the overall Animesh costs (complexity) as a result of the Project ARCTan work to overhaul all of the complexity calculations in order to make them more reflective of the actual costs involved in rendering, etc., different objects. This work has apparently been on hold recently.
• Land Impact: streaming costs / LODs: there was further discussion on the 50% bounding on LODs.
  • Concerns have been raised at the disparity between the 50% cut-off between the high and medium models compared to the GLOD (Global LOD) cut-off of around 30% (so 70% discarded). Other concerns relate to the 50% between the medium and low models disincentivising creators from trying with a low model. An overall concern is that people will continue to look purely at land impact, rather than considering complexity and optimisation as matters of improved performance.
  • Vir admits the approach taken with Animesh is something of a trade-off between trying to encourage considered use of LODs and implementing a system that “scares people off” because of its demands. As such, it is something that may be revisited as a part of ARCTan, after more data has been gathered as a result of Animesh being released in the meantime.
  • A major difference with the “new” system is that it no longer considers scale. This means that creators who animate their creatures using a combination of multiple models and using alpha masks to hide the “unseen” versions and who reduce the “unseen” models to avoid them raising a creature’s LI, will no longer be able to do so.

• Per-bone scale animations: having the ability to use per-bone scale animation, which could be particularly useful for non-human bodies (and now Animesh) has been  a request since Bento.
  • Currently, the SL animation format doesn’t allow scales to be specified, so an overhaul of the animation system would be required to make this possible.
  • A further problem is scale animation can conflict with any use of the shape sliders, when used to modify an avatar shape (one of the items under consideration for a future update to Animesh is support for a body shape and the use of sliders).
  • The benefits with scale support include:
    • The ability to create a single creature body and use it in different species of that creature without the need to develop new animations and new rigged attachments (so a “dog” body could be used for a Labrador or a Chihuahua or Dashhound).
    • The ability to have “young” creations (babies, puppies kittens, hatchlings….) “grow” over time.
    • The ability for creators to develop a broader range of different NPCs and different creature types without having to rely on the avatar shape / slider system, which is inherently biased towards human forms.
  • An alternative to animation scaling (and subject of a feature request) that was initially made during Bento, was to have an overall body size slider that could proportionally adjust the entire size of the shape associated with an avatar (and Animesh, if shape and slider support is added to Animesh in the future).
    • One issue with implementing this at present is that the message format use to communicate slider parameters may not support the level of messaging required to communicate an overall rescaling that affects every joint and bone position at once (which would require updates to the Appearance  and Bake services as well, so this would require an overhaul.
    • A further issue is that of locomotion:  the same overall locomotion graph is used regardless of size, so in a single stride, a very tiny avatar made using a “size slider” could  appear to move the same distance as a “normal” sized avatar, which can result in it appearing to move really quickly;similarly a really tall avatar created using a “size slider” could appear to hardly move at all each time it takes a step. So, the locomotion graph would need to be overhauled.
  • Use of per-bone animation scaling hasn’t been ruled-out, with Vir pointing out that even adding body shape and slider support to Animesh is complex, requiring further updates to the Appearance and Bake services in order to work. So it might be something to consider alongside of considering shape / slider support once the initial Animesh project is released.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

There do not appear to be any blockers within the project preventing it from moving forward. However, as indicated at the July 27th TPV developer meeting, there are some changes being made to the AIS system, and the updates to inventory required in support of Bakes on Mesh (which also requires updates to the Appearance and Bake services as), are currently awaiting that work to be completed.

Environment Enhancement Project

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 that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
• There are no EEP parameters for manipulating the SL wind.
• EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
  • These will be an atmospheric effect, not any kind of object or asset or XML handler.
• The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
• EEP will not include things like rain or snow.

Resources

• Project definition document.
• Project summary (this blog).

Current Status

EEP remains on internal testing at the Lab, although as I noted in my previous CCUG summary, Rider has been teasing us with images in the forums. According to Dan Linden. the viewer UI is “pretty much” complete, and work is focused on some of the back-end messaging, which appears to be holding things up. There may be a further update on status at the next TPV Developer meeting on Friday, August 10th.

Other Items

• 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).  This is still within Graham Linden’s pile of work.
• Next Meeting: the next CCUG meeting for August 2018 will take place on Thursday, August 23rd.