Category: SL User Group Meetings

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.

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, September 21st, 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. 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, 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).

Current Progress – Animesh Constraints

“It’s not [been] the most exciting week,” Vir commented about his most recent focus on the project. “What’ I’ve been working on lately is complexity limits and other constraints.”

[2:48-4:19]As noted in previous CCUG meeting notes, some constraints on Animesh are required to prevent undue impact at either the simulator or viewer end of the system. These constraints will be in addition to any already in place in SL (e,g, Land Impact, overall limit of the number of attachments an avatar can wear, etc), and include:

• Limiting the overall complexity of an Animesh object
• Limiting how many Animesh items an avatar can have attached at any one time (currently set to one in the upcoming project viewer for testing purposes)
• Limiting the number of triangles an Animesh object (attached or in-world) can contain, possibly to around 20K initially. Interestingly, some limits in Sansar are defined in terms of tri / poly limits.

With complexity and number of tris, the limits have yet to be fully defined, and Vir welcomed any well-made mash models could serve as Animesh examples in order to try to help baseline the initial limits.

[4:45-5:10 and 8:55-9:49] Currently, there are no new limits for the scale (or size) or an Animesh object beyond the existing constraint re objects and avatar skeletons already in place. Some feel that additional constraints / viewer limits may be required in order to handle “titan” Animesh creatures (e.g. creatures of 64m in height, which may also require bounding box adjustments). Vir is prepared to look at this, but would like to see how things go with testing via the project viewer.

[5:22-5:41 and 6:18-6:47 and 10:41-11:06] The triangle limit will apply to all Animesh objects regardless of whether they are in-world or attached, and will be applied at the time the objects are flagged as Animesh. So if someone tries to link together a set of existing rigged mesh items and flag them as Animesh (or which contain an Animesh item) which exceed the limit, the flag Animesh flag will not be set. This should leave existing content unaffected and avoid content breakage.

[12:14-13:17] Some see the proposed 20K limit is two low and suggest 30K or even 50K, to allow for clothing, accessories, etc., to Animesh characters. The counterpoint to this is to set a limit which encourages optimisation, and to have people consider impact on the simulator / on others.

[14:24-15:32] A request for the viewer to provide meaningful feedback when Animesh limits are reached, preferably with a pointer back to some wiki information. Limits won’t actually be reached on mesh upload, but when objects are flagged for use as Animesh post-upload, so would require some form of viewer notification.

[15:34-16:20] Requests have been made to obtain poly counts of objects via LSL to help track things or even in the viewer UI. Vir currently uses his own diagnostic display to help indicate such things, but currently, no such updates, LSL or UI are planned, although the debug ShowRenderInfo could display the required information if more directly exposed and Vir will file a JIRA on this, although it might fall outside the current scope of work.

[22:11-22:35] It was also pointed out that tri / poly counts are variable based on LOD. Vir is currently focused on the tri count of the highest LOD for an object

[13:18-13:44] Vir’s approach to all of the constraints / limits being discussed at this time is to start as tight as possible, and then make adjustments and loosen things as testing with the project viewer begins / offers reliable feedback and data. It is easier to relax constraints and allow people greater creative freedom, than to start with a loose set of limits and then have to tighten them (potentially breaking test content, and adding to people’s overhead in having to rebuild it).

Time Frame for Animesh

[19:29-20:00] The constraints mentioned above and trying to fix the transform matrix when handling Animesh attachments. There are also a couple of bugs he feels need fixing before the project viewer appears. However, the hope is now that the viewer will be appearing sooner rather than later.

[48:52-49:28] There are a couple of irritants in the viewer Vir wants to fix before releasing a project viewer for Animesh testing. Ther are some corner cases where the viewer can be awkward, but these are not considered blockers to a project viewer appearing, and can be cleared-up in due course.

Performance Hits

[27:45-28:42] There are still concerns as to the performance hits on things like real-time shadow casting with Animesh skeletons following avatars (pets, etc.) or in being attached to avatars (and vice-versa). Vir isn’t too concerned by this at the moment, as the code is already handling much of what will be required with Animesh: every time an avatar sits on something, it is effectively updating every frame, so with Animesh this will be much the same. However, as with everything else, this will be subject to testing.

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

[31:28-32:00] The updates to the service to manage 1024×1024 textures and compositing is with LL’s QA team, who ar testing to ensure the system can handle the compositing correctly, and the back servers won’t fall under when loaded with handling 1024×1024 textures in bulk. Progress with the rest of the project is dependent on this.

[36:25-36:59] The rest of the work will focus on applying the baked textures (which will include alphas, just as is the case with the system avatar now, but will not include materials) to mesh avatar models.

[39:09-40:55] A possible follow-on to the current work on bakes on mesh is to extend the capability to include Animesh objects as well, although this will require Animesh objects to have a notion of a body shape. It might even be possible to push the system into other uses.

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.

Current Status

[30:32-31:12] Rider has been working on getting his settings objects – environment assets – correctly passing into Windlight. Once he has this working smoothly, he’ll feel a little more comfortable in talking potential time lines on when things like a project viewer are likely to appear. However, he did point out that everything is currently in “Goth compatibility” – black environment settings against a black sky!

Other Items

Mesh Uploader

[49:38] A discussion on whether creators will in future be forced to upload only manually created LOD for their models, rather than auto-generating them. Short answer: No, but people are encouraged to optimise LODs where manually or automatically generated. The uploader also has numerous constraints on upload, not all of which are well documented or which provide adequate / any feedback when they occur. It’s acknowledged that such situations could be handled better.  However, issues of tracking the number of bones a mesh is rigged to can be tracked through Avastar and MayaStar prior to upload.