Category: SL User Group Meetings

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.