Category: SL Tech

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.