sl-service-account
commented
4 years ago Vir Linden commented at 2020-02-05T19:35:26Z
The current bake service expects to be dealing with items in user inventory. Modifying to handle items in object inventory would be an interesting approach but would require some significant work. Would also require UI changes to all of the outfit editing and display features.
I will bring this in as something to consider for BOM follow-on work.
How would you like the feature to work?
Bakes On Mesh is expected to bring about the demise of the burden of onion layer avatars which add considerably to the rendering time for an avatar. At present however, the move to "proper" BOM mesh body results in a reduced user experience in a number of ways. This Jira is one of a series that proposes potential features to address this.
A "proper" BOM body, for the purpose of these jiras is one that eliminates all unnecessary onion skin layers mesh, as opposed to those that persist with existing onion meshes and a HUD relay that allows the BOM textures to be specified as the base layer.
Request: HUD interaction with wearables. One of the biggest losses in usability is the inability to visually peruse and apply bakeable layers. This applies to tattoos, makeup, lipstick, eyeliner, etc.
There are two routes to allowing HUD access to the bake service. One is defined in the Jira https://jira.secondlife.com/browse/BUG-216137. This method allows complex script level access to the bake service. It is very powerful.
An alternative is to allow HUDs (HUD point attached scripted objects) to access wearables contained in the HUD object and apply them to the avatar. The requirement that the scripted object is worn on a HUD point is to avoid potential abuse.
This method does not give the flexibility proposed by Chellynne's Jira but it would enable assets to be applied. There is no requirement for placement control in this case, that can be managed through the existing viewer user interface.
Note: This is currently achievable via RLV on TPVs though they can only control wearables within a known folder structure limiting the usability.
Why is this feature important to you? How would it benefit the community?
The typical use case for the non-BOM user is that they wear a HUD with the pallette of makeup colours,( or tattoo designs etc) that they want to try and click on the thumbnail for the shade/style that they want. This is then applied. The BOM equivalent is scrolling through a list of opaque inventory in the hope that they are named in a manner that conveys the colour/design and then applying it. The following image illustrates a simple example of a recently released lipstick pallette, the creator has gone to the trouble of providing both BOM and HUD based versions. The screen shot shows the interface for each.
For me this is an interim solution, it enables usability that is otherwise lost and stands as a barrier to BOM adoption. Long term I would hope that a fully viewer integrated inventory browser could remove the need for these resource hungry HUDs entirely.
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-228155 | | Summary | BOM: Enabling HUD interaction with bakes | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Beq Janus (beq.janus) | | Created at | 2020-01-31T02:11:00Z | | Updated at | 2020-02-05T19:35:42Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2020-02-05T13:35:26.231-0600', 'How would you like the feature to work?': 'Bakes On Mesh is expected to bring about the demise of the burden of onion layer avatars which add considerably to the rendering time for an avatar. At present however, the move to "proper" BOM mesh body results in a reduced user experience in a number of ways. This Jira is one of a series that proposes potential features to address this. \r\n\r\nA "proper" BOM body, for the purpose of these jiras is one that eliminates all unnecessary onion skin layers mesh, as opposed to those that persist with existing onion meshes and a HUD relay that allows the BOM textures to be specified as the base layer.\r\n\r\nRequest: HUD interaction with wearables.\r\nOne of the biggest losses in usability is the inability to visually peruse and apply bakeable layers. This applies to tattoos, makeup, lipstick, eyeliner, etc.\r\n\r\nThere are two routes to allowing HUD access to the bake service. One is defined in the Jira https://jira.secondlife.com/browse/BUG-216137. This method allows complex script level access to the bake service. It is very powerful.\r\n\r\nAn alternative is to allow HUDs (HUD point attached scripted objects) to access wearables contained in the HUD object and apply them to the avatar. The requirement that the scripted object is worn on a HUD point is to avoid potential abuse. \r\n\r\nThis method does not give the flexibility proposed by Chellynne\'s Jira but it would enable assets to be applied. There is no requirement for placement control in this case, that can be managed through the existing viewer user interface.\r\n\r\nNote: This is currently achievable via RLV on TPVs though they can only control wearables within a known folder structure limiting the usability.', '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?': 'The typical use case for the non-BOM user is that they wear a HUD with the pallette of makeup colours,( or tattoo designs etc) that they want to try and click on the thumbnail for the shade/style that they want. This is then applied. The BOM equivalent is scrolling through a list of opaque inventory in the hope that they are named in a manner that conveys the colour/design and then applying it. The following image illustrates a simple example of a recently released lipstick pallette, the creator has gone to the trouble of providing both BOM and HUD based versions. The screen shot shows the interface for each.\r\n!https://i.gyazo.com/ce723876dfaee5156689044cfb001753.jpg!\r\n\r\nFor me this is an interim solution, it enables usability that is otherwise lost and stands as a barrier to BOM adoption. Long term I would hope that a fully viewer integrated inventory browser could remove the need for these resource hungry HUDs entirely.', } ```