Category: SL User Group Meetings

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, April 5th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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. Please note that Vir’s microphone was not behaving during the meeting, causing his voice to drop-out at times, breaking up the context of his conversation (I had the same issue with my audio recording).

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.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Progress

The project viewer is now available – version 5.1.3.513936, which as noted in previous updates, was released on March 30th. This is the first pass of the viewer, and there is much more work to come.

General Notes from the Meeting

[2:55-04:00] Some mesh body creators are already involved in looking at Bakes on Mesh, and the Lab has been gathering names and details of creators, but there has – as of the time of the meeting – been no direct outreach to any of them. Siddean Munro (Slink) is reported to be “thrilled” with the capability, and sees it as a means to dramatically reduce her workflow.

[4:45-5:55] Status of 1024×1024 support: While the first part of the Bakes on Mesh project was to update the Bake Service to support 1024×1024, currently, these back-end changes have not been deployed, so all Bakes on Mesh testing currently use the existing 512×512 textures supplied by the Bake Service. The deployment has been delayed due to other work being carried out on the Baking Service, but it is hoped it will be deployed in the next few weeks.

[13:26-14:22] It terms of 1024² texture support with the baking services is eye textures. Currently 128×128, these will be increased to 256×256, the pixel density on so small a target compensating for the lower resolution.

When  the increased texture resolution support is deployed, the Lab will also be implementing additional servers to support the additional load on the Baking Service.

[6:01-8:49] Wearable/ Texture Map issues: It’s been noted that the eyelashes are tied to the avatar eyeball texture, not the avatar head, which might cause some issues.

The right / left arm being mirrored in the texture map has also been re-noted. This is prompting some creators to consider re-purposing the system skirt or hair wearable (which are now almost never used) to be assigned to one or other of the arms. This would  allow, for example, a tattoo to appear on one arm only, rather than being mirrored on both arms, as is currently the case on system avatars.

[9:52-11:05] In order for this to work, the textures would need to be uploaded as a skirt or system hair. Basically, the system wearables act as containers of the textures, so if you want to apply a texture to a specific body region (as supported by the viewer / Bakes on Mesh), you can assign it to that wearable (e.g. the texture can be applied to the undershirt, shirt or jacket wearable to be applied to the upper body, or to the skin wearable to be applied to the entire body).

Cathy foil also gave feedback on using Bakes on Mesh to apply system eye textures to mesh eyes.

[8:53-9:49] Will the baked texture slots be expanded in to future? (there are currently 6 slots: BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR.) Possibly, but not being considered with Bakes on Mesh at present. Currently, the bake texture slots are tied to the supported wearable textures. Adding more slots  would require defining the underpinning data to be stored in the additional slots (i.e. define additional wearables).

[12:10-12:36] One thing to remember is that if an alpha layer in used to hide your system avatar (or a major part of it), it will be baked as well, and if that bake is applied to a mesh, it can end up masking more of the mesh than intended, due to the extent of the alpha.

[14:42-17:02] Hiding the base avatar: a means to hide the system avatar without having to use an alpha mask has long been a request, raised again during the Bakes on Mesh project. No decision has been made on if this will be done or how. One approach might be to make a further change to the Bake Service so it ignores the base avatar; another might be it use an unassigned texture slot to “hide” the avatar from the Bake Service – this has the advantage of not requiring a change to the Bake Service.

[17:29-25:00] A general discussion on how a more flexible use of Bakes on Mesh might be achieved – such as re-purposing rarely used texture slots, or extending the Bake Service itself.

• Re-purposing texture can be done with care – such as using the skirt or system hair as described above to give individual texture for the arms.
• Further extensions to the Bake Service itself – e.g. additional bake slots beyond the current 6  are unlikely to form a part of this project, but might be considered for any follow-on that comes after it.

The Lab also have some concerns about opening-up the Bake Service further include the potential for performance hits, possible abuse.

