[BUG-228175] BOM: Enable inworld/viewer alpha mask creation/editing.

[sl-service-account]

How would you like the feature to work?

Another in the series of BOM-related feature requests, enhancing the viewer to usability on a par with the current user experience via HUDs

In-viewer alpha mask wearable creation

The aim is to allow users to create and/or edit the alpha layers that are required to hide parts of the underlying mesh body when using BOM.

The current alpha wearable edit floater would be enhanced to provide two new tabs:

The first is a segmented overlay that gives users a familiar type of interface, functionally replicating (and ultimately replacing) their current segmented body HUD. (see Slink and Maitreya HUD examples)

The following shows an early concept mockup UI and illustrates the two tabs for standard and advanced mode.

The second view is an advanced tab that allows users to "draw" a mask manually, this moves away from the need to "cut" clothes to fit the segmentations of a given body; enabling older mesh clothing to be used where it was not possible before and giving creators themselves a simplified route to create and upload masks for their products before selling them. This is a more complex proposition requiring rudimentary drawing tools to be provided though at the most basic level this need be no more than a simple brush size control.

The checkbox below the UV layouts causes a local overlay of the UV guide texture to be placed on the avatar allowing the fine-tuning of the alpha to the body/garment. The alpha mask itself would also be composited locally and applied to the avatar for preview.

To make this as attractive as possible mask creation should be free, (it currently costs 5 uploads - minimum assuming no errors are made - to fully populate an alpha wearable) whereas the existing segmented mesh HUDs have no per usage monetary cost.

In theory, a case could be made to have a charge levied for masks that are to be shared/sold though this seems unnecessary in the grand scheme of things.

User-configurable segmented masks

An alternative, and more practical, design to the one envisaged above is to provide the overlay UI on top of the underlying UV map, this removes the maintenance overhead of mapping segments from one projected view to another, especially where they might cross multiple alpha mask textures. It also opens the possibility of fully customisable UV editing through the provision of custom data sets provided by creators of bodies.

Initial thoughts on this are that the creator would provide a folder of mask images and a small data file to describe their alignment.

The data file would most likely be XML, but JSON would also be viable. In its simplest form, the file need only define a UV guide (a UUID preferably) that would form the backdrop to the masks, the masks themselves would be loaded from the folder containing the XML file, there is no requirement for these to be UUIDs, they are never visible inworld and the upload cost would make this unattractive.

Allowing users to import overlays into the UI potentially opens a number of maintenance concerns that are beyond the scope of this initial feature request.

Why is this feature important to you? How would it benefit the community?

With the introduction of BOM, the desire is to escape the significant rendering overhead of segmented mesh bodies. The inconvenience of the alpha editing function makes BOM highly unattractive to users who are comfortable with the simple point and click alpha capability provided by their body's HUD.

This feature would remove that restriction allowing body creators to escape from the burden of maintaining the segmentation and return to a far simpler model without the risk of falling short of their customers' expectations around usability. It would also make the creation of alphas simpler for clothing creators.

Should the UI be user/creator configurable?

Configurability of the segmentation view is highly desirable as the cut placement of existing bodies is a much-disputed matter, at the very least the default provided masking should aim to be at least as configurable as the superset of all the major bodies. The bodies are limited in practical terms because the segments have to map to mesh texture faces and are a maintenance nightmare, in the UI case the resource constraint is far lower.

