Vivian Rail commented at 2018-04-19T22:34:44Z

A few things to add here.
1: The layer integer should be more flexible. For example a skin would be 0, a tattoo would be 1-10, a lipstick 11-20, an eyeshadow 21-30, an eyeliner 31-40, and so on. Clothing layers would occupy higher numbers. System clothing would use integer values based on the type, and tattoo system clothing could include an integer value to specify a target depth.
2: To have feature symmetry to the system clothing objects, tint would also need to be included
3: A float for alpha should also be added to allow layers to be faded, which is a well-loved feature for makeup systems.
4: The ability to bake textures together separate from the system layers is an obvious and essential extension to this. Any avatar component that uses a custom UV will have use for a custom bake stack which is unentangled with any system clothing layer, and this also leaves open the door to put clothing onto a different mesh (since clothing that's painted onto the skin is only ok sometimes.

The functions I would suggest is this:

key llAddToBake(key UUID, key TargetUUID, integer Layer, vector Tint, float Alpha)

• The function could be used to target an existing bake key, or create a new bake stack using TEXTURE_NEW_BAKE constant
• The returned key would either be a new key for the new texture (which would follow the avatar around the grid), or the same key as the TargetUUID

llDeleteFromBake(key uuid, key TargetUUID)

• of course we need a way to take a texture back out of the bake stack.

Lastly, the part of this that could be kicked down the road (but really shouldn't) is materials support. Every mesh body and head system uses materials to improve the appearance of the skin. I'll go ahead and say it again, this needs to be thought through and included in the MATERIALS baking service. Just baking the diffuse was the status quo back in 2005. Now it isn't. Make the system for 2018.

polysail commented at 2018-04-19T22:44:00Z, updated at 2018-04-19T22:52:13Z

Caveats: Technical Difficulties Etc:

Once you insert a texture into the "stack", how does it get removed? At some point the user needs a visual indicator of "I'm wearing this applied texture." In the event that said user would like to ~ not be wearing said texture anymore." In an applier system that, by default is tracked in the associated HUD of the item that the texture is glued upon. But once this has been offloaded to a universal baker, the default go-to location for such a thing to appear is in the "currently worn" items tab. Which effectively makes this project about creating and wearing temporary inventory items. However, that is now a modification to the entire inventory system of SL, including changes to the way the entire server handles inventory. That being said, Oz has specifically stated that modifying how inventory is handled on SL is something that is exceedingly difficult and is generally avoided at all costs.

One possible workaround for such a thing is to have each mesh asset / script keep track of what it's "inserting" into the stack, and then removing it when it's no longer worn, via some sort of "baker listener" mechanic. But then you also have the accounting / griefing issue "well exactly how many items can I add to a stack before I hit a limiter? Does this count towards the user's total "worn items" count? Should it? What is to prevent someone from adding a ton of objects to said stack just to take them all up and stress out the baking service. With HUDS it's at least limited to a specific number of slots ~ but what's to prevent someone from surreptitiously adding things. What happens when two different HUDS compete for the same stack-space?

Essentially applier HUDS create "additional inventory and inventory organization" on a per-mesh basis. That is their present utility that they bring. The goal of this is to preserve that ease of use functionality. Visually looking at 64 different models and going "mmm I want to wear this one" is far more appealing and convenient than dredging through 64 different similarly named inventory items. And convenience really does sell. The biggest mesh bodies are "big" because they have a good applier system backing them and a clothing community designing for them. The downside is of course, that their design is also killing SL render times horrifically.

The challenge of Bakes on Mesh, as a whole is to preserve as much convenience and quality of content without the render cost, but sadly at the end of the day, unless there is a workaround here, onion avatars will need to remain just to support the hundreds of thousands of (probably millions?) of existing "applier only" textures that are in circulation presently.

Mel Vanbeeck commented at 2018-04-19T22:57:14Z, updated at 2018-04-19T23:00:36Z

I would say that the issue of how to remove layers inserted via script would be handled by the function mentioned earlier which explicitly names the UUID to remove, and then a troubleshoting function which removes all script-inserted layers from a stack.

llClearBake(key TargetUUID)

Also potentially useful is a query
ineteger llFindInBake(key UUID, key TargetUUID)

• which would return the level that texture is currently installed in a bake stack, or -1 if it's not present.

  Regarding griefing, I would just say that at least initially baked textures all apply to the 62 worn item limit, and the textures are tied to an avatar.

  I'm perfectly happy to kick the can down the road on figuring out how to create persistent baked textures which would remain in-world separate from the avatar who owns them.

Chellynne Bailey commented at 2018-04-19T23:11:48Z, updated at 2018-04-19T23:12:03Z

Did yall miss the bit where I said it'd appear in the appearance tab for removal? xD As far as removing textures, while I'm not opposed to there being a scripted way to do it, that sounds rather tricky. Seems like something that'd be easier to simply have the user do in the appearance tab. Then again, I'm sure the RLV folks would like to be able to remove items...

What if we did this:
llAddToBake(string Name, key UUID, key BakeUUID, integer Location);
Where name is the name of the item. This would be handy for instances where you want to replace textures as well and would allow a
llClearBake(string Name); that could also be used to remove items that are worn.

Mel Vanbeeck commented at 2018-04-19T23:24:57Z

I think for any mesh body system if you're going to add stuff via script you'll want to be able to remove that same stuff via script as well (or edit the parameters of that layer after it is worn, like changing tint, or opacity). In fact, it may be good to go a step further and let scripts remove the system layer items worn out of inventory RLV style. What I like to avoid is any situation where you must use two or more different systems to manage one feature.

Chellynne Bailey commented at 2018-04-19T23:35:04Z

Yeah, I think you're right Mel, I've updated the OP to add an "ItemName" to the basic requested API. Both to designate what will appear in the Appearance tab, but also so API commands can be built using it to designate which item to remove or replace.

Chellynne Bailey commented at 2018-04-19T23:38:03Z, updated at 2018-04-19T23:48:34Z

"What happens when two different HUDS compete for the same stack-space?"
One will hit the stack first, and then the other will hit and be inserted right below it. Nothing ever happens at the same instance. But yes, all attempts at removal functions will need to reference either the ItemName or it's UUID I think. Trying to remove by layer number will be problematic.

"well exactly how many items can I add to a stack before I hit a limiter? Does this count towards the user's total "worn items" count? Should it?
I think it should.. but that could add up fast. Ideally, multiple textures would be able to be associated with a single Item Name as long as they each use a different bake. All those items would exist in the same spot on the stack, and would be cleared all at once when a clear function is used.

"Regarding griefing, I would just say that at least initially baked textures all apply to the 62 worn item limit, and the textures are tied to an avatar."
I agree

Chellynne Bailey commented at 2018-04-20T01:00:54Z

What happens when you put the wrong texture on a Mesh Foot.

polysail commented at 2018-04-20T02:51:31Z, updated at 2018-04-20T02:54:04Z

With regard to the baked items counting towards your total worn items. The viewer would have to have some means of communicating that to the user, otherwise it's just silently failing. LSL functions don't do feedback very well. In fact pretty much every other LSL function silently fails once it's hit it's "cap" whatever that cap may be.

Communicating that via inventory is a challenge in it's own right as I outlined above.

Would it be feasible to have the baking service issue a data_server event that could be listened to about the state of the bake and the remaining "slots" on that avatar?

Chellynne Bailey commented at 2018-04-20T04:13:29Z

That's a good point... it's not a catastrophe if it fails silently, but I suppose it SHOULD throw an error or line item warning. "Reached Layer Limit. Remove some layers before adding more"

polysail commented at 2018-04-20T13:56:28Z, updated at 2018-04-20T14:02:30Z

The more that you add to this the more that it becomes clear to me that this is about scripted control of creating and removing temporary system layer based avatar attachments. That is a HUGE step forward, but it is definitely a step forwards. I think we should do it.

But the proposal needs to be re-framed under that structure in order to make any sense at all.

Edit: Explanation> The addition of "it'd be nice if it did alphas too" made it clear to me that we are now talking about just adding and removing inventory items on-the-fly. Which isn't a bad idea. We could even control it via experiences~ I think? We just need a function to "create temporary inventory item of classification [Skin, Tattoo, Clothing, Alpha] type, then apply to avatar inventory". Then it can be removed at any time~ with or without the LSL function. It's obvious it's contributing to the worn count, there's good feedback, so there's no mystery about what you're wearing.

Zuitina commented at 2018-04-20T17:58:04Z

I agree with Chellynne, we do need this before the bakes on mesh goes live. I'd hate to have to go back to a system avatar.

Chellynne Bailey commented at 2018-04-20T18:49:12Z, updated at 2018-04-20T19:12:26Z

Polysail: Yeah, that's exactly it. If you think something needs to be rephrased better, let me know. I'm not always the best at expressing ideas, so I'm definitely open to critiques. I don't know enough about the LL back end to suggest actually adding things to inventory. Only they can tell us if it'd be easier to add to inventory then to create a "virtual item". Or if there'd be any meaningful difference.

And yeah, the more I think about it, the more I think all of the above needs to happen, not just to save the market but improve it dramatically. We often get updates to do fancy new things, but this would actually give us some room to make all the fancy things simpler and more intuitive. Like, making skirts that automatically apply alphas/glitch pants. Entire outfits that could be an attachment instead of a bunch of pieces. People keep talking about wanting "Previews". If clothing is applied via script, people could make huds that give previews! This combined with the Bakes on Mesh could dramatically lower the learning curve and users trying to get dressed.

On another note, I was also chatting with someone the other night, and we came to the conclusion this might be simplified and easier to work if they depreciate Socks/Gloves/Tops/Jackets/Pants/Undies and convert those old items to Tattoo layers.

It'd cut down on the number of layers Creators making system layers need to make. (Yay, less work!)
It'd solve any questions about how things could be sorted. (currently, you can only sort things within their "layer")
It'd give LL less stuff to maintain. (yay for less system bloat!)

We'd lose out on things like sleeve lengths, and Jacket openings, but has anyone used those things in a long time? Normally I'd advocate keeping backward compatibility, but I think they've been irrelevant since... iunno... 2004?

What is everyone else's thoughts on this?

Vivian Rail commented at 2018-04-20T19:26:41Z

The socks, underpants, gloves, etc. are the only visual information visible for trying to manage your layers in inventory. Without that, you've only got the text attached to the object to figure out what sort of textures are actually in that package.

They certainly can't delete any of the old containers, but to be useful at all, a completely new set of simplified containers should definitely be added.
For example pants that go above the waist. Currently you have to pair pants with a shirt to get the upper UV in there (and did that little gap in the bake on the lower belly ever get fixed?). We don't need the options for loosening up the groin, flaring the cuffs, etc, shortening the legs, etc. We do need options for tint, transparency, and access to all 3 of the body maps. Likewise the jacket layer with its weird UV cropping is silly. Each layer needs a container that resembles the tattoo container.

And then getting back to this JIRA, yes the script needs to be able to pop a texture into the stack with precision, so a tattoo will definitely go jsut above the skin, but below the makeup, or a mask will go above the makeup, but below the undershirt, and so on. This is why I would like to see the "Location" integer have a nice broad range with well-defined value spans to target, as mentioned in the first comment. The extra space in a 0-100 range allows for new standards to be adopted as time goes by, e.g. we're always going to put eyeliner on the layer 14, so we know that if we want to put an eyeliner in and knock out any existing eyeliner, remove whatever is in layer 14 before adding the new eyeliner there. Freckles will always go in layer 4, etc.

Galathir Darkstone commented at 2018-04-20T20:31:42Z, updated at 2018-04-20T21:39:39Z

I completely agree on the old system layer clothing being deprecated, with tattoo layers taking the forefront there. It's more useful and more consistent. I hope that can happen. It also gives the same number of layers to potentially stack on all 3 Body areas. That would make Hair, eyes, and skirt the odd men out with only one layer, I think? But maybe it would be to confusing to add those to the tattoo layers as well?

On the whole of Bakes on Mesh, I am optimistically enthused about the potential improvement in quality of life for SLers in general. I personally don't care about resurrecting any old system skins or system layers, but I do definitely think that this would help to tackle some complications related to rigged mesh. The whole dueling 32bit textures on rigged mesh is tiresome, and has always felt like something that impacted the potential for rigged mesh in a significant way to me. Even to this day I see people asking what is going on when their hair ghosts/halos their clothing and tattoo layers... or even more ironically, their hairbase. BoM can... finally... give them a way to stop that from being an issue.

Add to that the potential to cut down on the complexity of mesh attachments? Brilliant. That's a wonderful thing for the whole grid. Less load on server resources... less load on video cards and RAM for the residents... Woot! High 5 team!

The one thing casting a shadow on this for me? The potential for it to absolutely WRECK a not only thriving, but vital industry in SL. Make no mistake, appliers for clothing and skins in SL are HUGE business. And they are HUGE portion of the market that actually engages the active, spending userbase. I don't think the import of this can be overstated, despite the surprising pushback from some folks who are clearly just not involved in what is a very active segment of the economy. To those people, I want to offer the following:

The applier market is an invert pyramid:

On the top of this pyramid, we have tens of thousands of residents, all happily using their appliers to put their favorite skins, tattoos, makeup, hairbases, scars, clothing, and more (some of which I could not describe in a non-adult setting) to their various mesh bodies, hands, feet, eyeballs, third eyes (and beyond), tails (yes there are tails that accept SL AVI UV textures), bosom augments, pregnancy bellies, extra limbs, and more. Powers that be bless the miracle that is SL, where there is a will, there is a way to create whatever niche items users might want to wear to customize their avatars and be whatever they can imagine!

Below them, we have the designers all cranking out a steady stream of Appliers. Even after all of Chelly's VERY HARD WORK to get as many people onboard with Omega as possible, (which, for the uninitiated, is a common applier system that can use relay HUDs to allow designers to create appliers that will work on many brands of mesh) there are still a LARGE number of meshes out there for which these designers create appliers. So not only to they create AN applier for a particular skin tone, they often have to create several. For some, this might just be about providing access to as many native applier formats as possible. For others, they want to tweak those applier textures so they work best on the various different products to be used on. For example, as popular as Slink feet are (and for good reason, I love Siddean's work), the toe area of Slink feet is not EXACTLY SL AVI UV. In addition to pulling from slightly outside the edge of the UV for SL AVI feet, we also do NOT want the toes painted on the feet for Slink feet... or any other mesh feet I'm aware of, since those painted on toenails are not going to be hidden under the mesh toenails. This means that the textures that work on the system avi for feet just don't for Slink. Further complicating this, Maitreya Feet are slightly different, as are Belleza feet. I think you can see where this is going. Now see that list up above that all the residents are using appliers on, and you'll begin to grasp how complex it is to make Appliers. And then consider that it's not uncommon for different options to be offered for skins and tattoos and clothing. HUD appliers can provide images so that one applier can have a multitude of buttons for the users to peruse and choose which option they want to use with relative ease. Compare that to the idea of having a stack of system layers in your inventory that are just words (since there is no preview system in SL). I belabor this point to try and relay the amount of work that has been ongoing in SL for YEARS by no small number of designers making appliers. Time, during which, the system avatar has become so under-utilized that even Linden Lab themselves opted to provide 100% mesh avatars for new users to use when they first become residents. That under-utilization meaning that a significant portion of these appliers... of solid content that resides in the inventory of thousands upon thousands of SL residents... that those appliers have no corresponding system layers. Search SLMP today for Omega Applier right now, and you see that there are 116,304 hits in Apparel and 32,012 hits in Components. Search Catwa Applier and get 25,259 hits in Components. Maitreya Applier gets you 95,024 hits in Apparel and 22,999 in components. Slink Applier gets 93,837 Apparel and 26,504 Component hits. Check LAQ, Lelutka, Gianni, Belleza, etc. The list goes on. There is surely some overlap in listings, but it illustrates the number of applier products involved in the SLMP that this tier of the pyramid has created... and while I can't put numbers to how many of those appliers don't have System skins, any conservative estimate puts the total at thousands. Probably tens of. Again... belaboring the point... so I'll move on.

At the bottom of this pyramid, you have the Mesh Makers. These are the people who decide on the applier format their mesh will use. Or not use. If Bakes on Mesh is launched with the "We'll get it out now and figure out how to insert UUIDs later" attitude, these are the people who can decide, "Wow! I'm going to peel off those onion layers and drop the Complexity on my mesh, and make my life MUCH easier!" And, I might add, that's pretty arguably a good decision on their part, for many reasons. And when their customers come to them and say "Why don't these appliers work on your mesh anymore?" They will almost certainly say, "That designer needs to update their applier for Bakes on Mesh." And who pays the price for that decision? Who gets buried under the expected workload to take thousands upon thousands of textures and drop them into system layers, using, I might add, a UI that was clearly never meant to expedite the process enmasse? The ones who put countless hours into setting up appliers in the first place.

Now, just realistically speaking, a lot of those appliers are NOT going to get moved onto system layers. That's a tremendous amount of update work. Work that will yield much less new income as an update, and work that will eat up time that would have otherwise been spent making new items that would generate new income. That will leave more than a few end users with purchases that are suddenly deprecated. It's going to mean frustration all around.

Is any of that a reason not to proceed with Bakes on Mesh? I don't think so... but I do think it is a reason to make every attempt to find a way to keep these appliers compatible with the BoM change. All that would take is a way to insert (and thus, necessarily, remove) textures into (from) the bake stack via script. I know I used a lot of words to get to the point here, but I really do NOT think it can be overstated how important this is to a large number of residents, even if they don't yet understand how it could impact them. Traditionally, LL has been against breaking existing content. The current path might not break content, but it certainly would lead to it's demise just as surely. I hope we can find a solution for Chelly's suggestion in this Jira that will eliminate the bulk of that potentiality.

[edit: ]

Mel Vanbeeck commented at 2018-04-20T21:14:47Z

Things like the hair texture and the skirt texture should be fully deprecated. There is absolutely no use for either of those containers in the present day. In fact I would go so far as to say the hair and skirt mesh should be deleted from the base avatar. There is no need to try baking several skirts together either. If someone is using a mesh skirt, they'll just put the proper texture right on it or use an applier. It's a waste of resources to pass it through the bake service. The hair mesh in particular causes problems when people wearing modern avatars haven't scaled it down to hide inside the skull and/or properly alpha map it out of existence. Those channels can happily be re-assigned to the second arm in the new clothing containers. This relates to Siddean's JIRA, though, but I would say new clothing containers is key to both of these issues. Script access to the bake service requires the bake service to be nicely organized.

Skirt could be re-assigned to left arm, and hair could be designated as general purpose. Delete those meshes off the base avatar entirely, and you've got something far more useful.

Chellynne Bailey commented at 2018-04-20T21:16:19Z, updated at 2018-04-20T21:16:54Z

And then getting back to this JIRA, yes the script needs to be able to pop a texture into the stack with precision, so a tattoo will definitely go jsut above the skin, but below the makeup, or a mask will go above the makeup, but below the undershirt, and so on. This is why I would like to see the "Location" integer have a nice broad range with well-defined value spans to target, as mentioned in the first comment. The extra space in a 0-100 range allows for new standards to be adopted as time goes by, e.g. we're always going to put eyeliner on the layer 14, so we know that if we want to put an eyeliner in and knock out any existing eyeliner, remove whatever is in layer 14 before adding the new eyeliner there. Freckles will always go in layer 4, etc.

Well, just above the skin is easy. 1 would always do that. The top of the stack would also be easy. -1 would do that.
All the ranges in between... I can't think of a way to do that without creating limitations. And I'm not convinced there needs to be a ton of precision beyond that. If something doesn't land exactly where you hope, then you can rearrange it in Appearance tab.

As for the Integer range, Integers are any value from −2,147,483,648 and +2,147,483,647. So we'll have plenty of room to work with, but I'm not actually sure what you're suggesting. The Location Integer I have listed is the actual location in the stack. It'd never go above 64, and each time you inserted a texture, all the textures above it would go up 1. So it's not going to be useful to try and set addresses. I get the impulse to try and get things to go in the right spot.. but I fear if we try to control that too much we'll end up in the same boat we are now with Pants/Undies/Jacket/etc where people have to make multiple versions just because these things can't be rearranged.

Mel Vanbeeck commented at 2018-04-20T21:47:15Z, updated at 2018-04-20T23:17:02Z

Building on Galathir's point about the number of appliers out there — that massive pile of appliers will not go away. They will continue to be available all over the grid, and people will have to learn what is compatible and what isn't. Not just that, but millions of dollars worth of those same appliers are sitting in the inventories of our customers. So, with the prospect of baked textures coming around, we have to choose which standards we will support going forward — but we really don't have a choice. At least initially, we have to suppor both. If we just released an update and switched to only supported baked textures, saying that this is the way going forward, that would be a major problem for all of our customers.

To get around this, we wind up having to develop two different versions of the head - one which is lean and light and just supports baked textures, and then another which puts onion skins on top of the baked textures - and I can guarantee almost everyone would immediately start wearing the version which supports both (since nobody on the grid owns a 1024x10424 system skin to wear in the first place, so they would have to go out and buy one if their head didn't come with one that sutis them), and they would probably never switch over to the baked only version. For us, this doubles the work involved with any system updates. You wouldn't believe how complicated setting up an onion skinned head is. It is the kind of thing that you plan, and then you crash into SL limitations, then re-plan, make compromises, and repeat the process. Not to mention the HUD layout for these two head versions would differ substantially. Customers then have the additional confusion while shopping of having to search for the type of product which is compatible with their preferred head version, because they can no longer just say "oh, this is made for LeLutka, it must work with my LeLutka head." They have to confirm what they're looking at is an applier, or a system clothing object, and that's specifically what they want, etc.

If the script has access to the baking service, we can just go straight to bake only mesh - just one version to develop and maintain, and the scripts will handle all the existing appliers elegantly and seamlessly, the system clothing meshes in nicely, and nobody has anything to complain about. People update to the lighter, easier to render mesh, and from a customer's perspective everything just continues to work perfectly. There's no need to absorb a new protocol or workflow for getting textures onto your body. Then designers can choose whatever suits them best between making nicely organized appliers with fantastic visual representations of what's being applied, or they can go retro and build their content on clothing layer objects and folder them up.

Mel Vanbeeck commented at 2018-04-20T22:05:39Z, updated at 2018-04-20T22:10:53Z

For "Location" (target layer) in the stack, if the stack is as you are describing where you have the top layer constantly moving to a higher value as things are added, and you are never quite certain what sort of things are at what values, there is no good way to manage the stack via script. Maybe you can query the stack size and it tells you there are 5 textures in the stack. So what is on the third layer? You want to add an eyeshadow, which should go above tattoo, but below eyeliner. Is there just one tattoo, or are there two? Are there freckles? The eyeshadow might need to go between 4 and 5, or it might need to go between 3 and 4 if the eyeliner is on 4 and the lipstick is on 5. If this isn't well-defined, the script will just be forced to slap stuff on the top or the bottom of the stack regardless of where it belongs, then the user will have to open up a separate panel in their client to reorganize the stack.

If you set up the stack to be a sort of address range, where you can always know that the jacket layer is going to be set at an altitude of 80+, and that shirts belong in the 70-79 range, then you've got no problem making sure that your script-applied shirt winds up underneath jackets, and above undershirts, or your eyeshadow winds up above tattoos, but below eyeliners and masks, because there is a standard for at altitude those entities reside at.

And then for things being installed at the same altitude or stratum, they can either knock the other out, or sort that the one applied later goes just above the existing texture.

Then regarding having to make different versions of an item in different container types for the system clothing, that's simple. The container type should determine where in the stack it goes by default, but people should be able to reorganize that to their liking using the outfit editor. If they want to wear their underpants over their pants, that should just be a drag away. By default, though, the underpants should go under pants.

polysail commented at 2018-04-20T22:12:10Z, updated at 2018-04-20T22:32:28Z

The nuances of where each temporarily created inventory item gets "stuck" isn't necessarily something we need to solve computationally. The users are usually pretty adept at either noticing that something got applied incorrectly ~ or are indifferent enough to not care that their eyebrows are being tinted by their eyeshadow. I think you could create a temp-attach-inventory item that obeys the same rules as existing clothing layers~ and have that be a sufficient enough functionality to be useful.

Additionally there is literally no way for a script to "know" what the desired "sub-layer" of an attachment is~ as I can think of no reasonable way for it to be "aware" of what the content is on the other layers. Especially since ~ well SL.... user generated content is user generated content.

Galathir Darkstone commented at 2018-04-20T22:21:31Z

Thanks for adding your thoughts to that, Mel. It certainly had occurred to me that the existing pool of appliers would be something you'd have to consider, but I hadn't thought it through to the point of 'what would customers do with both choices.' I think you nailed it for sure. And that would kind of blunt the positive impact on resource consumption (rendering cost... asset server workload... etc).

Chellynne Bailey commented at 2018-04-21T01:46:38Z, updated at 2018-04-21T01:47:57Z

Yeah, I didn't put the integer in there for precise targetting. It'll let you put things on top, bottom, or take a wild swing to get it somewhere in the middle. (Check the number of layers, aim for halfway through!) . If you're using a converter, you might also set it up so that new items always land on top of your favorite tattoos and never under them. But other then that, I don't really think precise targetting is needed or possible. Today if you put on more then one tattoo you have to rearrange it, so this is no different. And if we talk them into depreciating non-tattoo clothing layers, there will be even more sorting that will need to be done.

The big issue I think is... if we put any sort of sorting indication that is not what is already physically in the stack, what decides how System layers are sorted?

Lets say we go simple and did:

0- Skins
1-10 - Tattoos
11-20 - Body Marks
21-30 - Clothing

That'll work for everything added by script, but what about the System Layers? Where do they stack in that?
Now, we could use Pants/Undies/Jacket as indicators. But really.. we should be depreciating those items. They make a ton more work for anyone who wants to make system layers. And when you want to get nitty gritty, like on the face. You want Eyeshadow to appear UNDER brows, but both those items would be on a tattoo layer.

Honestly, how to rearrange layers is a skill all SLrs should have, and really isn't a huge burden.

polysail commented at 2018-04-21T02:21:44Z

There should be integers per-layer. Clothing always appears atop tattoo, tattoo overtop skin. We're not losing that functionality.

polysail commented at 2018-04-21T02:32:27Z, updated at 2018-04-21T02:35:49Z

Just to spell out how I'm understanding we want this process to work step by-step is:

Step 1: LSL Function has a cache of texture UUID's that it might want to use. ( standard applier UUID directory ).
Step 2: An interpreter script prompts the user "Do you want to apply this to [ Skin, Tattoo, Underwear, Clothing , Eyeball , (skirt?) ] Layer?
Step 3: User selects the correct choice and the script sends this information off to the server.
Step 4: Server sends back to the user a Temp_attach (Experience?) Keyed item that is that texture UUID wrapped within a temporary inventory object of that classification ( Skin , Tatt , Underwear , Clothing ) etc. as a temporary asset with a "stack preference" that the viewer will then keep track of. IE > Insert into the bottom of "Tattoo layers" "Insert into the top of clothing Layers"
Step 5: This temporary asset is now attached to the avatar until an LSL command or an inventory action removes it.
Step 6: The baking service recognizes the avatar has a new attached texture and does it's own thing naturally.

Step 7: The user decides they no longer wish to wear said item and either manually removes it~ or removes it via another LSL scripted call from a HUD type entity. This item is now gone forever, until another call is made to create a similar object.

Mel Vanbeeck commented at 2018-04-21T02:33:44Z

Of course system layers would go in at predefined layer values. In your example, Undershirt would go 21, shirt 25, jacket 28, or something like that. That would be fine with me, but I don't see any reason that keeping the numbers small helps anything. It's much easier to remember undershirt 50, shirt 60, jacket 70, or something like that. Of course the values would be in the LSL wiki, but better if you don't have to check the reference every time.

polysail commented at 2018-04-21T02:48:13Z

It's my understanding that even with the present inventory system each layer ( IE Skin , Tattoo , Underwear , Clothing , Jacket ) has it's own unique stack associated with it. So you can have underwear 1 2 3 4 5 which always rests overtop tattoo 1 2 3 , which always is on top of skin 1. The total height of the stack overall is largely irrelevant.

As a bare minimum you need a "insert on top of stack class " function.
A nicety would be a corresponding "insert on bottom of class inventory stack" function in addition to that. But I don't see this as critical.

Chellynne Bailey commented at 2018-04-21T05:53:40Z, updated at 2018-04-21T06:00:33Z

About Polys Step-by-Step

2. That'll depend on the scriptor. I for one hate applier prompts and will do absolutely anything I can to avoid them. The required info is already in the appliers, so I'll just be fowarding skins to skins, and everything else to the appropriate alpha stack.

3. There's no real reason to limit this to experience users. There's no real griefing opertunity other then writing "Dork" on someones forhead. Lets not complicate it for folks with an unnessessary permission call.

4. I do not know enough about SLs inventory system to know if this would be easier or harder then emulating an item. My suspicion is that creating an item would be harder then emulating one, but ultimately, it would look the same on our end. It's just something the Lindens will have to figure out. Whats easier, dealing with their inventory beast, or their baking beast.

Otherwise, yip.

=============================================================================
As for Clothing types not going away... I don't know if they'll be going away NOW, but if not, they should be going away LATER. Expecially if people still want personalized icons. Their Clothing layers NEED to be simplified.

Plus if System Layers are going to be a thing now, we can cut peoples boxing time by 1/3-1/5 just by eliminating the need for duplicate layers.

Regardless, anything we do to reference these different types, we need to make sure it won't make it harder to remove the unneeded clothing layer types. Or break when it is removed. So I'm really loath to insert directly into a class type that might eventually stop existing.

So, how about this:
llFindTopofClass(string className);
Use this to find the location that is needed. If Classes go poof, it'll end up returning the top of the pile. Annoying, but not script breaking.

Also, if you're right about the Stacks being separate entities, we might need to wrangle a Linden to clarify what would work easier for their existing set up. They may not actually have a real attachment list. It might be a list of lists, in which case you're right, we'll need to recalibrate. Lets make sure it's brought up at the next meeting.

Mel Vanbeeck commented at 2018-04-21T22:36:25Z

My concern is specifically with heads, where there is just the tattoo layer on top of skin in the existing structure. The body you can sort things pretty well with the 4 available layers. Makeup has a definite order things need to go in, though. You can't have your eyeshadow on top of your eyebrows, etc. Skin and makeup is really the primary and best use for baking textures, so this should work extremely well for makeup. Skipping a step in the function design here could mean zillions of extra clicks (and rebakes) across the grid as people reorganize their faces every single time they try a different makeup.

It would just be insane to design this system in the laziest way possible to make things easy on the Lindens or on scripters, or whatever. It needs to be easy for users so that things can generally just work for a customer without them having to think about it or learn a complex system structure. If we have a designated slot for eyeshadow, which is an extremely common product in SL, then there's no question whether your eyeshadow is going to land on the right stratum of your facial stack. It just goes there on the first click, and we move on with our day. Either the system needs to have all those layers defined from the start, or it needs to be flexible enough that they can be defined by the design community as time goes by.

polysail commented at 2018-04-21T23:36:28Z

You make a valid point. What new layers ~ aka stack categories would you recommend adding? Eyeshadow. Eyebrows. Lip cover. Blush. ?

Chellynne Bailey commented at 2018-04-22T07:02:28Z, updated at 2018-04-22T07:40:32Z

Yeah, I've been thinking about it all day, and you're right dag nab it. Frankly, I'm trying to keep the request as simple as possible, to make sure it gets done, but I think we DO need to specify the class. Not because of heads, but for bodies. Makeup doesn't overlap a ton. (there's a reason people got away with a single layer of makeup so long). So I don't see a dire need there. But hey, you are the head guy, and if we're doing it for bodies, might as well do it for heads. Symmetry = good. So I'll be updating the Jira here in a second.

Edit: Done, also, anyone got some nicely done Applier examples I can steal screenshots of to put in the examples? Something that'll wow these lindens? chuckles

polysail commented at 2018-04-22T08:13:19Z

I feel compelled to point out the obvious here though~ despite how unpopular that might make me: absolutely none of these functionalities are in any way tied to bakes on mesh in its current project scope. That is to say~ that there is nothing here that requires an actual change to the way that the bakes on mesh project currently is defined. Bakes on mesh~ as it is currently defined is "take the composite avatar texture slots and stick them somewhere." This project is a follow on project that is required in order to make bakes on mesh practical for general use~ but this defined functionality is dependent upon bakes on mesh ~ but bakes on mesh isn't dependant upon it. There's no reason I see at this point to not let bakes on mesh go forwards~ with this as the immediate follow on project. Just put it at the top of the project queue~ because it is that important for the removal of onion avatars. But this is: thoroughly a follow on project. Bakes on mesh can continue forward without this~ just onion avatars will need to remain for backwards compatibility with appliers until this project is live as well.

Galathir Darkstone commented at 2018-04-22T08:35:18Z

Poly: If you don't see any reason to keep Bakes on Mesh in beta while this is sorted out, then you either A) Just completely disagree with what we've said about the subject, or B) Are not READING what we have said on the subject. There ARE valid reasons for holding the project from full live launch until this is resolved. You are just flat wrong, in my opinion. Whether BoM requires this to be solved to work is not the only factor here. This is a fundamental change that effects a HUGE number of products and customers... and if it's just rolled out as is, there could be dramatic negative backlash.

polysail commented at 2018-04-22T08:54:42Z, updated at 2018-04-22T08:59:48Z

What is the fiscal reason that mesh body makers have to cease using multi-mesh onion avatars and cease to support appliers? Mesh body designers want their product to appeal to the most people that they can~ as long as onion avatars provide a functionally better product for the end user than a BOM version does ~ onion avatars will continue to exist~ along with appliers. The two technologies don't play terribly nice together~ but they are by no means mutually exclusive either. I agree there is an urgent need for this project. I do not agree that this project has anything within its scope that redefines the parameters of the existing BOM project scope. I could be wrong~ but if I am~ please cite an example? To clarify~ I do not see anything preventing a BOM skin layer with applier onion layers over top~ in fact ~ until this project is completed, that is what I fully expect to see.

Chellynne Bailey commented at 2018-04-22T19:16:15Z

I don't think you understand the burden creating and managing Alpha HUDs and Layers puts on Mesh Makers. I've seen MANY nice looking meshes hit a wall and fail just because the Mesh Maker suddenly realized what would be required to get it set up with Layers and Alphas and just gave up. Didn't even try to move forward.

The trueth is, no matter how broken BoM is released, Mesh makers WILL make the leap. Even if it costs them a few sales. Because they'll be able to churn out many more products, and make many more improvements with the time saved. For some there is an even more direct financial reason, as they have profit shares with scriptors who take 10-15% to maintain these Alpha HUD monstrosities. Once Bakes on Mesh hits, those mesh makers are likely to start looking for cheaper options.

Frankly, it only takes one Big Mesh maker to make that leap and the rest will follow. And I've already had one large mesh maker confirm to me that they will be removing their layers. They rightfully see that keeping the layers will not be worth their time.

Mel Vanbeeck commented at 2018-04-22T20:04:33Z, updated at 2018-04-22T20:09:03Z

There are many businesses out there whose entire inventory is appliers which support one or several mesh body parts. How is it ok for LL to create a new standard which makes their entire inventory obsolete as soon as it is adopted by the mesh creators - just because they don't feel like fully developing the feature? To continue to be relevant, they have to update their entire inventory just to survive however many months until the Lindens decide to tackle the rest of the job, at which point all the work that went into changing their product stack into a new format becomes pointless, because appliers work again? Not every business in SL is doing it as a full-time job.

And the same thing for the customers - their entire inventory is obsolete (because their chosen mesh body decided not to support onion skins in their next update), so they have to buy all new skins or makeups, then X months later their old inventory becomes usable again... because LL found time to finish the feature set. Confusing?

If the point of this feature is to make sure that everyone is using it for everything so that the avatars of the grid are easier to render, then there needs to be zero drawbacks to adopting it. Even with these changes, unless materials are included in the baking service there is one massive drawback to baking clothing onto a skin. Without these script access changes, mesh designers have to look into supporting bakes and onion skins together, which is good for consumers and supporting businesses in the near term, but completely defeats the purpose of pushing out the bake service update half-done. The grid will still be full of onion skinned avatars.

In fact the result is even more confusing, because customers then have to learn the ins and outs of mixing applier-based onion skins and system-based baked skins, only to have that knowledge become pointless as soon as the job is finished. Who is going to teach them all this stuff? Who is going to teach the new users who have absolutely no knowledge of the evolution of avatar texturing? This is the perspective that LL should be thinking from.

jadenart commented at 2018-04-22T20:13:06Z

I am with Chellynne regarding her last comment. Second bakes on mesh is out, i plan to remove all unneeded mesh layers, that was for me and im sure for many other most hated part of head making.

Galathir Darkstone commented at 2018-04-22T20:52:43Z

@poly inre: "What is the fiscal reason that mesh body makers have to cease using multi-mesh onion avatars and cease to support appliers?"

You clearly have no idea how much work is involved in setting up the onion layers... nor the added complications if you have to change the mesh for some reason... nor how many support inquiries come from SL's limitations when it comes to dealing with clashing 32bit textures on those layers, among other things.

I will simply defer to JadenArt's telltale comment, rather than enter into another lengthy monologue.

polysail commented at 2018-04-24T01:16:06Z, updated at 2018-04-24T01:17:32Z

Outfit folders would be missing the temporarily applied textures unless some mechanism was put in place to recreate temporary assets. It's not a show stopper~ a little creative scripting can create an inventory item to stick into an outfit folder to automatically create and apply new temporary assets~ same as existing HUD save slots.

Chellynne Bailey commented at 2018-04-24T03:54:58Z, updated at 2018-04-24T04:01:12Z

Yeah, obviously, there's going to have to be some sort of storage solution added to hold the emulated layers once they are created, or they'd disappear on relog or adding another item. Either a invisible temp folder, or some other creative solution Lindens come up with. But that's delving deeper then we really need to. Lindens know their System. They'll be the best ones to figure out the best way to meet the needs set forth. We can talk all day about how to make things work, and try and give them ideas for how to do it, but ultimately, but we're not the ones who have to put hammer to nail here.

polysail commented at 2018-04-24T06:02:24Z

Coming up with a plausible hammer to nail strategy is the entire point of this exercise~ otherwise we're just sitting here praying and wafting incense hoping water falls from the sky~ In order for a JIRA to get anywhere we kind of have to iron out those pesky details. What do we need as a community? Do the temp assets have to be persistent through relog? Or will the mesh body have an "on rez" event to recreate them on demand? Is either permutation okay~? It seems like persistent until detachment would be ideal~ but that is an entirely new classification of temporary asset.

Chellynne Bailey commented at 2018-04-24T19:36:25Z, updated at 2018-04-24T21:07:53Z

If were going to make this symmetric with system layers, which is the goal, well need the layers to persist through two of and also in outfits. So yeah, its going to need to be stored somewhere. Either by modifying the outfit and currently worn folders to let them live there or by creating a new temp folder for them to live in untill they aren't being used anymore.

Still, as much as I'm trying to not nail down every detail for them, this all has been great feedback, and I've again, amended the proposal, trying to work out the kinks in how the API should work and make it more clear that it'd be creating a new item.