SL project updates 42/2: Content Creation User Group

The Content Creation User Group Meeting, Thursday, 13:00 SLT

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, October 19th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live steamed the meeting to You Tube, and his video – in two parts – part 1 and part 2. These have been embedded as a playlist at the end of this article, as should play one to the next. Time stamps to the recordings are included below, and clicking on any of them will launch each video in a separate browser tab at the assigned point. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

  • Can be any rigged / skinned mesh which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Uses three new LSL methods to run or stop animations, or check which animations are currently running:
  • Can use many existing animations.

At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life. So Animesh objects will not (initially) have an avatar shape associated with them, make use of the viewer’s inventory floater or the server-side avatar locomotion graph for walking, etc., and so will not use an AO, and will not use the avatar baking service. Such capabilities may be added as a future phase of the project.

Viewer Progress

The project viewer, with supporting documentation, was released on Wednesday, October 19th. See the official blog post and my overview for more.

Testing – General Feedback

[video 1: 8:29-9:15] Vir re-iterated that the purpose of the testing is to uncover bugs, check the workflow logic, gather performance data, etc., and encouraged creators to try to push the capability by doing as many different things as possible to ensure this pass of Animesh results in a “good” release.

People have been using the test items provided on Aditi, and early reactions to to the capabilities have been positive. JIRA issues and requests have been filed, and Whirly Fizzle has created a JIRA filter for Animesh to make listing all current reports and requests filed for Animesh.

Some Noted Issues

[Video 1: 10:32-13:15] Animated mesh height placement: One issue with Animesh noted in the meeting is determining where on / above the ground an Animesh objects should be placed, with people noting that when enabling the Animated Mesh option in the viewer, an Animesh creature / avatar can sink into the ground somewhat – as can some Animesh objects which should appear to be attached to an avatar, such as at the hand attachment point.

This appears to be an issue within the baking service which will likely require an update. In addition, Vir is hoping that testing will reveal more about height offset positioning so that the workflow for calculating where Animesh objects appear to be can be further refined to avoid discrepancies.

[Video 1: 16:29-18:18] Animation Playback Speeding Up at Greater Distances: This is a known issue wherein animations appear to “speed up” the further away you cam from the object / avatar being animated (the same thing also happens when avatars are impostered). This isn’t an Animesh issue, but a product of how animation updates are handled and his been known about for some time (and was subject to some investigations and tweaking with things like the Interest list several years ago), and is particularly noticeable with large numbers of avatars dancing.

A non-public JIRA has been specifically filed against the problem for Animesh, as it is felt the problem could be far more visible in regions where Animesh creatures, etc., are used. Vir’s hope is that the Lab can re-examine the issue with a view to reducing the issue’s visibility.

[Video 1: 19:22-19:40] Viewer crashing on unchecking the Animated Mesh option: this is a known issue, but one not seen as occurring frequently enough to be considered a blocker to issuing the test viewer. It is being looked at.

