[BUG-8132] Add LSL functionality to access Avatar Baked Textures

[sl-service-account]

How would you like the feature to work?

With the move to Server Side Appearance, all of the functionality of baking/merging various clothing layers is now handled on the Server side, rather than client side as was previously done. This means the LSL Scripting engine can now access not only the baking data, but the status of bakes as they occur to avatars within a simulator.

When an avatar adds or removes a clothing/alpha/tattoo layer, a new bake is generated, which is a combination of all currently worn layers. By creating a new function I will dub "llApplyBaked()", this merged texture could be applied to a suitable mesh avatar body replacement. This would mean, all of your skins, clothes, alpha layer, makeup, etc would work on a mesh body.

Roughly, "llApplyBaked()" would require this functionality:

• llApplyBaked(integer link_num, integer face, integer section)

• Where 'link_num' is the prim (or mesh) in the linkset to act on.

• Where 'face' is the face number of the mesh to apply the baked texture.

• Where 'section' is the bake section to apply to the specified face. Enumerated as: BAKED_HEAD BAKED_UPPERBODY BAKEDLOWERBODY BAKED SKIRT etc

  But to use this properly, a script would need to know when a new bake is available. This can be accomplished by extending the already existing "changed()" functionality.

  New "changed()" event:

• CHANGED_BAKE : Indicates the avatar has rebaked, and that a new set of baked textures are available for application. This allows the mesh avatar to update appearance to match any layer changes.

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

  Currently, creators have to do a lot of undesirable 'tricks' to approximate this functionality.

• Creators who create textured clothing layer apparel have to make these textures available separately via a scripted object called an "Applier". This object transmits the clothing texture UUID to the mesh body so it can 'wear' the item.

• The applier market is very fragmented, with a myriad of incompatible systems being utilized by various creators or more often not utilized at all.

• Appliers make for an easy vector to misappropriate original texture keys.

• Creators who create mesh bodies have to do several undesirable 'tricks' to simulate the functionality of the default avatar's clothing layer system.

• Divide the mesh body into numerous individual material zones (and often into numerous individual meshes to get around the 8 material per mesh limit), in order to simulate the effect of Alpha layering (hiding various parts of the body to prevent showing through various attachments).

• The whole mesh body often is layered 2-4 times over, in order to simulate clothing layers and tattoo layers. That means 2-4 times more triangles than would normally be required.

  This new system would eliminate all of these problems.

• The need for appliers would vanish. Any clothing/tattoo/alpha layer that can be worn by the avatar would be capable of being applied to the mesh automatically.

• Since the final baked texture is used, all clothing layers, tattoo layers, and alpha masking would be included, giving the single layer mesh al of the functionality of the Default Avatar clothing system.

• Misappropriation of the texture keys provided by this function would be nearly impossible: Because of the unique way the Server Side Appearance system handles baked textures, They are not served by the regular texture system, instead only being sent to the viewer in response to appearance requests by the default avatar. Therefore, if a mesh has these baked texture keys applied, they will not appear unless an avatar in the simulator has the exact same combination of layers on. In short, these texture keys are tied to the outfit that generates them. This is actually more limited than the full texture keys applier deal with now.

  Thanks for your consideration.

Links

Related