[25:09-27:35] Extending the Bake Service to support materials: this is a complex step to take, which may not even be properly defined. Maps (diffuse (texture), normal and specular) all have to be defined by layer and brought together properly in a composite bake in such a way to ensure normal and specular maps from one layer are correctly associated with the diffuse map from that layer, so they aren’t displayed over another layer. As such, materials support will only be considered as a potential element for a follow-on project to the current Bakes on Mesh work. See also BUG-214631 for a proposal on how materials support might work.

[33:37-34:11 and 36:40-37:20] Bakes on Mesh for HUDs / Bakes and Textures: conversation on bakes on mesh and HUDs, expansion on Bakes on Mesh vs. appliers, and texture and Bake UUIDs. In short: Bakes on Mesh can also be applied to HUDs, which could help reduce the number of textures commonly found in them (a single composite rather than multiple textures). Complexity of HUDs might also be reduced, simply because the texture applying elements may no longer be required as textures will come via the Bake Service – although applier HUDs for materials will still be required.

Some are concerned allowing bakes on HUDs increases the risk of texture theft (by allowing the textures to be screen capped, for example). However given this can be done anyway, simply by displaying a texture on a cube and then attaching the cube to the screen as a “HUD”, it’s hard to see what the fear really is (it’s also not the most efficient way of wrongly getting a texture out of SL).

[42:40-44:13] Fewer textures: the general hope with Bakes on Mesh is that over time, it will allow mesh bodies  / heads to be less onion layer complex, and also reduce the number of different textures being applied, by allowing layers (e.g. skin, make-up, tattoo, etc.), to be composited down to a single baked texture.

[44:26-45:52] Wearables cap: a reminder that up to 60 wearables can be applied to a single avatar in any combination of layers, and the order in which they are displayed corresponds to the individual layers (e.g. undershirt, shirt, jacket), and the order in which multiple items in those layers are worn. See this 2015 project update for more on the global wearable allowance.

[47:17-47:32] Can local textures be used with Bakes on Mesh? No. local textures are just that, local to a user’s system; they are not transmitted to LL’s servers, and therefore, they cannot be baked.

[48:10-49:00] Bakes on Mesh and Edit Appearance:  it’s been noted that mesh bakes don’t update with changes made in the Edit Appearance mode (see BUG-216014). This is because Edit Appearance is local changes within the viewer, usually applied to the system avatar. Bakes on Mesh require the data to be sent to the baking service, composited, and applied – which only happens on exiting Edit Appearance. Vir has indicated it might be possible to add the logic required to have the appearance editor update in real-time when using mesh bakes.

Continue reading “2018 SL UG updates #14/2: CCUG summary” →

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 29th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

Animesh Project

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.

Current Progress

Vir now has a proposed revised land impact / tri count formula and test plan for Animesh. This will be going to QA, and if all goes well, the new formulas will be deployed on the Aditi Animesh test regions ready for public testing. No end-date for public testing on Aditi has been defined – the Lab want to ensure as many as are interested have to opportunity to test the new formula. Animesh attachment will remain limited to one per avatar, at least for the time being.

It is likely that server-side support for Animesh will reach the Main grid ahead of the project viewer reaching release candidate status – although this still won’t be for a while.

LODs and Streaming Costs

How Animesh Level of Detail (LOD) is handled is still being tweaked. Currently, Animesh objects sit between in-world objects and avatars in terms of the way their LODs are handled / swapped. The Lab is looking to adjust this, so that Animesh LODs are more consistently handled as they would be for in-world objects.

The broad plan is – for Animesh only – that the lower LODs will not affect streaming costs so long as they are not disproportionately large. Providing they get smaller by at least a factor of approximately 2 as they go down to the courser LODS, they will not impact streaming costs.

Note this work is not part of Project Arctan, which may lead to further changes in costs associated with objects at some point in the future – see below for more.

Project ARCTan

This is the code-name for the project to re-evaluate object and avatar rendering costs (e.g. Land Impact and avatar ARC), led by Graham Linden as a part of the overall rendering system work. The aim of is to have the costs assigned to objects and avatar more accurately reflect the impact they have on people’s viewer performance.

