The following notes are taken from the Content Creation User Group meeting, held on Thursday, September 14th, 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 is embedded at the end of this article. However, due to power issues at his end, the first few minutes are missing from the recording. Time stamps to that recording are included below, and clicking on any of them will launch the 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, time stamps may appear to be out of sequence in relation to the recording.
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.
- Animated objects can be any rigged / skinned mesh which is correctly flagged as an animated object (so it has a skeleton associated with it), and contains the necessary animations and controlling scripts in its own inventory (Contents tab of the Build floater) required for it to animate itself.
- The capability will most likely include a new flag added to an existing rigged object type in order for the object to be given its own skeleton.
- At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life.
- Animated objects will not (initially):
- Have an avatar shape associated with them
- Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
- Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
- Use the avatar baking service
- The project may be extended in the future.
- It will involve both back-end and viewer-side changes, likely to encompass new LSL commands to trigger and stop animations (held in the object’s contents).
Project Viewer
[pre-video start and 46:06-46:40] Work on the viewer is focused on cleaning up how the viewer handles animation when dealing with Animesh objects, as there are some elements which simply aren’t used. The transform matrix has been adjusted, so that Animesh attachments now look as if they are attached to the avatar, rather than potentially floating somewhere reasonably close to it (so an Animesh object attached to a hand will now appear attached to the hand and move with the hand, for example). Further work is required, but things are now behaving a lot better; there’s still no ETA on the appearance of the project viewer, however.
Animesh Constraints
Some basic constraints on attaching Animesh objects to an avatar or in-world, and on the overall allowable complexity of Animesh objects have yet to be defined and incorporated into the viewer. These are necessary to prevent Animesh objects negatively impacting performance to an undue degree. The initial constraints set within the project viewer will be subject to refinement in testing.
[32:21-33:06] In terms of avatar attachments, there is already a server-side limit on how many attachments can currently be worn by an avatar (38), so the Lab could look at the type of attachments being used, and limit Animesh in terms of an allowed number within this global attachment limit (e.g. 2 out of the 38 global limit for attachments may be Animesh).
Load Testing
Alexa provided a couple of GIFs demonstrating Animesh. The first showed her army of dancing bears – around 100 – all happily dancing on a region without causing an appreciable load.
[13:39-16:54] However, whether populated regions (in terms of avatars and objects) could handle such a load is open to question. Also, these bears are all the same optimised mesh, and are probably not placing the kind of load on the simulator and viewer as would be in the case of multiple and different kinds of mesh with varying levels of complexity. To help determine reasonable limits, the Lab will be establishing some test regions once the projects viewer is available, to allow for more comprehensive testing with assorted Animesh models, and which will used to further refine the Animesh constraints noted above.
[18:11-18:40] As a part of her own testing, Alex also intends to use the mesh starter avatars produced by the Lab, mixing them together in a scene using different animations, etc., to see how things behave.
Animesh and Pathfinding
[10:35-11:14] A couple of previous meetings have raised the idea of Animesh working with Pathfinding (the means by which scripted objects – people, animals, monsters, etc,– be set to move in a region / parcel and react to avatars, etc). Dan Linden is looking into how Animesh and Pathfinding might work together, and he and Alexa shared a GIF image of some of the work, with some of Alexa’s dancing bears skating around their own pathfinding routes, which provide a quick demonstration that the two can likely be used together.
Alexa has also been experimenting with Animesh and ice-skating, taking the view that having creatures and animals ice-skating in winter scenes (which can actually be common in “wintered” regions, with skating penguins and the like).
Animesh Attachments: Fluidity and Clothing
How smoothly attached Animesh objects work is liable to be dependent upon the animations themselves, and whether or not they move the object’s pelvis bone or nor. As with all things, some experimentation and fine tuning is likely to be required be creators in order to optimise the motions of their Animesh attachments.
Some people have been looking at Animesh as a means to get clothing to move more naturally with an avatar. However, as Vir pointed out in the meeting, utilising additional skeletons in clothes may not be the most efficient way to achieve this, when it should be possible – with a little care – to use existing some of the bones in the avatar skeleton to achieve the same results (e.g. skinning the cloth of a gown or skirt or cape to the wing bones, etc).
This would allow the clothing to move far more seamlessly and in sync with body movements than could be achieved with Animesh attachments, which would not have any direct means of syncing with an avatar’s movement.
Root Positioning
[1:39-3:03] Vir is has been working on aligning the root joint of a skeleton associated with a Animesh to the position of the object in-world. Sometimes this gives good results, sometimes it doesn’t, resulting in objects jumping around when animations is played or moving into the air or sinking into the ground, etc, as the server thinks they are somewhere else than the visual position shown in the viewer. Because of the mixed results, he’s considering alternative approaches, such as using the object’s bounding box, and will be exploring options before pushing out any project viewer. One of the balances he’s trying to achieve is presenting a nice visual result without over-complicating what has to be done in order to achieve that result.
Changing the Orientation of the Skeleton via LSL / LSL Commands
[34:12-34:45] Will there be a scripted function to change the default orientation of a skeleton to match an Animesh object? Conceivably; however, Vir is hoping to develop a reasonable default behaviour when attaching a skeleton which will allow simple editing of the object to achieve the desired result, if required. Should this be shown not to work sufficiently well enough, additional LSL support will likely be looked at.
[4:54] A question was asked about the list animations command (LlGetObjectAnimationNames). This is one of three new LSL commands being introduced to support Animesh – please refer to my week #35 CCUG update for details on these.
Inverse Kinematics
[1:10-1:20] A request was put forward for work to be done in extending / improving inverse kinematics in SL, particularly with regards to Animesh and as a whole. This won’t be something that will be tackled before the project viewer appears (if it is worked on at all).
Feature Requests BUG-100864 and BUG-134018
[23:47-24:23] These two requests, for rigging sitters to Animesh bones and for providing a means for Animesh to support non-rigged legacy content are seen as most likely out-of-scope for the current Animesh work, but may be considered as part of a follow-on project.
Vehicles: Scripted Moving Parts or Animesh Moving Parts?
[29:32-30:41] Vehicles can have a lot of moving parts, driven by scripts. Would Animesh (which requires a scripted trigger) be more efficient in handling those parts? Short answer: depends on the vehicle and the type of behaviour involved. Complex motions often depend on alpha swapping, which is highly inefficient, so Animesh could be of benefit.
Animesh Documentation and Forum
[21:27-22:16] Documentation for Animesh, with links to sample content will be appearing on the SL wiki in due course. Information on the project viewer, when available, will be available from the Alternate Viewers page.
[26:03-26:29] The Lab is considering an Animesh forum thread (similar to the one created for Bento), where people will be able to discuss Animesh and ideas related to it, once the project viewer is available.
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 Status
[0.23-1:04] Work is still focused on deploying the support for 1024×1024 textures to the baking service. This is now at the stage of QA work to determine that it is working correctly and to better understand the overall impact on the baking service in handling 1024×1024 texture bakes, and whether or not additional baking servers will be required.
[27:51-28:47] There is no ETA on a project viewer for bakes on mesh. As well as the focus currently being on ensuring the back-end baking service will be able to support the capability, the viewer-side work will need to be slotted into the current viewer priorities list, which hasn’t, as yet, been done.
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.
[30:49-32:07] As noted in my week #37/1 update, Rider has recently been pulled away from the EEP work. A project viewer is nearing readiness, as are the environment assets. However, the scripted elements of the work are further down the road, and the appearance of the environment assets and the viewer may be subject to some required infrastructure changes.
Other Items
Increasing the Build Size Limit
[3:14-4:08] There have been requests to increase the build size limit for objects, more recently with specific regards to Animesh (to allow very large creatures, for example). Currently, there are no planes to do this, although if use-cases emerge during testing of the project viewer, it may be something that gets considered, although again, it would depend on how easy it might be to implement.
Imposter Cropping and Imposter Updates
[4:12-4:22] There is a bug where imposters can appear cropped when rendered. This is something Vir is aware of, but hasn’t had time to look at.
[17:12-17:40] Imposters and how they are handled with Animesh is something which may require updating. This is unlikely to be done before the Animesh project viewer is released, but it is something that will be looked at before Animesh goes to release status.
Inventory UI Redesign Request
[6:04-10:08] A request was made to “upgrade” the Inventory UI floater to be more Windows Explorer like in form as a part of the Animesh project viewer release. The request seemed to be made under the belief that the Animesh viewer would be a “new” viewer, rather than a release of the current viewer with enhancements to support Animesh.
While similar request have been made in the past, such work would only be undertaken as a project in its own right, as such, it would fall outside of the Animesh project. Also, before the work is considered, it would need to be formally put forward to the Lab in the form of a JIRA feature request / project proposal, defining the requirements, goals, and benefits.
Mesh Uploader – Supporting Multiple UV Maps
[38:38-45:25] A question was asked via chat about supporting the upload of multiple UVs for mesh objects (e.g. for lightmaps, to provide a better means of providing global illumination in a build without relaying on multiple textures, etc. The question was somewhat misunderstood in context when being repeated. However, such a capability would require an overhaul of the uploader, and raises questions on compositing and may require alterations to the graphics pipeline. As such – and subject to a formal feature request – this would sit in the bucket of things the Lab might be interested in considering in the future.
Additional Content Creation Meetings
[26:44-27:24] Concerns have been expressed over Animesh dominating the CCUG, with some requesting separate Animesh meetings to allow more time for other topics to be discussed at the CCUG. There are unlikely to be additional meeting created, with Vir noting that while Animesh is a hot topic, the CCUG does allow other topics to be raised, and will doubtless evolve to cover other projects and hot topics over time.
Raising a Bug Report
For those who have not raised a bug report / feature request on the JIRA, guidelines for doing so can be found here.
Inara Pey: Living in a Modemworld 