• [ ] https://github.com/secondlife/jira-archive/issues/13802
• [ ] https://github.com/secondlife/jira-archive/issues/820
• [ ] https://github.com/secondlife/jira-archive/issues/2900

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-8132 | | Summary | Add LSL functionality to access Avatar Baked Textures | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Reporter | Darien Caldwell (darien.caldwell) | | Created at | 2014-12-30T06:39:05Z | | Updated at | 2017-11-08T16:32:37Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2015-01-04T05:04:30.134-0600', 'How would you like the feature to work?': 'With the move to Server Side Appearance, all of the functionality of baking/merging various clothing layers is now handled on the Server side, rather than client side as was previously done. This means the LSL Scripting engine can now access not only the baking data, but the status of bakes as they occur to avatars within a simulator. \r\n\r\nWhen an avatar adds or removes a clothing/alpha/tattoo layer, a new bake is generated, which is a combination of all currently worn layers. By creating a new function I will dub "llApplyBaked()", this merged texture could be applied to a suitable mesh avatar body replacement. This would mean, all of your skins, clothes, alpha layer, makeup, etc would work on a mesh body.\r\n\r\nRoughly, "llApplyBaked()" would require this functionality:\r\n\r\n- llApplyBaked(integer face, integer section)\r\n- Where \'face\' is the face number of the mesh to apply the baked texture.\r\n- Where \'section\' is the bake section to apply to the specified face.\r\nEnumerated as:\r\nBAKED_HEAD\r\nBAKED_UPPERBODY\r\nBAKED_LOWERBODY\r\nBAKED_ SKIRT etc\r\n\r\nBut to use this properly, a script would need to know when a new bake is available. This can be accomplished by extending the already existing "changed()" functionality.\r\n\r\nNew "changed()" event:\r\n- CHANGED_BAKE : Indicates the avatar has rebaked, and that a new set of baked textures are available for application. This allows the mesh avatar to update appearance to match any layer changes. \r\n', 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'Currently, creators have to do a lot of undesirable \'tricks\' to approximate this functionality.\r\n- Creators who create textured clothing layer apparel have to make these textures available separately via a scripted object called an "Applier". This object transmits the clothing texture UUID to the mesh body so it can \'wear\' the item. \r\n - The applier market is very fragmented, with a myriad of incompatible systems being utilized by various creators or more often not utilized at all. \r\n - Appliers make for an easy vector to misappropriate original texture keys.\r\n\r\n- Creators who create mesh bodies have to do several undesirable \'tricks\' to simulate the functionality of the default avatar\'s clothing layer system. \r\n - Divide the mesh body into numerous individual material zones (and often into numerous individual meshes to get around the 8 material per mesh limit), in order to simulate the effect of Alpha layering (hiding various parts of the body to prevent showing through various attachments).\r\n - The whole mesh body often is layered 2-4 times over, in order to simulate clothing layers and tattoo layers. That means 2-4 times more triangles than would normally be required. \r\n\r\nThis new system would eliminate all of these problems.\r\n - The need for appliers would vanish. Any clothing/tattoo/alpha layer that can be worn by the avatar would be capable of being applied to the mesh automatically. \r\n - Since the final baked texture is used, all clothing layers, tattoo layers, and alpha masking would be included, giving the single layer mesh al of the functionality of the Default Avatar clothing system.\r\n\r\n- Misappropriation of the texture keys provided by this function would be nearly impossible:\r\n Because of the unique way the Server Side Appearance system handles baked textures, They are not served by the regular texture system, instead only being sent to the viewer in response to appearance requests by the default avatar. Therefore, if a mesh has these baked texture keys applied, they will *not* appear unless an avatar in the simulator has the exact same combination of layers on. In short, these texture keys are tied to the outfit that generates them. This is actually more limited than the full texture keys applier deal with now.\r\n\r\nThanks for your consideration.', } ```

[sl-service-account]

Satomi Ahn commented at 2015-01-04T11:04:30Z

NiranV Dean put a valid objection to this in the comments of BUG-8100: when you wear a custom mesh body, you need to hide your legacy body with a full-body alpha, thus preventing the server to actually bake the composite textures you need (instead it bakes transparent textures).

Can we add as a requirement that a way to hide the standard avatar must be added (server and client side) that does not use a full body alpha? Or any other method that would have the effect of hiding the standard avatar (sending fully transparent textures to all other clients, for backward compatibility) while still baking the composites you need for your custom body?

[sl-service-account]

Inara Pey commented at 2015-01-06T20:14:00Z

As baking doesn't actually happen on the simulators, but is effectively a separate service, how would LSL access the baking data?

[sl-service-account]

Jenna Felton commented at 2015-01-07T01:25:49Z, updated at 2015-01-07T01:32:58Z

The idea is indeed interesting and has merrit. But I see a difficulty there.

That is, not all bodies of mesh avatars have the same mapping and the same mapping the linden avie has. The mesh body I am wearing has definitelly a special one, and as far I know only the avatar by Chip Midnight uses the mapping that is very close to the mapping of the linden avatars, so textures backed by SSA server would work well for that body but not for mine. However, the solution could be to allow to backe the final mesh texture from the used mesh skin texture and alpha texture, instead of the avatar skin and alpha layers.

Also, that the advantage of mesh clothes is, that they have 3D structure. Shirts go over the breats and not between them, The jacked is even far outstanding from the skin and shirt and so on. Simulating clothes by bringing textures around the mesh body is removing that advantage, so your suggestion will not eliminate all mesh clothes, but some.

However, when it could make possible to erase parts of the mesh skin picture by backing it with the alpha picture needed for the worn clothes, that would very much improve the system of mesh clothes, since much more clothing would work with incompatible mesh bodies (that is often a problem to find one that looks good on your avie, even when it has zones you can hide.)

Then, how to provide that alpha picture? I'd suggest to allow a mesh Alpha layer to be created in the same way as you do when you create an avatar alpha layer, but you select here a single image and it is used - when that alpha layer is worn with your clothes - to backe with your mesh skin image and then to bring on the mesh body.

[sl-service-account]

Siddean Munro commented at 2015-01-07T03:04:32Z

At first glance this seems like a great idea but there are several issues with it. Full body alphas, UV mapping, although Jenna, I believe quite a number of mesh bodies use the default SL mapping. I know mine does, except for the feet because it's impossible to make feet with toes from the avatar UV template as it is. Also, textures often need editing for mesh bodies, so placement of body landmarks, and things like painted on fingernails will be wrong if transferred straight from the avatar. The more I think about this, the more I prefer the material slot for alpha textures Jira. https://jira.secondlife.com/browse/BUG-8100#comment-453950

[sl-service-account]

Satomi Ahn commented at 2015-01-07T13:49:12Z

@Inara: to access baking data, maybe we could devise a new dataserver asynchronous request? Also I have an alternative proposal: instead of llApplyBaked(), it might be more interesting to create 6 new reserved UUID constants, one for each avatar face, that would always denote the texture baked for that face for the avatar wearing the object. This way, LSL (or the simulator) would never need to know the actual baked texture UUID, but as clients can already access baked texture UUID for any avatar they see, they would know how to do the translation.

Pros: does not need much server-side changes (only 6 new LSL constants). Cons: would only work with updated clients who know that they need to translate these constants into UUIDs of actually baked textures.

[sl-service-account]

Satomi Ahn commented at 2015-01-07T14:05:48Z

Talking with other people, this is also a need that emerged: ability to bake only a subset of worn clothing (as to apply the texture a slightly different mesh, for instance, for outer clothing that should not be painted on the body). But as said Siddean, this use case should be taken care of by normal maps (materials). Note that this also means that we should be able to bake material textures together if we want the ability to apply several pieces of clothing to the same surface.

Making a synthesis of both trends: what we need is the ability to bake arbitrary texture sets with options for different baking methods/operations (classical superposition of 32 bits textures, alpha layer union, addition (or max) for normal maps, and so on). Then the question of the UV map loses some of its relevance (as long as all baking sets use the same UV map, and that the result is applied to a compatible mesh).

All of this would be nice. Still the initial proposal keeps one advantage: the ability to use the old system clothing on newer mesh bodies.

[sl-service-account]

Kyle Linden commented at 2015-01-07T19:09:14Z

Thank you for your suggestion. We've reviewed your request and determined that it is not something we can tackle at this time.

Please be assured that we truly appreciate the time you invested in creating this feature request, and have given it thoughtful consideration among our review team. This wiki outlines some of the reasoning we use to determine which requests we can, or can't, take on: http://wiki.secondlife.com/wiki/Feature_Requests

Thanks again for your interest in improving Second Life.