The hope is that overall, by making a careful set of adjustments, not only can client-side performance be improved, but creators can be given positive incentives to build more performant content (a problem currently being that providing good LOD models – high, medium, low and very low – for mesh content can actually penalise a creator in terms of upload costs / Land Impact, encouraging them to skip doing so).

This project is still in the early stages, and the Lab is fully aware of the risks and concerns involved in potentially making changes to things like Land Impact (e.g. undesired object returns), and so are approaching the work cautiously. Right now, data is being gathered and internal comparative testing is being tried. There are no plans to make any kind of changes in the immediate future. When changes do start to be made, they will be done so carefully to avoid disruption, and users will be appraised of what is happening and when.

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.

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

It is important to note that this project is still in its preliminary stages. Any release of a project viewer doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Current Progress

The project viewer is still with QA with a couple of outstanding JIRAs awaiting resolution. The hope is that it will be making a public appearance soon.

When issued, this viewer should work anywhere, as it doesn’t require simulator changes. However, only those using the project viewer will see things as intended. Anyone on a viewer without the Bakes on Mesh updates will see placeholder textures, rather than the intended baked textures, on avatars trying the Bakes on Mesh capability.

Bakes on Mesh will essentially use the three avatar elements used by the baking service – head, upper body, lower body, eyes, hair, skirt), and applies clothing bakes for those elements to specific mesh faces, effectively “hiding” the corresponding base mesh region. This means for example, a head bake can be applied to a mesh head, an upper body to the mesh upper body faces, etc.  It does not at this point allow for more finely tuned applications – such as an individual jacket layer, or just to the hands.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements involving simulator and viewer changes, and includes some infrastructure updates.

Current Progress

Rider is still engaged on infrastructure work, which he hopes to complete Soon ^TM. Once that is done, he’ll complete the work on assets in inventory.

Custom Pivot Points

Work is being carried out to provide custom pivot points for mesh objects (see BUG-37617). This will most likely appear in a Maintenance RC viewer, once ready. The exactly implementation details weren’t clear at the meeting; it’s believed the data for the pivot point is coming from the corresponding data for the highest LOD in the uploaded .DAE file. However, the pivot point must be inside the bounding box of the object, and remains the centre of the object. Steps will also be taken to prevent pivot points placed outside of the bounding box simply causing the bounding box to increase in size (as did happen in a mesh uploader error), as this tends to both increase the objects LI by a factor of at least 2, and break the associated LODs.

Other Items

Texture Caching

Work continues on trying to improve texture caching in the viewer – which has already been an educational process for the Lab. There is nothing on the horizon yet in terms of updates for the viewer, as the work is not seen as a high priority when compared to other projects. However, there is a belief that there is room for “dramatic improvement” in the way textures are managed.

Permissions System

The question was asked if there are any plans to re-work the Second Life permissions system to be more supply chain driven, as is planned for Sansar. Short answer: there are no current plans to overhaul the permissions system simply because it is so complex. Currently the only thing being considered with permissions is extending them to allow scripted permission changes (formerly known as mod keys), which are seen as important for enhancing Animesh capabilities. However, here are current no time frame in when / if these will be implemented.

Firestorm RenderVolumeLODFactor Setting / Object LOD Confusion

Some appear confused by the recent RenderVolumeLODFactor behaviour change (see here) and what it is doing, believing it is part of a change to object LODs in Second Life.

Essentially, the Firestorm update is purely a viewer-side change only, intended to encourage users not to use over-the-top settings in their viewer which can affect performance, because changes to this value are globally applied, affecting all objects within the viewer’s field of view, not just a specific wearable or object.

However, this change does not mark any kind of change to the object’s LOD data held on the servers (the content isn’t being “changed” in any way on the back-end); it purely alters the way content is rendered by the viewer in terms of which LOD model of the object it uses.

Date of Next Meeting

There will be a CCUG meeting on Thursday, April 5th, as the normal LL internal meeting has been postponed a week.