A further case for allowing user-defined overlays is to enable more diversity of mesh bodies, especially for those that are not of a human form. A customisable overlay system would enable mesh bodies that do not map directly to the LL UV map to be supported by the viewer.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-228175 | | Summary | BOM: Enable inworld/viewer alpha mask creation/editing. | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Labels | bakesonmesh | | Reporter | Beq Janus (beq.janus) | | Created at | 2020-02-05T15:02:14Z | | Updated at | 2021-02-24T20:19:20Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2020-02-05T13:43:20.532-0600', 'How would you like the feature to work?': 'Another in the series of BOM-related feature requests, enhancing the viewer to usability on a par with the current user experience via HUDs\r\n\r\nIn-viewer alpha mask wearable creation\r\n\r\nThe aim is to allow users to create and/or edit the alpha layers that are required to hide parts of the underlying mesh body when using BOM. \r\n\r\nThe current alpha wearable edit floater would be enhanced to provide two new tabs:\r\n\r\nThe first is a segmented overlay that gives users a familiar type of interface, functionally replicating (and ultimately replacing) their current segmented body HUD. \r\n(see Slink and Maitreya HUD examples)\r\n\r\n!https://i.gyazo.com/994a241cba107b16d1470f90c0fec4b9.png!\r\n!https://i.gyazo.com/490ca1e68585dab4d48439edf0c5a6ef.png!\r\n\r\nThe following shows an early concept mockup UI and illustrates the two tabs for standard and advanced mode.\r\n\r\n!https://i.gyazo.com/c449685049e9908b4726b0c712644765.gif!\r\n\r\nThe second view is an advanced tab that allows users to "draw" a mask manually, this moves away from the need to "cut" clothes to fit the segmentations of a given body; enabling older mesh clothing to be used where it was not possible before and giving creators themselves a simplified route to create and upload masks for their products before selling them. This is a more complex proposition requiring rudimentary drawing tools to be provided though at the most basic level this need be no more than a simple brush size control.\r\n\r\nThe checkbox below the UV layouts causes a local overlay of the UV guide texture to be placed on the avatar allowing the fine-tuning of the alpha to the body/garment. The alpha mask itself would also be composited locally and applied to the avatar for preview. \r\n\r\nTo make this as attractive as possible mask creation should be free, (it currently costs 5 uploads - minimum assuming no errors are made - to fully populate an alpha wearable) whereas the existing segmented mesh HUDs have no per usage monetary cost. \r\n\r\nIn theory, a case could be made to have a charge levied for masks that are to be shared/sold though this seems unnecessary in the grand scheme of things.\r\n\r\nUser-configurable segmented masks\r\n\r\nAn alternative, and more practical, design to the one envisaged above is to provide the overlay UI on top of the underlying UV map, this removes the maintenance overhead of mapping segments from one projected view to another, especially where they might cross multiple alpha mask textures. It also opens the possibility of fully customisable UV editing through the provision of custom data sets provided by creators of bodies. \r\n\r\n!https://i.gyazo.com/9cab1c1f0381b8a42d773cb0785e8ed3.gif!\r\n\r\nInitial thoughts on this are that the creator would provide a folder of mask images and a small data file to describe their alignment. \r\n\r\nThe data file would most likely be XML, but JSON would also be viable. \r\nIn its simplest form, the file need only define a UV guide (a UUID preferably) that would form the backdrop to the masks, the masks themselves would be loaded from the folder containing the XML file, there is no requirement for these to be UUIDs, they are never visible inworld and the upload cost would make this unattractive.\r\n\r\nAllowing users to import overlays into the UI potentially opens a number of maintenance concerns that are beyond the scope of this initial feature request.\r\n', 'Original Reporter': 'Beq Janus (beq.janus)', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "With the introduction of BOM, the desire is to escape the significant rendering overhead of segmented mesh bodies. The inconvenience of the alpha editing function makes BOM highly unattractive to users who are comfortable with the simple point and click alpha capability provided by their body's HUD. \r\n\r\nThis feature would remove that restriction allowing body creators to escape from the burden of maintaining the segmentation and return to a far simpler model without the risk of falling short of their customers' expectations around usability. It would also make the creation of alphas simpler for clothing creators. \r\n\r\nShould the UI be user/creator configurable?\r\n\r\nConfigurability of the segmentation view is highly desirable as the cut placement of existing bodies is a much-disputed matter, at the very least the default provided masking should aim to be at least as configurable as the superset of all the major bodies. The bodies are limited in practical terms because the segments have to map to mesh texture faces and are a maintenance nightmare, in the UI case the resource constraint is far lower. \r\n\r\nA further case for allowing user-defined overlays is to enable more diversity of mesh bodies, especially for those that are not of a human form. A customisable overlay system would enable mesh bodies that do not map directly to the LL UV map to be supported by the viewer.\r\n", } ```

[sl-service-account]

Vir Linden commented at 2020-02-05T19:43:21Z

This seems like a tough feature. Is there a uniform convention for what the different region boundaries should look like, or is this vendor-specific? We do not currently have any tools for image editing, only support for uploading a new image, so this would require significant changes there too.

[sl-service-account]

Beq Janus commented at 2020-02-05T22:18:17Z

I agree, it's tough in it's fullest extent, but if we put aside the image editing of the advanced tab for now and look at the compositing of segmented masks then that is less innovative. In TPVs that have legacy baking code we already have the code for compositing images so it shouldn't be a stretch to adapt that, the code could be contributed back if it has been removed completely from the LL codebase.

There is no convention for where to cut, they all do it differently which in turn makes producing garments that are compatible across multiple bodies more complex an undertaking with the existing alphacut bodies.

This leads to two paths forward:-

1) provide a superset of the top N alpha cut bodies thus giving more configurability than any of them have today. This is doable because in this solution we are not constrained in the number of cuts by the ever-increasing complexity of the mesh.

2) allow user-installed overlays (we have sketched a data-driven design for such a solution that is not actually that complex). there are pros and cons to this, one of the more interesting pros is that it enables non-standard UVmaps to still work with the in-viewer tools. There are popular (but relatively niche) bodies that do not adhere to the LL UV map, due to special needs, there are non-human avatars that fall inot this space too. It is more work and option #2 is not mutually exclusive to option #1 allowing us to do #1 first and migrate to #2 later.

 

[sl-service-account]

Ai Austin commented at 2020-06-08T08:43:06Z, updated at 2021-02-24T20:19:21Z

I think this would be a fantastic facility. Now we have BoM and should encourage alpha masks to be provided with mesh clothing that can be used with any classic or mesh/BoM body it ought to become the norm to use fine grain alpha masks with any avatar.

But today alpha mask production does require some proficiency with a graphics editor and a lot of messing about to dress an avatar in a SLUV map, wear clothing, look for poke through and paint those onto an alpha mask, make the transparency layer and upload and test. I always find it takes a few goes to get things right.

I don't think this needs to be specific to any one mesh body at all. It would probably best be based on the standard SL UV mapping and hence, as in one of Beq's suggestions, the "UI" could just be to paint over a base image of the standard SLUV image as a underlayer.

It would probably be fair to charge the same as a texture upload to save the alpha mask produced after it has been produced and tested.

The new version of the Ruth2 v4 (in progress) and Roth2 v2 mesh bodies are set up to work best with BoM and don't have fine alpha cuts, but use just the maximum number of faces on any single mesh for coarse alpha cuts, allowing for fine grain alpha masking where necessary. Roth2 v2 is already on the SL marketplace at https://marketplace.secondlife.com/stores/228512

[sl-service-account]

Kyle Linden commented at 2020-06-10T19:01:03Z

Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.

Thank you for your continued commitment to Second Life.

[sl-service-account]

Vir Linden commented at 2020-12-09T15:44:59Z

I'm importing this to keep track of it as one possible approach to a longstanding problem. We are not specifically committing to implementing this approach.