Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-214631] Exact Recommended Specifications for "Bakes on Mesh" Project #3335

Open
2 tasks
sl-service-account opened this issue Feb 23, 2018 · 1 comment
Open
2 tasks

Comments

@sl-service-account
Copy link

sl-service-account commented Feb 23, 2018

How would you like the feature to work?

This JIRA is meant as a tie in / update to https://jira.secondlife.com/browse/BUG-10980. To increase specificity and hopefully define project scope and stages for the already in-progress "Bakes on Mesh" project.

Step 1: [ Already completed ] Increase the capacity of the baking service to composite and output textures at 1024 x 1024 resolution. : This was done to keep "pace" with the present already widely implemented "applier system" that is simply layering multiple 1024 x 1024 alpha textures on top of multiple layers of mesh (dubbed onion avatars) to achieve a partial reproduction of the manner in which the Linden Avatar system clothing and tattoo layers worked.

Step 2: Specify a means of removing the visibility of the presently worn default Linden body that does not involve the use of alpha textures as seen by the baking service. Preferably this would be done on a per-texture-sheet basis. IE Head, Torso, Legs, and Eyeballs would all be their own removable entities. The reason for this, is because many avatars still use the existing Linden avatar head, with other mesh addons. A simplistic "Remove all" command would be sufficient~ if that is the only feasible way to accomplish hiding the default body without using the existing alpha texture system but, it would be far far from being ideal. The goal of this is to enable having meaningful alpha cutouts for skin textures. In old days outfits we purchased had system alpha layers to cut holes in the skin texture so that they wouldn't poke through meshes. Now-a-days it's simply used to completely hide the existing body. Having an alternative means of "vanishing" parts of the avatar would allow the baked output texture ( replete with it's alpha masked holes ) to be projected on a mesh, thus adding that old utility of removing the visibility of certain parts of a mesh body to user-created mesh body assets.

Step 3: Establish an LSL command to assign an "Output channel" (composited texture UUID) of the Baking service for an avatar to a Mesh Face. Ideally this would be owner-restricted. IE "Get_Owner_Torso_Bake_Output" and Assign it to Mesh Face [0 -7] of this mesh. This would replace the existing diffuse texture with whatever the baker has outputted, based on the current owner of the mesh object the script is running in~ this output would have to be refreshed every time the baker runs again and spits out a new UUID either by viewer UI command or by changing their wardrobe. It also would have to forcibly update each time there was an ownership change on the asset it resides in, or else people could migrate looks around via transfer objects until the baker output UUID expires, leaving the object grey. In theory, texture application could also be done via the edit menu, but as with some other things~ such as texture animation, I really feel like an LSL function is all that is needed in this case. The reasoning and logic behind this is, there are already thousands of people who are used to the applier HUD system, and for the reasons of supporting the widest range of content, people will probably want to keep their applier system based HUDS, so adding this functionality in LSL form to them makes the most sense. At least initially~ until the day when most of the "applier" based content is updated or hopelessly outdated. I don't see a need for a viewer UI based "Right click and put my face on this prim-cube" functionality.

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

It's very difficult to force end users and content creators alike into changing their habits. So the idea is to initially provide this as an option. That will hopefully reduce the number of 1024x1024 textures. As giving these to the baker will composite them better, reduce alpha layering (OpenGL Z-fighting) rendering glitches and hopefully encourage designers to reduce the number of onion layers on their bodies.

Encouragement and enforcement are two separate notions though, and I'm not anticipating the un-enforced complete removal of onion layers. I'm merely hoping that in the short term they will no longer be populated with dense textures. If we could hold a meeting with the premier mesh body designers, and establish the removal of one or more onion layers. (Tattoo is the most readily obvious one for removal ) from their products, it would be very much a step in the right direction.

Enforced removal of the onion layers will only really become a reality once render costs are adjusted and enforced via the rumored project ARCTan.

Problems, Caveats, and "Ideal Functionality" and other things that would be nice~ but are probably Out of Scope

When I originally recommended "Bakes on Mesh" the idea was floated of taking an arbitrary set of textures and simply asking the baking service "Here, meld these together based on this set of rules" It was quickly deemed to be too much work, and the above iteration was settled upon as practical. However~ there's a few (albeit minor) issues with the chosen implementation.

Limitations on Materials: People like shiny skin. Beq pointed out to me that while 99% of clothing appliers these days do not come with materials layers~ the effect of a non-materials undergarments & clothes overlaid via onion layers ontop of a materials skin, thus occluding the skin material layer, is actually pronounced and very nice. Having the baker only function for diffuse textures pulled from the avatar layer system is limiting~ albeit not in a project crippling manner. In the war-of-ideas however, on convincing people to drop the current implementation in lieu of the newer one~ losing functionality of any sort is not enticing ( hence the reason that Step 1 was needed above ). It is for this reason that this feature may not initially kill onion avatars as stone-dead as we are currently hoping it will. (Our exercise clothes shouldn't shine with sweat, but in the present planned implementation they will ~ if we have a sweat specular on!)
Possible solution to the above:
Extend System clothing assets to use materials: if you extended system clothes to all have their own materials channels, it would work. To have the desired effect, you would retroactively fill in every existing clothing asset with a blank materials texture ( 128,128,255 normal , 0,0,0 spec ) proportional to it's source image size with a mask based on it's diffuse alpha opacity, or interpolate that data on demand. That mask would "cut out" the normal and specular effects for compounding purposes. These could then be layered on top of existing normal / specular maps for a true materials composite effect. This would circumvent the problem of normal and specular maps presently using their alpha channels for materials data. At the core of it though, this solution is essentially "compound a normal map using the alpha channel of a diffuse map as an input". Which brings us to a different possible future implementation below ~~~

Limited Extensiblity: Ideally texture compositing really shouldn't be something that's limited to a worn entities or just the diffuse channel. There's plenty of use cases for "Feed the baker this set of textures and stick the output on this face" such as baked shadows and emulated caustics. All of these involve compositing one texture atop another one in some manner and stuffing the output onto an entity. This would be possible to do in just as secure a manner as presently exists for texture assignment. "Here's a list of the UUID's of the textures I want assigned to this object face" ~ the only distinction being "hey, baker, glue this set together first". Vir pointed out the obvious technical issue of that requiring the creation of a new texture asset owned by no one on the asset server in order for it to be continually pulled and referenced by objects in world. Hence why this is in the "out of scope~ and maybe next..." section. But I don't see this as an insurmountable problem, nor as being a security risk. If completion time is not a pressing urgency on this project~ possibly "doing it all in one go" would be advantageous?

The goal of this after all ~ is to provide means for preserving the visual quality that people are accustomed to while creating avenues for optimization. Thus SL can grow and evolve graphically. The latter implementations on this Feature request have the advantage of surviving better as the SL materials system grows and becomes more and more widely adopted.

Links

Related

Original Jira Fields
Field Value
Issue BUG-214631
Summary Exact Recommended Specifications for "Bakes on Mesh" Project
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Labels bakesonmesh
Created at 2018-02-23T05:20:39Z
Updated at 2018-04-11T14:26:17Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2018-03-07T13:19:57.657-0600',
  'How would you like the feature to work?': 'This JIRA is meant as a tie in / update to https://jira.secondlife.com/browse/BUG-10980.  To increase specificity and hopefully define project scope and stages for the already in-progress "Bakes on Mesh" project.\r\n\r\nStep 1: [ Already completed ] Increase the capacity of the baking service to composite and output textures at 1024 x 1024 resolution.  :  This was done to keep "pace" with the present already existing applier system in place that is simply layering multiple 1024 x 1024 alpha textures on top of multiple layers of mesh to achieve loose reproductions of clothing and tattoo layers.\r\n\r\nStep 2: Specify a means of removing the visibility of the presently worn default Linden body that does not involve the use of alpha textures as seen by the baking service. Preferably this would be done on a per-texture-sheet basis.  IE Head, Torso, Legs, and Eyeballs would all be their own removable entities.  The reason for this, is because many avatars still use the existing Linden avatar head, with other mesh addons.    Though a "Remove all" command, if that is the only feasible way to accomplish this would be sufficient, it wouldn\'t be ideal.\r\n\r\nStep 3: Establish an LSL command to assign an "Output channel" of the Baking service for an avatar to a Mesh Face.  Ideally this would be owner-restricted.  IE "Get Owner Torso Bake Output" and Assign it to Mesh Face [0 -7] of this mesh. This would replace the existing diffuse texture with whatever the baker has outputted, based on the current owner of the mesh object the script is running in.   In theory, this could also be done via the edit menu.  But as with some other things~ such as texture animation, I really feel like an LSL function is all that is needed in this case.  The reasoning and logic behind this is, there are already thousands of people who are used to the applier HUD system, and for the reasons of supporting the widest range of content, people will probably want to keep their applier system based HUDS.  At least initially.\r\n',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': "It's very difficult to force end users and content creators alike into changing their habits.  So the idea is to initially provide this as an option.  That will hopefully reduce the number of 1024x1024 textures.  As giving these to the baker will composite them better, reduce alpha composite glitches and hopefully encourage designers to reduce the number of onion layers on their bodies.\r\n\r\nEncouragement and enforcement are two separate notions though, and I'm not anticipating the enforced removal of onion layers.  I'm merely hoping that in the short term they will no longer be populated with dense textures.  If we could hold a meeting with the premier mesh body designers, and establish the removal of one or more onion layers. (Tattoo is the most readily obvious one for removal ) from their products, it would be ideal.\r\n\r\nEnforced removal of the onion layers will only really become a reality once render costs are adjusted and enforced via the rumored project ARCTan.",
}
@sl-service-account
Copy link
Author

Vir Linden commented at 2018-03-07T19:19:58Z

This has several proposals for bakes on mesh, some of which might be considered for the bakes on mesh project, and some of which might be possible future work. Importing accordingly.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant