The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, April 19th, 2018 at 13:00 SLT. 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 streamed the meeting, and his video is embedded at the end of this summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details.
Initially, the meeting opened on Aditi at the Animesh test regions.however, Voice issues across the beta grid regions resulted in the meeting decamping to the TPVD amphitheatre on Agni, and these notes reflect the meeting from that point onwards, starting at the 7 minutes 19 seconds point in the video.
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.
The project viewer with the updated Animesh land impact / tri count formula was released on Monday, April 16th. Version 184.108.40.2064468 also brings the viewer to parity with the current release viewer.
Vir’s provides a detailed explanation in the Animesh updated limits and cost formulas forum thread, However, in summary:
- Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
- Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
- Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
- High LOD: all of the estimated triangle count included in the effective_tri_count.
- Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.
- These values are also reflected in ARC (avatar rendering cost) calculations for Animesh items.
[7:23-8:43] The viewer also incorporates a change where it will automatically switch to skeleton based rendering for Animesh as soon as it detects the use of an avatar skeleton in an object, rather than waiting until an animation starts playing on an Animesh object in order to make the switch. It is hoped this will avoid issues between an Animesh object’s static and animated states, which can cause visual glitches when the animation based switch is made. It should also avoid potential exploits with people using multiple Animesh objects without necessarily animating them.
[9:13-9:32] It is believed the majority of bugs for Animesh are now in hand, however if any finds specific issues with the new impact calculations or with the latest project viewer in general, they are asked to file a JIRA bug report.
Rigged Mesh Level of Detail / Bounding Box Issues
Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems
For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).
[8:44-9:12] Graham Linden has been investigating these, as has some proposed changes which he and Vir hope to implement in the near future, the implication being these will be folded into the Animesh viewer.
Environment Enhancement Project (EEP)
A set of environmental enhancements, including:
- The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
- New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
- Experience-based environment functions
- An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
This work involves simulator and viewer changes, and includes some infrastructure updates.
[10:35-11:05] Rider Linden has been involved in dealing with other issues, which have delayed progress on EEP. He hopes that with this worked cleared, he’ll be able to focus on getting the viewer updates out in a project viewer.
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, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.
This work does not include normal or specular map support, as these are not part of the existing baking service.
New Bake Service Slots
[11:30-12:25] Anchor Linden is working on adding three new texture slots to the Bake Service, these being skirt tattoo, hair tattoo and eyes tattoo. These updates should hopefully be incorporated in the next viewer update. The idea is to allow tattoos for any component of the system avatar and have them reflected on mesh faces, making the Bake Service more flexible for use with mesh.
Bakes on Mesh and the Applier Market
[12:38-24:32] There have been a number of requests for API to be provided in support of Bakes on Mesh. Mostly, these are considered by the Lab as items to be considered as a part of any follow-on project which may arise after the current Bakes on Mesh work.
However, it has been pointed out that providing an API to allow scripted insertion of textures into the bake stack so that people don’t have to use the system layers could offer a four-fold benefit for creators in the applier market:
- It offers back compatibility for a huge range of existing applier based skin and clothing options (many of which have specific adjustments to match the UVs of the body to which they are being applied, which cannot be mirrored using the generic SL avatar UV)
- It offers a continued ease of use to consumers: they don’t necessarily have to pour through folders and folders of layer items to achieve a look.Or even learn what system layers actually are, given many may never have had cause to use system wearables due to the preponderance or mesh applier systems and the widespread use of mesh bodies, etc.
- It potentially allows broader use of the Bake Service to achieve effects offer far greater us of the Bake Service to achieve additional effects.
- It could serve to speed the adoption of Bakes on Mesh over continued use of applier systems.
A feature request covering some of these ideas has previously been raised (BUG-214631). However, Vir and Alexa Linden has requested a specific Feature Request on this one issue is raised and filed so that the Lab can consider it in more detail.
[24:33-30:56] The two-step approach to SL projects: Vir reiterates that the approach taken with Bakes on Mesh (like the majority of user-facing current projects) is to offer a minimum set of features to launch a new capability, then see how it is used and iterate from there. This means the initial work is simply a means to leverage the Bake Service without necessarily needing to make extensive changes to the service itself – something any provision of APIs would require.
The concern here is that such a two-step approach will not work in this case, because some body / head creators are already looking at Bakes on Mesh as a means to reduce the complexity (“onion layers”) in their products (a stated hoped-for result for Bakes on Mesh).
However, doing so could cause widespread disruption in at least two ways:
- It would result in “breaking” existing applier systems, requiring applier based clothing makers to re-work their entire back catalogue of products and present them to users in a less easy-to-use form (in a reverse of benefits 1 and 2 above).
- It could cause consumers to resist updating their mesh heads and bodies to newer, less complex versions in favour of retaining the ease-of-use presented by their current body versions and existing applier systems.
Even mesh body head creators who may opt to try to offer some form of “transitional period” with two products – a “current” range of bodies / heads that work with applier systems, and an “Bakes on Mesh” version – are faced with uncertainty as the two-step approach doesn’t really offer any clarity as to future direction and time frames for enhancing Bakes on Mesh.
[44:30-50:30] The two-step approach to releasing Bakes on Mesh is returned to, and Vir takes a straw man poll on whether Bakes on Mesh should go this route, or go more like Bento, with a longer gestation period (Bento was around 18 months) to allow a more rounded feature set to be supplied. The majority of the feedback indicated people would rather it have a longer gestation period and be released later, possibly with a more rounded feature set, possibly with the script API support. Obviously, as a straw poll, the feedback doesn’t mean the project time frame will be re-evaluated, but it did offer useful feedback for the Lab.
[31:00-35:50] Ensuring persistence: Vir points out that a major problem in supplying any form of API for texture insertion into the Bake Service is that of persistence.Currently, the Bake Service retains no information relating to system layers (which items are worn, the order in which they are worn, etc.), once the current combination has been replaced / changed (or beyond the current log-in session; the information is held solely within the avatar inventory, and recalled at log-in.
Applier systems, however, send the UUID for a texture to be applied directly to the corresponding mesh (“onion”) layer of the body / head that is to wear it. Thus, if these textures are to be arbitrarily injected into the bake stack by means of a script, the issue is where should the information relating to these textures (what they are, where they sits in the stack of wearable layers, etc.) actually stored? The Bake Service has no means of either storing it, or directly sending the information to the mesh layer where it can be stored.
Bakes on Mesh: Mesh Conflicts and Resolution
[36:39-44:30] Even with the additional Bake Service slots Anchor linden is implementing (above), mesh bodies are broken up into more parts than can be supported by the Bake Service slots (they have separate hands, feet and hair, two arms (as opposed to on arm being mirrored as part of the Bake Service upper body slot). This can potentially lead to conflicts in where and how system layers are applied.
Cathy Foil has proposed the introduction of new Bake Service slot / wearable: BAKE_AUX, which could be used to apply additional wearables to a mesh face using that slot / channel – with the added flexibility that each face assigned to BAKE_AUX could utilise a different wearable. The would require changes to both the Bake Service and the viewer Appearance Editor (to offer a tattoo layer input field where the textures for the BAKE_AUX wearable (see BUG-216084 for more).
The Lab’s concern is that providing BAKE_AUX presents a “blank cheque” for abuse. As up to 60 wearables can be worn at a time, it might allow someone to present the Baking Service with an additional 60 tattoo layers which have to be composited, on top of the six existing bake slots, significantly impacting Bake performance. However, there are potential benefits to this approach as Cathy notes in the JIRA. It is also one of two ideas for additional slots that has been proposed, and is potentially the more flexible, as such the Lab has accepted the JIRA to give it further consideration.