Other Points of Animesh Discussions

  • [Video 1: 13:17-15:11Animesh: Purpose Built, or Just Conversion? Should Animesh just be a case of being able to convert any rezzable rigged mesh to Animesh (as is the case) or should mesh intended to be Animesh be specifically designed with that end use in mind. In the case of the former, conversion lowers the barrier to entry with Animesh, but might lead to inefficient models being converted, possibly leading to performance issues. The latter is likely to be used by some content creators wishing to optimise their content for Second Life, but potentially limits the scope of Animesh.
  • [Video 1: 15:12-16:23] “Unrigging Meshes” on conversion to Animesh: It is noted that converting a rigged mesh to Animesh and not animating it causes the rigging applied to the mesh to be ignored, effectively “converting” it to an unrigged mesh. So modifiable items brought from a creator which are not supplied with an unrigged version might, be “converted” in this way.
  • [Video 1: 20:19-21:43] Mesh attach / detach limitations: By default, we generally attach / detach objects directly from inventory; also by default, mesh attachments cannot be dropped in-world. However, this means that the only way to currently “pick up” and “put down” an Animesh pet which can roam in-world / be held, is via inventory, which doesn’t make a lot of visual sense. Vir agrees this should probably be looked at and amended, if possible.
  • [Video 1: 22:30-23:12 and 23:40-25:20] 90-degree rotation of visual mesh versus bounding box / physics: The question was asked if this is a side effect of the +x alignment (see my previous CCUG update for a discussion on avatar alignment). In short, yes, but there is a lot going on in defining, rigging, attachment mesh, it’s not clear precisely what is going on, and further investigations are required.
  • [Video 2: 0:00-0:30] Attaching a prim object to an Animesh object causes the prim to become invisible: (partially messing from the videos): the reason this happens is unclear, but it is regarded as a bug.
  • [Video 2: 0:48-2:15] Is there a script function for attaching a mesh to an existing Animesh object: yes, but is permissions based.
  • [Video 2: 3:05-7:45] Facial animation / pathfinding issue? Medhue Simoni reports that adding pathfinding to an Animesh object which does not have facial animations running can make the object’s face “explode”.  This requires further investigation to pin down – but might indicate Animesh may need a “reset” option similar to the Reset Skeleton option for avatars (also covering alignment / bound box issues).
  • [Video 2: 7:58-9:45] Animesh and avatar shapes: as noted in the project summary above, Animesh currently does not recognise avatar shapes (but this may be added in a future iteration of the project, once baking service support, etc., is available. This means all joint in a skeleton are in their default position unless affected by a script / animation & there is no ability for shape editing.
  • [Video 2: 10:29-13:44 and 15:08-16:00] Sitting on Animesh objects & pathfinding: sitting an avatar on an Animesh object should be possible, but if the mPelvis bone of the Animesh is moving, this may result in odd avatar movements, as noted in past Animesh updates. For an Animesh creature using Pathfinding, a sit target will likely need to be explicitly scripted.
  • [Video 2: 14:04-14:29] Interacting with Animesh by clicking on it: there is a known issue still being looked at, where right-clicking on an animated Animesh works, left-clicking doesn’t.
  • [Video 2: 16:16-20:00] Using a prim as the root of an Animesh object: Animesh currently requires the root object in the linkset is rigged mesh (and – as noted above, re: attaching prims to an Animesh item) is not very happy if any other parts of the linkset are not rigged mesh. A request has been made to allow the root of Animesh items to be a prim, in order to ease problems of orientation / bounding box scaling.Vir’s view on this is that work still needs to be done to ensure a better placement and orientation of the skeleton in order to better overcome issues of orientation, etc.
  • [Video 2: 16:46-17:40 and 22:50-23:20] Handling joint conflicts: conflicts with multiples meshes in an Animesh attempting to manipulate a joint at the same time are essentially handled the same way as for avatars where multiple attachments may try to manipulate the same joint: an arbitrary decision on which position is used is made by the system based on asset UUID.
  • [Video 2 20:24- 21:40] Why is there an alignment issue? The core issue with orientation is that, until now, attachments have been based on the avatar skeleton already being in-world, which causes an attachment to be correctly positioned and oriented to it. With Animesh, the opposite is true, it is the object that is already in-world, and the skeleton is then being associated with it. Wherever the skeleton goes and faces will become the visual location / orientation for the object, and its finding a way to most accurately position the skeleton with respect to the object that is the problem.
  • [Video 2: 24:40-25:13] Do linked Animesh objects each have a skeleton? No. Animesh linksets only use a single skeleton. So link three Animesh items together, and they’ll have a single skeleton.

Animesh In-World Groups

Two unofficial in-world groups for Animesh have been created:

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

Current Status

[Video 2: 25:47-26:38] Rider has converted the day settings in the new format and is about to start working on making environment setting into inventory objects. Once he’s completed this work, his focus will be on producing a project viewer for people to use in testing the available EEP capabilities. This will be “soon”, but may not include the scripted elements of the project.

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. This may lead to a reduction in the complexity of mesh avatar bodies and heads.

Current Progress

[Video 2: 27:57-28:32] An updated baking service server is going to be set-up on one of the Lab’s internal development grids for load testing.

[Video 2:  28:44-29:33] People are looking towards the bakes on mesh project; Vir re-stated that it is a major project in total, and currently the only aspect being tackled is getting the baking service to comfortably support 1024×0124 textures. Where the rest of the work required to support baking on to mesh bodies and items, etc., lies on the Second Life development roadmap and time frames is still TBD.

Content Creation User Group Meetings Moving to Aditi

[Video 1: 6:44-7:33] To assist with Animesh discussions and testing (the latter of which is currently only be possible on the Aditi, also known as the beta grid or preview grid), CCUG meeting will, for the foreseeable future, be moving to that grid and the Animesh 4 region on Aiditi. Details of the meeting location will be made through the CCUG wiki page.

However, if you have not previously logged-in to Aditi, you will need to file a support ticket to request access, and do so at least 24 hours in advance of the meeting. For further information on Aditi, including how to log-in, please refer to the Aditi wiki page.





Storytelling in Sansar

Sansar: Through the Waterfall – Jasmine

As a new – and still developing / evolving platform – Sansar is currently perhaps more a place for experimentation for many, rather than a place to inhabit or use productively (which is not to say it cannot fulfil use cases, as I hope my article on the recent Voyages Live: Egypt tour shows). Because the platform can be seen in this way, I’m constantly looking out for experiences that push Sansar’s current capabilities just that little bit harder – and Linden Lab has been encouraging experience creators to do just this, initially through their Creator Challenge, which took place a few months back (see here for more), together with the Halloween-themed Sansar’s Scariest contest, which closed its doors to entrants in mid-October 2017.

Creator Jasmine has used both competitions as a means of experimenting with Sansar’s potential as a storytelling platform. For the Creator Challenge, she produced Through the Waterfall: Enter Another World, which actually took the prize for Best Narrative Experience. This is the not-entirely-happy story of what happens to two young girls in the aftermath of a tragic car accident.

Sansar: Through the Waterfall – Jasmine

The story starts atop a giant desk on which visitors are informed, Without dreams, we can never become more than that which we already are… , together with an invitation to jump down to the floor and find the first of a series of keys.  Each key, when walked upon, teleports the visitor to a chapter in the unfolding story. It’s a fairly linear piece,  requiring the visitor to “fill in” the blanks of the storyline, so to speak, but the crafting and use of media and music help move things forward through the six chapters. I’m not going to say more here so as not to spoil anyone’s visit.

Miner Difficulties is a further narrative-based experience, with the story developed by Jasmine, and scripting / choreography by Galen (the two of them working under the title of Through the Waterfall). The similarities between this story and that of Through the Waterfall: Enter Another World are fairly clear: both start in similar surroundings, both involve the visitor in an unfolding narrative (an introduction and three chapters for Miner Difficulties, rather than the intro and six chapters of Enter Another World). However, it is the differences in the way the story is managed with that sets Miner Difficulties apart from Jasmine’s earlier work and helps mark how Sansar’s capabilities are gradually unfolding and lending themselves to more sophisticated use.

Sansar: Miner Difficulties – Jasmine and Galen

Whereas Enter Another World relied upon the discovery of keys and narrative deductions on the part of the visitor to link the six chapters of the story, Miner Difficulties uses two “living” guides to steer visitors through the story and piece together events. These are a little bird and a little girl.

Again, I don’t want to spoil a visit, so I’m not going to say much on what to expect. Suffice it to say that the bird acts as a guide through the woods, leading visitors to the little the girl (and then continues onwards with you as you travel with her). The girl also acts as a guide  – but as well as leading you onwards, she also talks to you as she does so, giving a natural structure to the narrative. Both bird and girl are beautifully choreographed and give a great sense of depth to the experience.

Sansar: Miner Difficulties – Jasmine and Galen

To those used to the complexities and capabilities of Second Life, these experiences may seem a little simplistic. However, they do demonstrate the potential for Sansar to become a platform for storytelling – and with the growing capabilities for both VR and Desktop mode interactions, it will be interesting to see how narrative-based experiences develop.

In terms of Halloween / ghostly experiences, I found Miner Difficulties one of the more involved in Sansar, and deserving of its status as a featured experience.

Experience URLs

Floating in Second Life


Floating is an accident, pure and simple. It was never intended to be a collaboration between Bryn Oh and Cica Ghost – but that is what it is. Which is not to say that it is anything unfortunate – far from it; it’s an installation that mixes fun with something of a slight social message.

As Bryn explains, the installation was originally intended to be her design, but built to display the 2D art of another person. But for some reason (shyness?), having secured a grant to use the region, the other artist did not follow through on their commitment and no 2D art was supplied – leaving Bryn holding the lease on a region and in need of an idea. Enter Cica Ghost. She and Bryn put their heads together and in a week, Floating had emerged, with the assistance of Desdemona Enfield and Serenity Mercier.


The core of the build is a city hugging a shoreline; at one end are high-rise apartments overlooking a marina with motor cruisers and boats. The people in the apartments are clearly wealthy or well-off; through the windows of one we can see a family sitting down for a sumptuous meal, a butler in attendance, in another, a family sits in coloured warmth. With the marina and the high-rise buildings, the evidence of wealth, it is hard not to be put in mind of somewhere like Monaco.

At the other end of the curving shoreline it is a different story. Here there are no glittering high-rises, only older buildings, grubbier in appearance, which in turn give way to humble, racked living pods. The beach here is also far from the pristine marina, with piles of detritus, while the absence of colour underlines the lack of affluence. Thus, a comment on the divide between those who have, and those who have less (and who serve?), is made.


However, this isn’t just a build with a message on society’s disparities; there is also a sense of fun yo be found. At the arrival point, visitors can take an umbrella and float around the build, while free-floating balloons also offer a means to float through the air. But be warned – care needs to be taken as there are blocks that periodically fall from the sky.

Also to be found at the landing point is a zap gun. This can be purchased for L$0, and allows people to hunt and shoot one another. Just make sure you join the experience in the region if you intend to place – otherwise, should you be shot by someone else, you’ll be teleported home, rather than just back to the landing point.


Floating is a curious, electric mix of art, message and fun (if visiting with others and the guns are being used). Instructions on obtaining the zap gun and on getting around can be found at the landing point.

SLurl Details

Floating (LEA 13, rated: Moderate)

Animesh project viewer arrives in Second Life

On Wednesday, October 18th, Linden Lab announced the release of their much-anticipated Animesh project viewer had been made available, marking the start of public testing for the Animesh project.

For those who have not been following my Content Creation User Group meeting updates, “Animesh” is an amalgam of “ANImated MESH”. The overall goal of the 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, trees with animated branches, etc.

In short, an Animesh object:

  • Can be any rigged / skinned mesh which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects.
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Uses three new LSL methods to run or stop animations, or check which animations are currently running:
Animesh allows you to take rigged mesh objects, add animations and controlling scripts to them, associate them with an avatar skeleton, and have them run in-world without the need for any supervising viewer / client

The Animesh project has been in development for the last several months, and has involved ongoing discussions and input from content creators at the Content Creation User Group meetings, which are held in-world at the Hippotropolis Camp Fire Circle most Thursdays at 13:00 SLT. As such, the arrival of the project viewer does not mark any kind of official release of the project. Rather, and as noted, it marks the commencement of public testing for what will hopefully become the first release of Animesh functionality.

Currently, testing can only take place on Aditi, the beta grid, where five regions are available with Animesh support enabled. These are: Animesh1, Animesh2, Animesh3, Animesh4, all rated Moderate, and Animesh Adult. Again, please note that Animesh functionality in the project viewer will not work on the Main grid at this time.

Animesh objects are created in-world, not uploaded as such. They must contain the animation(s) they are to run and a controlling script (l), and are enabled via Animated Mesh object in the Build Floater’s Features tab (centre). Note that if you select an unrigged / non-mesh object (or a No modify rigged object), the option will be greyed out and unavailable (right)

An Animesh User Guide is available to help people get started with Animesh, and a forum thread has been set-up for feedback and discussion, while specific bugs or feature request suggestions for the project should be reported via the Second Life JIRA.

Test content is also available to help people get started, if they don’t have suitable content of their own they wish to convert to Animesh objects. The test content can be found here.

In addition, those who test the viewer and Animesh are invited to attend the Content Creation User Group meetings and join discussion on Animesh (and other content related projects), and  / or are welcome to follow my Content Creation User Group meeting updates.

One of the aims in testing Animesh will be to see how many Animesh objects a region and the viewer can comfortably handle without impacting the performance of either

Eventually, Animesh will hopefully support fully fledged non-player character (NPC) creations which can, if required have things like an avatar shape associated with them, use a dedicated, avatar-like inventory, and utilise both the server-side locomotion graph for walking, sitting, etc., and the avatar baking service. However, these capabilities do not form part of the current Animesh project, but will be added as a future project, once other elements which can also help better support NPCs have been put in place (such as an update to the baking service, which forms another project within the Lab).

Related Links