Category: SL Tech

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, October 12th, 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, with key points of discussion noted below. Time stamps to the 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, 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 object (generally 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.
• Can use many existing animations.

However 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
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Viewer Progress

[1:11-3:40] We are now “very close” to seeing a project viewer, test content and test regions appearing. The viewer has been passed by LL’s QA team, the initial test content is being developed (and will be added to, although people can obviously also test their own content) and a total of five regions will be set-up on Aditi (the beta grid) for the purposes of test very soon. Four of these will be arranged in square and be rated Moderate (allowing for comprehensive content testing, including how Animesh is managed on region crossings), the fifth will be separate and rated Adult.

The main hold-up for now is documentation: release notes, wiki documentation, FAQ, etc. When all is ready, there will be a blog post on the project, and the viewer itself will be appearing on the Alternate Viewer wiki page – so those interested in testing Animesh should keep their eyes on both the official blogs and the viewer wiki page.

Root Positioning

[4:20-7:20] The most recent work with Animesh has remained focused on aligning the root joint of a skeleton associated with an Animesh to the position of the Animesh object in-world. The problem here is that the skeleton / avatars in SL are oriented along the X-axis; however, some tools (Avastar?) align along the Y-axis.

This means that when applying skeleton (X-axis orientation) with an in-world mesh objects with a Y-axis orientation to make it Animesh, the latter can jump and rotate. Vir had been looking to make changes in the skeleton’s orientation to handle mesh with a Y-axis orientation this. However, it turns out doing so could cause unwanted behavioural changes for scripts handling attachment rotation and positioning. To avoid this, the skeleton orientation will remaining X-axis oriented. Vir hopes that the upcoming testing will allow the settings for linking skeleton to mesh can be further refined to make the conversion from static mesh to Animesh as smooth as possible.

Animesh and Vehicles / Testing vs Release

[9:20-13:20] A view is expressed that Animesh is being “rushed” without sufficient thought being given to its application in vehicle design. This in part perhaps stems from confusion about public testing of Animesh and a release in Animesh. For example, while Bento had an initial “closed” period of develop to lay the ground work, it was followed by a broad and lengthy public period of testing, consultation and enhancement.

As such, the arrival of the project viewer doesn’t mark a move towards “releasing” Animesh – but rather allows more widespread testing of the capability, including its potential use in vehicles and elsewhere. Testing is the point at which the Lab can more fully look to creators for feedback, requests for improvement – and even fleshed-out feature requests  etc., which might be considered for folding-in to the current work or for follow-on work once the initial Animesh release has been made.

Quick Questions

• Land Impact:
  • [15:54-16:29] Overall land impact constraints of Animesh are still TBD (testing will help determine what might be required). However, Vir points out that in terms of individual LI applied to Animesh objects it will initially be focused on a per skeleton basis, not on a per mesh basis (so a linkset of several rigged meshes converted to Animesh will be seen as single object with an LI, not a group of mesh objects, each with an LI).
  • [37:35-38:34] Couldn’t the Animesh constraint be purely land impact based? possibly, but then attachments would be excluded – as they are with avatars, and the most costly element in terms of performance are avatars; by only using LI as a constraint, then Animesh could become as impactful as avatars with multiple high render cost attachments.
• [16:46-17:18] Is Animesh prim objects with an AO? No. Animesh is rigged mesh objects containing scripted animations within them, associated with an avatar skeleton.
• [17:22-17:57] If an Animesh has linked skeletons, do animations play across all of them? No – Animesh does not involve linking skeletons. It can comprise multiple rigged mesh objects which are linked to an individual skeleton, which can have animations applied to it.
• [18:09-18:30] will the attached mesh also count against the tri count? Yes. There will be a limit, most likely set to 20K when testing starts, but subject to review as testing proceeds.
• [26:02-27:35] Short description of how Animesh will work, as covered in some of the bullet points in the project description, above. Includes some discussion of using Animesh with pathfinding.
• [30:00-30:35] Is animation movement capped (in terms of moving an individual bone): yes, it is capped at 5 metres, as it always has been for avatars.
• [30:41-32:55] Physical properties discussion: Animesh objects will operate like avatars: they well not have physical collisions as a result of animation (e.g. a moving arm on an Animesh will not collide with a passing avatar, for example). However, Animesh objects will have physical properties (based on mesh physics shape), and so can fall, etc.
• [47:35-48:08] Will Animesh alter the land impact for existing objects in-world? No. Animesh is a new object property, only applicable to objects intentionally set as Animesh. As such, it will not affect pre-existing content in-world unless said content is converted to Animesh (if it can be).
• [48:48-49:58] Will Animesh behave at altitude? There  is an issue which sees mesh rigged with software skinning deforms at altitude (starting around 1,000m and getting worse from there). Animesh might suffer the same, but it hasn’t been tested.
• [52:47-56:10] The eyes have it – a discussion on automating eye movements on Animesh in a similar manner to avatars. Vir see this more as building-out the NPC-style capabilities with Animesh, which is very much a follow-up to the current project.
• [58:18-59:20] Can Animesh work with other mesh? It should; the complex part is liable to be keeping the object’s actual position in sync with its rendered position based on the animations playing, particularly as there won’t be a “sit” equivalent. Vir hopes this is something that will be poked at in testing.

Side notes on Animesh Constraints:

[44:08-45:21] As Vir has previously indicated, all of the constraints in the viewer – when it appears – are for testing purposes, and to provide a means by which things can be tested.  For a catch-up on constraints and testing, please refer to my previous CCUG update.

[20:21-20:45] Also, to help with constraints and information, Vir has been updating the viewer’s avatar complexity panel to provide information on triangles, which will also work for Animesh objects.

[22:45-29:08] A feature request has also been submitted for an alternative method of handling land impact and incorporating Animesh – see BUG-139203. This has been left open for comment. However, it is something the Lab is interested in taking a look at.

Continue reading “SL project updates 41/2: Content Creation User Group” →

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, September 28th, 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, with key points of discussion noted below. Time stamps to the 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, 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 object (generally 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.
• Can use many existing animations.

Note that the focus of this project is not currently about providing fully-functional NPCs at this point in time, which is seen as a follow-on project.

Current Progress

[3:32-4:00] We are getting close to seeing a project viewer for Animesh.  Vir is about to submit a build to the Lab’s QA team for testing, which should be done by the time of the next meeting (Thursday, October 12th, 2017). The outcome of the testing will help determine when we might see the project viewer made publicly available.

[4:00-4:37] Most recently, Vir has been working on issues with the transform matrices when handling Animesh attachments. He’s now got these to a point where things can be edited and positioned where they are needed. There may be some further iterations on this work, but it appears to be working well enough for testing now, once the project viewer is available.

Constraints

This discussion on constraints, and triangle limits in particular ran throughout most of the meeting in chat, with a large portion of the meeting from around the 50 minutes to the end of the hour being almost exclusively personal viewpoints chat. I’ve attempted to highlight the key points of the discussion below.

[6:05-7:25] As noted in previous CCUG meeting notes, some constraints on Animesh are required to prevent undue impact at either the simulator or (particularly) viewer end of the system. These constraints will be in addition to any already in place in SL, and include:

• Limiting the overall complexity of an Animesh object
• A land impact surcharge for in-world Animesh objects (currently set to 200LI per region for testing purposes).
• Limiting how many Animesh items an avatar can have attached at any one time (currently set to one for testing purposes).
• Limiting the number of triangles an Animesh object (attached or in-world) can contain, the figure for this the topic of debate.

[8:21-9:08] The initial limits will be documented when the project viewer is released. Vir will be working on this and other related Animesh documentation when the viewer goes to QA for testing.

[12:30-13:30]  The limit will come into play when converting an object (or linkset) to Animesh in-world (note there is no check at upload, as a) the uploader has no way of knowing if a rigged mesh item is specifically Animesh or not without changes; and b) an in-world check allows existing in-world mesh to be used as / with Animesh without the need to re-upload). It will be triggered through the viewer, enforced by the server.

