Category: SL Tech

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, August 30th, 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. Topics blow are not necessarily presented in the order in which they were discussed, I’ve attempted to group items by subject matter.

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

Current Status

In support of the server end of Animesh being grid-wide, and the viewer being in RC status, Vir Linden posted an update to the Animesh discussion thread in the forums.  The post underlines the point that now is the best time for some final testing of the initial Animesh capability before it rolls forward to a formal release in the not-too-distant future, when it will be harder to make changes out of concern for breaking existing Animesh content.

In particular, the post makes mention of the fact that moving forward, Animesh will see a behavioural change:

We will be enforcing a size limit on Animesh objects. This will give more consistent behaviour with other types of prims, for which size limits are enforced. The exact details of how this will work is still to be determined, but you should assume that Animesh objects cannot become arbitrarily large.

The reasons for this is that there is no upper limit imposed on rigged mesh objects (whereas all other types of in-world objects have a limit), and there is a concern that if Animesh is not capped, then people could make very large objects that generate rendering issues for those viewing it (see BUG-225331 for more), or as a means simply to grief.

What the limit is and how it is to be enforced is still TBA, but at the CCUG meeting, Vir indicated that the real-time bounding box calculations may be leveraged.

One bug the Lab are trying to poke at is “stuttering” with some Animesh motion. The underlying cause of this has yet to be identified.

Animesh and Resetting the Skeleton

Vir asked the question on when should a skeletal reset occur on an Animesh objects. For example: an Animesh dog has accessories that can be attached / detached by adding / removing from the linkset via script. Should the skeleton for the dog be automatically reset from the removal of an attachment, or should it be a manual reset by the user? Most attachments may not require a reset, unless they were altering the dog’s shape; however, forcing a reset could also mean any animations running on the Animesh would also have to be reset, making things a little complicated. The consensus opinion swayed towards leave things as is, rather than force a reset, and allow creators determine how to handle things.

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 viewer and 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

Bakes on Mesh is still awaiting the main grid deployment of the AIS updates needed to support the new Bakes on Mesh (and EEP) asset types. As noted in my previous CCUG summary, Bakes on Mesh also requires updates to a number of back-end services (e.g. the Bake Service), and to the simulator itself, all of which have yet to be implemented. The viewer, meanwhile is more-or-less ready, but may see a further project status update.

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

EEP is now described as being “very, very close” in terms of server-side support and a project viewer.

An issue with testing has been that a long-standing bug on Aditi (the beta grid) has meant that the Lab has been unable to set parcels them for sale, allowing users to purchase them (funds on Aditi are provided by the Lab – and are non-transferable to Agni! – so purchasing land there is effectively a zero-cost transaction to the user) and then carry out their own EEP testing. This issue has now been resolved by Rider and Ekim Linden, so parcels are now available on the beta grid for those wishing to test EEP once the EEP project viewer is available (as the necessary viewer-side update will initially be in that viewer), and assuming the server-side support hasn’t already been deployed to Agni to allow testing on the main grid.

Other Items

Animations: Obtain by Name or UUID? A Case of Permissions

The middle of the meeting saw a discussion on whether calling animations by name or UUID is “more secure”. In short, calling by name requires the animation to be in an individual’s inventory, and thus seen by the Lab as more secure in preventing theft. Calling by UUID opens the potential to animations being physically obtained from the CDN should the UUID be unfairly obtained.

The question was prompted out of concern that is it possible to remove animations (and other items) from No Modify objects ad use them elsewhere – which (it seemed) one or two creators want to prevent. This comes down to more to how the permissions system works, more than anything else (No Modify means an object cannot be physically altered or added to; it does not mean its existing contents cannot be removed). Preventing the removal of an objects contents (whether animations or anything else) would require a significant overhaul of the permissions system.

Link / Unlink Permissions for Experiences

A request was made no adding the ability for experiences to be able to request permission to link / unlink objects without the need for individual requests to be made for each link / unlink operation – something which could be useful with Animesh. This has been discussed in the past, but is seen as being a larger project than something specific for Animesh, although it is seen as a useful capability (along with the means to offer mod keys for No Modify objects). Right now it is unclear what form such a project to provide capabilities like this would be, or where it would fit in the overall SL enhancement roadmap.

In Brief

• Release Candidates and Project Viewers: generally speaking, if you are using either a Second Life release candidate viewer or a project viewer, you will not be automatically updated to an other viewer version, but you will be updated to the next available version of the RC or project viewer you are using, by the viewer update process. The exceptions to this are with RC viewers – such as the promotion of the viewer to release status (you will receive updates to later release promotions unless you opt to use another RC), or the RC is withdrawn (you will generally be updated to the current release viewer). Details on the release candidate viewer process can be found in my 2013 post: New viewer release process implemented.
• Experience Keys: Oz confirmed that there is a plan to allow Premium users to have more than one experience key (allowing them to make multiple individual experiences, rather than having to use the same one for different purposes). The time frame for when this will be implemented is still TBD, as it requires a certain amount of back-end work.
• Date of next meeting: Thursday, September 13th, 2018.

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.