The following notes are taken from the Content Creation User Group meeting, held on Thursday, September 28th, 2017 at 13:00 SLT at the Content Creation User Group wiki page.. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the
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”.
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).
[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.
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.
[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.
[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
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.
[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.
[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.