[15:04-15:58, [16:02-18:35] There is doubt is the 20K tri limit is high enough – even Vir is not sure, and may raise it before the project viewer is made available.

[18:39-19:22] Concern was raised about the impact of the servers decompressing mesh objects in order to calculate the number of tris the number of objects in an item in order to check if the Animesh limit is exceeded. Vir explains this isn’t how it’s done. Rather the server has a estimation for the likely tri count based on the size of the data objects which store the triangles – which is essentially the same figure used in the rendering / streaming cost calculations, and gives a close enough estimate to be reliable.

[20:40-28:58] Some would like to see it raised “just for testing”. however, Vir’s concern is that once the project viewer is available, the Aditi test regions are liable to be inundated with Animesh objects, resulting in them being overloaded with no meaningful data collected. The flips side to this is that an initial limit of 35K or 50K would mean that more existing content could be “flipped” to Animesh status, without the need necessarily for creators to have to create models specifically for Animesh testing.

[31:47-32:47] As the tri limit is managed server-side, it may be possible to have different regions set with different limits to offer a variety of testing environments.

[20:01-20:30] Animesh will increase the server load in other ways. Whereas the tri count was only affected by in-world objects, it will now have to account for worn Animesh as well.

[34:54-35:42] The important thing to note with these constraints is that they are preliminary and for the purposes of testing. Depending on the results obtained, some of them might well be relaxed both as testing progresses and prior to Animesh being formally released. As Vir notes, it is potentially much easier – and less upsetting – to start with very tight constraints and then loosen them as data is gathered, rather than start with very broad constraints and then try to restrict them over time. so, the intent is with the testing is to lay the grounds for a more informed discussion on limits – tri counts, LI, and everything else. Nothing, at this point in time or with the arrival of the project viewer in due course, is set in stone.

[47:21-50:23] Could the number of tris in an Animesh be tied to land impact, rather than a basic surcharge regardless? Possibly; again, the 200 LI surcharge is purely for initially region-based testing. This is already how land impact works elsewhere. However, there is always a basic cost associated with an avatar skeleton, so this needed to be factored-in as well, however minimal it might be for a single skeleton.

Test Content

[4:50-5:42] The idea for the Lab to provide more in the way of test content to help those wanting to get started with Animesh has been passed to the Linden Department of Public Works (LPDW) team. They’ve in turn assigned someone to produce some test content which will be made available through the Library (and so will appear in people’s inventory under Library when available).

How Will Animesh Attachments Work?

[9:10-12:10] Essentially the same as any other attachment, using an avatar attachment point. The Animesh item is attached via its root joint, and then can be edited to fit (translation / rotation).  Animesh can also currently be attached to HUD point, but this is liable to be disabled, particularly as it is will require more work to get it to function reliably, and there aren’t any obvious use cases.

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. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Status

[7:40-8:04] The updates to the service to manage 1024×1024 textures and compositing has been in testing with LL’s QA team, and it has been reported that the higher resolution texture capability (the baking service only supports 512×512) has the potential to impact the performance of the bake service, so a load test is being planned.

[14:17-14:37] The first part of the bakes on mesh project will not include any kind of API for injecting layers into the bake stack (e.g. to ensure that layers from the likes of appliers are stacked correctly (e.g. underwear, shirt, top), by the baking service. The might be added in the future.

[29:00-29:40] Essentially, the project currently breaks down into two core activities:

• First stage: just to increase the maximum resolution the baking service can support (1024×1024, as noted above)
• First (and larger) stage: to get the bakes on mesh to help with baking to mesh bodies. This work is “further down the line”.

[38:00-41:10] Once Animesh is released, the plan would be to also extend bakes on mesh to support Animesh objects as a part of the Animesh follow-on project, which would see Animesh objects have a notion of a shape, plus wearables in their object inventory.

Other Items

[14:39-15:03] As a ploy count will be used for Animesh constraints, can llGetObjectDetails() have a parameter to return the count is a scripted enquiry? Possibly, but not as part of the Animesh project.

There is no Content Creation meeting in week #40 (commencing, Monday, October 2nd). As noted above, the next meeting will be Thursday, October 12th, 2017.