The following notes are taken from the Content Creation User Group meeting, held on Thursday January 12th, 2017 at 1:00pm SLT at the the Hippotropolis Campfire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are available on the Content Creation User Group wiki page.
Core Topics
- Bento request from Troy Linden.
- Supplemental animations that run alongside the main animation (e.g., flapping wings while walking).
- Possible future project – applying baked textures to mesh avatars.
Bento Request From Troy Linden
Troy Linden is preparing a presentation on Project Bento for an upcoming Second Life meeting within Linden Lab in which he plans to review the project, the interactions with content creators, the benefits this brought to the project, etc. In particular, he would like to demonstrate Bento content people are making and impress on LL’s executives how the project has been received, and how things might be followed-up.
To help with this, he is requesting that anyone with glamour shots of Bento avatars, etc., videos of avatars and Bento items to contact him via IM to discuss and / or send him what they have (troy-at-lindenlab.com).
Supplemental Animations
Introduced in 2013, llSetAnimationOverride() is one of a series of animation commands keyed directly into the server’s animation states, allowing for faster, smoother animation state changes than with AO systems using the older llPlayAnimation() command. However, llSetAnimation() only allows one animation to be played at a time for any given state, and this can lead to conflicts when trying to run custom animations as well (see BUG-41048 . An example of this is trying to use llSetAnimationOverride() to walk whilst using an animation to flap wings (below), which causes while the walk, set by llSetAnimationOverride(), to freeze in favour of running the wings flapping, as they are also seen as a locomotion animation.
Vir has identified two possible courses of action to deal with this. The first would be to extend llSetAnimationOverride() to allow “supplemental” animations to run alongside the animation states keyed by llSetAnimationOverride(), effectively allowing them to play together. The other would be to provide a means for people to define their own custom animation states (with associated animations) which the simulator would be able to recognise and handle alongside the existing animations states, rather than having the associated animation conflict with the default animation states.
No decision has been made on which route to take, and Vir is putting together a proposal on approaches, which he’ll put forward at a future meeting.
Applying Baked Textures to Mesh Avatars
This would allow the skin and clothing layers (skin, tattoo, under shirt, shirt, etc., “wearables”) to be directly applied to mesh avatars. In theory, this could be done, and could make it easier to do things like match skins between, say a mesh body and a non-mesh head without having to use applier systems. It could in theory even reduce the complexity of mesh avatars, which currently have to be made up of multiple layers (the so-called “onion meshes”).
A further benefit would be for non-human avatars a well. Providing the same UV is used across all elements of an avatar, it could allow creators to offer different pelts / skins for their animal / creature avatars and, if they make their UV maps available to other creators, allow them to produce things like additional skins.
However, there are problems in proceeding this way.The baking service is capped at a limit of 512×512 texture resolution, which would mean a loss of detail trying to “stretch” such textures over a mesh avatar, which would result in the ability potentially being ignored in favour of using the current “onion mesh” and appliers approach. It might also mean that wearable layers would be used in non-standard ways (e.g. using a “skirt” layer to apply a skin), which could lead to user confusion (“why am I using a skirt to wear a skin?”) – although this could be overcome by adding further wearable types specific for use with avatar meshes to the system.
An alternative would be to increase the texture resolution for the baking service to 1024×1024. While not entirely ruled out, it does carry with it a set of unknowns as well – what would be the back-end resource hit, could it lead to an uptick in texture trashing issues in the viewer, etc.).
Baking Textures on In-World Mesh and prim Surfaces
Part of the above discussion overlapped with the idea of allowing textures to be baked on arbitrary meshes (thus allowing for compositing, etc).
Vir noted that this would be a far more complex project due to the nature of the baking service, and thus would likely not be considered as a part of making changes to how system wearables might be applied to mesh avatars. However, he is interested in seeing feature requests on how this might be done and the benefits it would bring to SL, and a related JIRA – BUG-7486 – is in the process of being re-opened for comments along these lines.
Other Items
The latest version of Avastar is support of Bento is still undergoing testing. Those using it report it is behaving well, so hopefully a realise won’t be too far off.
