Bakes on Mesh Feedback Thread

[Julia Blackwood]

23 hours ago, Vir Linden said:

I'm not sure why it's not responding. One recent change with the SL viewer is the addition of a separate launcher process, so instead of just starting the viewer, you're really starting a launcher, which then does things like checking for updates, handling crashes, etc, and is responsible for starting the actual viewer executable. So if you see something about python (a programming language used by the launcher), or Second Life Launcher, that's what it's about.

Re: the crash, you may want to retry and just wait a bit while everything gets loaded and cached. If that all works correctly, you may get better performance the next time you log in with that account. If it crashes consistently, please try with the SL default viewer, and then file a JIRA to let us know about the problem. Please give any details like "only crashes with bakes on mesh viewer" or "crashes consistently with both viewers".

Here's a screenshot. Obviously I'm using a Mac. Thought this may be of help. Thanks for your response, Vir!

[Chellynne Bailey]

On 4/18/2018 at 4:29 AM, Theresa Tennyson said:

Okay -- why? I'm honestly curious.

I can't speak for Les, but I can think of two BIG reasons

1. Backward compatibility for existing appliers. (Something anyone who makes or provides appliers should want. )
2. Because System layers are sllooowwwww.  There's a reason why people have started making items "for mesh only". Appliers, once you've set them up how you like, take much less time to box. It's a lot faster to copy and paste a bunch of UUIDs into a hud you reuse then to open up and insert textures into multiple system layer objects and rename each and every one. Some folks have made it even faster by creating scripts they use to extract UUID lists when they drop all their textures into a prim.  
   
   Frankly, texture creators will be much better off if we can get our hands on API to insert/remove from the stack. Especially folks who do alot of options. (I've seen a lingerie maker put 20+ textures in a hud for a single color of their lingerie item.)

[Nalates Urriah]

This is the video of the Content Creators' UG Meeting 4/19. At the start they are having voice problems.

 

[Henri Beauchamp]

On 4/18/2018 at 9:26 PM, Vir Linden said:

Prevent baked textures on non-mesh attachments: I'm not sure if we would want that limitation. How about something like a rigid piece of armor, which might be defined in the same UV space as the system avatar, and where you might want to apply a texture derived from a clothing item? I'd be curious to hear if anyone plans to use bakes on non-rigged meshes.

I think you misunderstood me: I meant, non-mesh attachments (SL-prim based, and possibly sculpties) and I was not speaking about non-rigged mesh ones...

There is simply no possible way for a SL prim based attachment to bear an UV map matching the SL avatar's, so it makes using avatar bakes on them rather (totally, IMHO) pointless. The sculpties case could be advocated, but I personally doubt a sculpty could be designed which resulting mesh would natively map to any of the avatar's UV maps...

Also, I see no point in allowing to use avatar bakes on HUDs.

 

On 4/18/2018 at 9:26 PM, Vir Linden said:

Disabling auto-hiding, or more generally giving the user more control over what gets hidden, has also been discussed. No final plan on that yet.

I think it's a must-have: think of your armor example, that won't cover hands and neck, but that could use your baked upper avatar texture: you'd need a custom Alpha layer for it and won't want the upper avatar body to be auto-hidden. Plus, it's super easy to implement (simply doubling the pseudo texture UUIDs by adding a set for non-auto-hiding bakes).

[Imokon Neox]

Maybe because this is all so overwhelming since I just discovered this thread and my skill level is not up to par, but I feel like I missed something about how normal maps/ material textures will be combined.

Normal maps can't just be flattened onto each other without adjusting each color channel. It's terrifying thinking when now we have materials to enable pore effects on skin and tattoos and what not plus on clothing.

Also the default SL UVs were very distorted/ low resolution in regards to tris density how is this going to translate to all the random custom tris on heads and bodies etc that have better weighting on joints or just curvy edges in general?

I haven't worked as much with system layers but I am familiar with retopology from 'organic' mesh to low poly meshes and I'm really not getting good vibes. Retopo is best with quads, but here we already have odd tris on the UVs.

Example: Say I have a bloody tattoo and another one with dirt and a bandaid...how will I know the bandaid will fall on top? Also If I was the designer of this I would use materials/ normal maps because that's what adds definition on the bandaid because you know the devil is in the details. Bandaids, jeans pockets, certain fabric textures.. Bandaid is on the knee.. lot's of distortion on system avatars but not on my Maitreya Lara. 

Also... as I am sitting here waiting for my software to finish baking on my products (30ish min for sculpted organic shapes)..I'm thinking...how long will this mish baking take especially if say someone really does want to combine layers? How will you order the bakes? Going through a zillion outfits deciding what I want to wear?

Edited April 22, 2018 by Imokon Neox
more thoughts...

[Theresa Tennyson]

5 hours ago, Imokon Neox said:

Maybe because this is all so overwhelming since I just discovered this thread and my skill level is not up to par, but I feel like I missed something about how normal maps/ material textures will be combined.

Normal maps can't just be flattened onto each other without adjusting each color channel. It's terrifying thinking when now we have materials to enable pore effects on skin and tattoos and what not plus on clothing.

Normal maps won't be baked together at this point in the project for a number of reasons, including the ones you state.

Also the default SL UVs were very distorted/ low resolution in regards to tris density how is this going to translate to all the random custom tris on heads and bodies etc that have better weighting on joints or just curvy edges in general?

I haven't worked as much with system layers but I am familiar with retopology from 'organic' mesh to low poly meshes and I'm really not getting good vibes. Retopo is best with quads, but here we already have odd tris on the UVs.

Example: Say I have a bloody tattoo and another one with dirt and a bandaid...how will I know the bandaid will fall on top? Also If I was the designer of this I would use materials/ normal maps because that's what adds definition on the bandaid because you know the devil is in the details. Bandaids, jeans pockets, certain fabric textures.. Bandaid is on the knee.. lot's of distortion on system avatars but not on my Maitreya Lara. 

The system avatar and the Maitreya avatar are probably using exactly the same texture. All the baking service does is provide a texture. How it's mapped is dependent on the mesh itself. The quality of mapping and triangle locations on the default avatar have nothing to do with another mesh that happens to use the same texture. Also, the baking service is perfectly capable of combining textures that are based on a completely different layout, if the avatar wears assets that are based on that layout and not on the default Second Life avatar.

Also... as I am sitting here waiting for my software to finish baking on my products (30ish min for sculpted organic shapes)..I'm thinking...how long will this mish baking take especially if say someone really does want to combine layers? How will you order the bakes? Going through a zillion outfits deciding what I want to wear?

This isn't really new. It's what Second Life has been doing since 2003. What the Second Life bake does is combine multiple layered textures and send them as a single composite texture. It takes a few seconds.

 

[Theresa Tennyson]

On 4/19/2018 at 3:49 PM, Chellynne Bailey said:

I can't speak for Les, but I can think of two BIG reasons

1. Backward compatibility for existing appliers. (Something anyone who makes or provides appliers should want. )
2. Because System layers are sllooowwwww.  There's a reason why people have started making items "for mesh only". Appliers, once you've set them up how you like, take much less time to box. It's a lot faster to copy and paste a bunch of UUIDs into a hud you reuse then to open up and insert textures into multiple system layer objects and rename each and every one. Some folks have made it even faster by creating scripts they use to extract UUID lists when they drop all their textures into a prim.  
3. 
   Frankly, texture creators will be much better off if we can get our hands on API to insert/remove from the stack. Especially folks who do alot of options. (I've seen a lingerie maker put 20+ textures in a hud for a single color of their lingerie item.)

There's a fallacy here. I realize that you're in the applier business but everyone else uses appliers to do something else. In fact, many people now using appliers were using system assets to do the same thing before. Backwards compatibility for appliers is just as much or as little of a concern as backwards compatibility for system assets was when mesh bodies and heads were introduced, and people will still own and be able to use products that use current appliers just as I was able to continue to use the system avatar for most of my purposes.

The speed issue is something I've asked to be addressed by allowing wearable assets to be made by script. https://jira.secondlife.com/browse/BUG-216140

As far as needing 20+ textures in a HUD, how much of that is because something like a lingerie set needs to provide individual textures for every possible combination? With system assets each piece can be provided individually and the end user can decide how to arrange them.

Edited April 22, 2018 by Theresa Tennyson

[Blush Bravin]

I have such a love/hate relationship with appliers. To be honest, when I first heard of the Bakes on Mesh project, I jumped for joy because I thought finally we can get rid of appliers. Yes, I understand it will be some work to add system layers to my applier only products, but I'm willing to do it if it means I don't have to deal with making appliers ever again!

[Athena Mornington]

To me, https://jira.secondlife.com/browse/BUG-216137? is essential at the launch of this new feature, not as an add-on at a later date. Here's an example why:

Let's say I have an applier HUD with 30 Shirts on it. Top and bottom. With the way that appliers work, that means I can use the applier on tattoo/bra/top & tattoo/undies/pants layer at my discretion. And, the long sleeves extend onto the hands and can double as a glove layer if wanted. So to convert that back to system layers, the creator would have to make 30 Shirts, 30 Pants, 30 Undershirts, 30 Underpants, 30 gloves - and rename them all to reflect the color. So, an inventory folder that currently holds 1 HUD would expand to a folder holding 30x5 =150 system layers. Ok, if Shirts/Undershirts or Pants/Underpants don't need to be doubled because the user can target where they want it to go and can juggle if it is on top or beneath something else, that would take the number down to 30x3=90 system layers. And the creator would have to do that for every single multi-item HUD they have, rename, rebox, update listings, update vendor systems, everything. Meanwhile, they are going to be handling an onslaught of questions from customers about how to use this or that, or why doesn't this work? Applier creators not only create the appliers for the mesh bodies, but they are usually the front line of support when it comes to mesh bodies because a customer always believes the issue is the applier, not the way a mesh body works with its own HUD.

Maybe I don't understand this feature properly, but if the above is a correct assumption, then IMHO, that's just not workable.

[Theresa Tennyson]

1 hour ago, Athena Mornington said:

To me, https://jira.secondlife.com/browse/BUG-216137? is essential at the launch of this new feature, not as an add-on at a later date. Here's an example why:

Let's say I have an applier HUD with 30 Shirts on it. Top and bottom. With the way that appliers work, that means I can use the applier on tattoo/bra/top & tattoo/undies/pants layer at my discretion. And, the long sleeves extend onto the hands and can double as a glove layer if wanted. So to convert that back to system layers, the creator would have to make 30 Shirts, 30 Pants, 30 Undershirts, 30 Underpants, 30 gloves - and rename them all to reflect the color. So, an inventory folder that currently holds 1 HUD would expand to a folder holding 30x5 =150 system layers. Ok, if Shirts/Undershirts or Pants/Underpants don't need to be doubled because the user can target where they want it to go and can juggle if it is on top or beneath something else, that would take the number down to 30x3=90 system layers. And the creator would have to do that for every single multi-item HUD they have, rename, rebox, update listings, update vendor systems, everything. Meanwhile, they are going to be handling an onslaught of questions from customers about how to use this or that, or why doesn't this work? Applier creators not only create the appliers for the mesh bodies, but they are usually the front line of support when it comes to mesh bodies because a customer always believes the issue is the applier, not the way a mesh body works with its own HUD.

Maybe I don't understand this feature properly, but if the above is a correct assumption, then IMHO, that's just not workable.

Why'd you want to wear a shirt spray-painted to your skin? Bakes-on-mesh is not a good solution for clothing. (Whether applier clothing is a good solution in itself is another story.) I have never said that it is.

This is my spec for a day-zero avatar, using only features that are available right now and bakes-on-mesh in its current state (hands, feet and head separate as is the common practice):

Main body of avatar: a single 8-face mesh that supports bakes on mesh, used for skins, tattoos/body detailing and alpha masks to wear under mesh clothing, and a possibility of underwear/hosiery worn as layering. Put on using system assets. With 8 faces, you could have an upper body, lower body, dimensional nipples that can be turned off individually, a "crotch cover" that can be turned off and three additional faces for a choice of neck sizes, etc.

Clothing layer: a single 8-face mesh divided into 8 sections - right arm, left arm, front torso, back torso, front pelvis, back pelvis, left leg and right leg. All these faces could be turned on/off and textured individually (including materials) with appliers. This would let you simultaneously wear a bra-and-panty set, stockings and a one-arm tattoo, all from different makers and all with their own materials settings. The "three layers" of the typical mesh avatar is really a fiction because you can't reliably wear two alpha-blended layers on top of each other and alpha masking makes anything with complicated edges or transparency look like it was cut out by a six-year old with those little round-pointed scissors.

You'd have a complete avatar that can do 90% of what the current avatars can do using two meshes instead of 119 meshes like in a Maitreya Lara body. In some ways it would be more versatile. And if it doesn't work for you? You wouldn't have to use it. Just use your old one. Of course if people snicker at you in a couple years because you're still in pieces when everyone else has arrived that's your choice.

[Blush Bravin]

Without the hassle of having to use an applier, we can once again make outfits without having to save with an applier attached or make multiple copies of the body with the applier (skin, clothing, whatever) applied to the body.  As my alt, I am a moderator for the Maitreya Lara Friends Group so I am very much aware of the support that goes into helping people use their mesh bodies. The question of how do I save an outfit with an applier is a constant question and headache. 

Can't we just let appliers die? Bite the bullet, do some work, and move on. I hope that once day we will look back to using appliers the way we look back at using sculpts now. They were necessary at one time but aren't we glad we don't need them anymore!

[Nalates Urriah]

5 hours ago, Blush Bravin said:

Can't we just let appliers die? 

I feel you. But, until we know how materials are going to work with BoM I can't see Appliers becoming superfluous. 

The problem of Appliers and how outfits are stored is a PITA. I have 2014 and 2015 outfits that use appliers for the underwear or shirt layer. If I did not include the Applier HUD as part of the outfit or save a copy of the body with whatever applied it is a pain to update the outfit. As Slink and others upgrade bodies and heads a bulk inventory replace of the body or head is a problem.

Bodies and heads are often no-mod. So, the copies can't be renamed. So, the inventory's bulk replace will wipe out the 'Applier' modified versions. If our viewer considered the UUID in it's 'is this the same' decision it might be easier.

Finding the Applier is awkward as there is no way in the viewer UI to lookup the texture/applier by looking at the body.

Appliers have their problems. But, they allow the designer to handle applying materials.

[Julia Blackwood]

6 hours ago, Blush Bravin said:

Without the hassle of having to use an applier, we can once again make outfits without having to save with an applier attached or make multiple copies of the body with the applier (skin, clothing, whatever) applied to the body.  As my alt, I am a moderator for the Maitreya Lara Friends Group so I am very much aware of the support that goes into helping people use their mesh bodies. The question of how do I save an outfit with an applier is a constant question and headache. 

Can't we just let appliers die? Bite the bullet, do some work, and move on. I hope that once day we will look back to using appliers the way we look back at using sculpts now. They were necessary at one time but aren't we glad we don't need them anymore!

I totally agree..appliers were a way to temporarily cope until we had a better method. Hopefully that improvement is just around the corner

[Blush Bravin]

4 hours ago, Nalates Urriah said:

I feel you. But, until we know how materials are going to work with BoM I can't see Appliers becoming superfluous. 

The problem of Appliers and how outfits are stored is a PITA. I have 2014 and 2015 outfits that use appliers for the underwear or shirt layer. If I did not include the Applier HUD as part of the outfit or save a copy of the body with whatever applied it is a pain to update the outfit. As Slink and others upgrade bodies and heads a bulk inventory replace of the body or head is a problem.

Bodies and heads are often no-mod. So, the copies can't be renamed. So, the inventory's bulk replace will wipe out the 'Applier' modified versions. If our viewer considered the UUID in it's 'is this the same' decision it might be easier.

Finding the Applier is awkward as there is no way in the viewer UI to lookup the texture/applier by looking at the body.

Appliers have their problems. But, they allow the designer to handle applying materials.

I'm one of those who doesn't like shiny skin. I tend to powder my nose in the physical world too so not being able to use materials on things like skin and tattoos isn't going to bother me at all. I would like some shine for lips and possibly eye shadows but a talented artist can get the shine without using materials .. yes, it's easier and the effect is better but not so much that I'd use appliers to get it. Now materials is vital on our mesh clothing but not so much for things that go on the skin... but that's my opinion.

[Chellynne Bailey]

13 hours ago, Blush Bravin said:

Can't we just let appliers die? Bite the bullet, do some work, and move on. I hope that once day we will look back to using appliers the way we look back at using sculpts now. They were necessary at one time but aren't we glad we don't need them anymore!

1

I know appliers are a bit of a convoluted annoying thing right now. But they really don't have to be. Frankly, atm we're at the Mercy of current API limitations. If we get the API we're asking for, appliers won't just be as good as System Layers, they will be FAR FAR BETTER. 

People have already mentioned Intuitive, Visual Representations of what you're thinking about wearing. Something System layers are incapable of. People keep asking for attachment previews, that's exactly what a well-designed applier hud does.

But I also see the day when all mesh and prim attachments automatically apply alphas and glitch pants. No more fumbling for an alpha. It just goes on when you put on your hooves. Scripted control of layers is going to bringing us much closer to the sort of "Wear and go" ease that other more limited platforms provide.

And yeah, for existing appliers of all sorts, there will need to be some sort of "relay". But for new products, there's no reason appliers won't just work without kits or relays or anything else.  It'll be much more akin to the experience you get with the texture huds for Mesh Clothing. Just wear and click. Frankly, I'm already mentally tossing about ideas for how to structure a new dev kit that can send things directly to the bake stack AND via normal applier channels for onion layers and wardrobe functionality.

Quote

The problem of Appliers and how outfits are stored is a PITA. I have 2014 and 2015 outfits that use appliers for the underwear or shirt layer. If I did not include the Applier HUD as part of the outfit or save a copy of the body with whatever applied it is a pain to update the outfit. As Slink and others upgrade bodies and heads a bulk inventory replace of the body or head is a problem.

2

If we get the API we want. This won't be the case anymore. Once the layers on the body, it'd be saved just like a normal layer.

On 4/22/2018 at 10:53 AM, Theresa Tennyson said:

Why'd you want to wear a shirt spray-painted to your skin? Bakes-on-mesh is not a good solution for clothing. (Whether applier clothing is a good solution in itself is another story.) I have never said that it is.

This is my spec for a day-zero avatar, using only features that are available right now and bakes-on-mesh in its current state (hands, feet and head separate as is the common practice):

2

 

That's a good set up. Honestly, it's what I'm recommending to mesh makers. But it's not our choice what they do.

Mesh makers are going to do what they want to do. No Customer, Designer, Skin Maker, Applier System Creator, etc is going to dictate what is going to happen day one. And they aren't all going to do the same thing. This isn't a borg collective. These are all individuals with different ideas about how businesses should be run.  The only way designers aren't going to get stuck making a bunch of system layers AND appliers is if we get an api.


And to anyone who thinks they should just "Bite the Bullet and update". Bear in mind, some creators have more appliers then others. The folks who are serious. Who do this for a living, often have hundreds and hundreds of textures in use. I've know several who actually have thousands from years and years of creation.  I know because I had to make them special applier scripts to handle the load.   Do not be fooled. It's not going to be a small task to convert all that old stock, and it's not a fair thing to ask of them. Frankly, layer creation can easily take as long as it took to create a batch of textures. Especially if you have a lot of options.  However long you've been doing appliers, you're going to have to spend half that time again to rebox all your old products. 

Quote

There's a fallacy here. I realize that you're in the applier business but everyone else uses appliers to do something else. In fact, many people now using appliers were using system assets to do the same thing before. Backwards compatibility for appliers is just as much or as little of a concern as backwards compatibility for system assets was when mesh bodies and heads were introduced, and people will still own and be able to use products that use current appliers just as I was able to continue to use the system avatar for most of my purposes.

 

Um.. what fallacy? You think people weren't concerned with backward compatibility when appliers arrived?! My whole bussiness is backwards and cross compatibility! You know how many "Is there a converter for system layers?" questions I get? How many people I've had to inform that NO, copybotting or grabbing XML textures is not an appropriate reaction to something not having appliers. Or that "No Mr Mesh Maker, you should NOT be helping people grab their Skins!"

To this day I still get these questions, wanting to use all sorts of things on all sorts of other things.  You should have seen the reaction when I just managed to wrangle the Phat Azz creator and get permission to use his channels for a free relay. Designers and Customers alike were *****ing ecstatic.

People care about backward compatibility ALOT. They always have. To the point of breaking my tos, the meshes tos, the items tos.  Frankly, the lack of Backwards compatibility has created tons of customer service issues for Myself, Designers and Mesh Makers over the years and I for one would like to avoid that.  I'd also like to avoid turning more people into copybotters and rippers then we already have. It's an ongoing problem completely caused by the lack of Backwards and Cross Compatibility.

I know you put your own Jira up. But I'm not sure why. It's almost functionally the same... but in such a way as to exclude existing applier creators by making it difficult to create a converter...





 

Edited April 24, 2018 by Chellynne Bailey

[Theresa Tennyson]

1 hour ago, Chellynne Bailey said:

If we get the API we want. This won't be the case anymore. Once the layers on the body, it'd be saved just like a normal layer.

 

How? What repeatable record of it will there be?

An applier is the equivalent of telling somebody to do something by a phone call. The data vanishes after the instructions are sent and if it needs to be repeated the process has to be done again. If they're only going to one thing - say, wear a certain pattern of textures that will be hard-coded into them until they're given new instructions, that's fine. You're talking to the mesh, and the mesh won't need to change until its told to.

With bakes-on-mesh, you're not talking to the mesh, you're talking to the baking service. It's dealing with thousands of avatars and honestly it can't bother holding onto the data necessary for every one of them, so it needs those avatars to provide instructions on how to bake them. That's the purpose of a system layer - it's a written instruction on what texture to deliver where. The baking service knows where to get the information quickly without having to ask questions.

Your proposal involves using textures and then all sorts of metadata that doesn't have a permanent place to live so it can't be accessed quickly and repeatedly. It's the same metadata that's already part of a system layer and which the baking service already knows how to read. Yes, right now the process of making a system layer asset is slow, but the items themselves are very useful and I think it would be much more practical to use them rather than creating an ad-hoc equivalent by script every time you click a button. It may well be possible to write an XML converter that would translate applier data into a system asset automatically.

Edited April 24, 2018 by Theresa Tennyson

[Les White]

On 4/18/2018 at 7:29 AM, Theresa Tennyson said:

Okay -- why? I'm honestly curious.

I want to make an alpha applier to help fit mesh clothing to mesh avatars. Currently we use a bunch of faces that toggle alpha. Soon we wont be - if this bakemesh stuff works.

Now imagine you have all these old mesh clothings and you want to wear them.  Do you fish around in your inventory for a bunch of alpha textures (you KNOW people are going to have huge collections of these) you can bake until you get a decent mask? How can you even look at these textures in your inv. Total nightmare.

Instead you use my new alpha slice applier hud that previews a seemingly endless array of alpha slices that you can apply to your skin bake in a UI that allows you to see them on a model and browse them by category.

I need to insert textures into the bake via script. This whole thing is kind of a non-starter without it.

While I'm demanding practical things let me also ask for a new standard and optional body_upper2 bake region that has 2 (two) whole arms that we people who make these mesh bodies can use as a standard as we move forward with this.

[Chellynne Bailey]

36 minutes ago, Theresa Tennyson said:

How? What repeatable record of it will there be?

An applier is the equivalent of telling somebody to do something by a phone call. The data vanishes after the instructions are sent and if it needs to be repeated the process has to be done again. If they're only going to one thing - say, wear a certain pattern of textures that will be hard-coded into them until they're given new instructions, that's fine. You're talking to the mesh, and the mesh won't need to change until its told to.

With bakes-on-mesh, you're not talking to the mesh, you're talking to the baking service. It's dealing with thousands of avatars and honestly it can't bother holding onto the data necessary for every one of them, so it needs those avatars to provide instructions on how to bake them. That's the purpose of a system layer - it's a written instruction on what texture to deliver where. The baking service knows where to get the information quickly without having to ask questions.

Your proposal involves using textures and then all sorts of metadata that doesn't have a permanent place to live so it can't be accessed quickly and repeatedly. It's the same metadata that's already part of a system layer and which the baking service already knows how to read. Yes, right now the process of making a system layer asset is slow, but the items themselves are very useful and I think it would be much more practical to use them rather than creating an ad-hoc equivalent by script every time you click a button. It may well be possible to write an XML converter that would translate applier data into a system asset automatically.

That's how it works now yes. But that will change. If we're using UUIDs to create temporary layers, there's going to be a home for it. There has to be or the information wouldn't persist from login to login. Maybe an invisible temp folder. Maybe somewhere else. But it WILL exist somewhere that can recalled. This isn't a radical thing to suggest.  The Lindens will figure out the easiest place to store the information.   

Edited April 24, 2018 by Chellynne Bailey

[Theresa Tennyson]

7 hours ago, Chellynne Bailey said:

That's how it works now yes. But that will change. If we're using UUIDs to create temporary layers, there's going to be a home for it. There has to be or the information wouldn't persist from login to login. Maybe an invisible temp folder. Maybe somewhere else. But it WILL exist somewhere that can recalled. This isn't a radical thing to suggest.  The Lindens will figure out the easiest place to store the information.   

I'm going to be blunt. I typically use system assets. This means that the merchants who now provide only appliers have decided that my business isn't worth spending their time on at this point. I can't complain about that - that's their time and their decision.

I'm also not saying that your proposal isn't a good idea if it can be made to work. However, this project will work perfectly for me as it is right now, and releasing it won't prevent additions in the future to work with old appliers, etc. This is not a showstopper. Why should I spend any of my time waiting for this feature only to benefit those who aren't willing to spend time to benefit me?

[Blush Bravin]

It seems that we will need to keep at least one of the onion skins of the mesh body if we're going to have the toe part of the stockings. I imagine it will work something like our Slink feet used to work that we used with our system bodies. How will Bakes on Mesh work with this scenario? 

[Tarani Tempest]

I actually like appliers ... GASP!SHOCK!    Of course I do not like the pesky problem of layering transparencies, no one does. So, some points off for using appliers.  Here is what I do like; I like having the ability to visually see my options, and clicking away until I am satisfied with the look. I also like that the applier replaces a folder full of system layers... which helps keep my inventory down.

Now , I am a bit biased, as I make cosmetic appliers... but my reasons still stand.  I am able to make fairly large elaborate cosmetic kits all wrapped up into ONE applier.  Some of my kits are made up of a 100 (give or take) textures.  If I were to release those only as individual system layers, it would be a nightmarish bloated folder of dooooom.  

I don't actually use clothing appliers, but I do use lingerie, tattoo and stockings/hose appliers.  I have some sets, that creators have included a ton of options.  Having all those options in one applier is pretty great, and would be perfection if it were not for the dreaded transparency annoyance.

So, I am all for finding a way to combine the use of appliers and bakes on mesh.

[Blush Bravin]

2 hours ago, Tarani Tempest said:

I don't actually use clothing appliers, but I do use lingerie, tattoo and stockings/hose appliers.  I have some sets, that creators have included a ton of options.  Having all those options in one applier is pretty great, and would be perfection if it were not for the dreaded transparency annoyance.

 

I make stockings so I understand all those options I have to make when making appliers because I have to think of every possible way a customer might want to use the items I've made, but if a set could have one system panty (mod so that panties can be tinted any shade the customer can dream of), one system stockings (again mod), one system garter (mod), then the customer can determine the combination desired. I don't have to make a ton of combinations hoping I've covered every possible combination. 

I get that for makeup it's possible that appliers will still be necessary if we want to use materials, but I have to say being able to layer tattoo makeups and then saving the combination of my choice as an outfit and not having to use an applier ever again is very exciting to me.

I love your makeups Tara. The idea of using one of your eyeliners with one of my own lipsticks, and my favorite set of freckles and then saving that as an outfit seems ideal for me. Doing that with appliers means I have to save all those appliers and somehow make a list of what color I used so that when I want to wear that combination I can hopefully get the same look I had before. 

Of course I'm not saying that having appliers as an option should not exist or be figured out, but I don't want to see this project delayed as a result on waiting for an applier solution. Personally, I don't like appliers but I'm certain that for everyone like me who doesn't like appliers there are just as many who want appliers. 

 

Edited April 24, 2018 by Blush Bravin

[Theresa Tennyson]

11 hours ago, Chellynne Bailey said:

That's how it works now yes. But that will change. If we're using UUIDs to create temporary layers, there's going to be a home for it. There has to be or the information wouldn't persist from login to login. Maybe an invisible temp folder. Maybe somewhere else. But it WILL exist somewhere that can recalled. This isn't a radical thing to suggest.  The Lindens will figure out the easiest place to store the information.   

How about this: Ask for a wearable item that can have its texture changed by script - either a modification to the existing assets or a new class. Then to use an applier with bakes on mesh, wear your HUD and one or more of these "chameleon" wearables associated with the HUD. The HUD button sends the texture to the wearable asset instead of the mesh face. You could have multiple wearables associated with the HUD. For instance, with a makeup HUD with 30 eyeshadows, 30 blushes and 30 lipsticks, you would wear a wearable for the lipsticks, one for the blushes and one for the eyeshadows. Then the HUD would change the texture on the appropriate item. Meanwhile, since the layer sequence wouldn't change, you could change your eyeshadow when it was still stacked below your eyebrows.

You'd have an avatar that could have over fifty layers and no alpha fighting.

All the data would be persistent until it was changed and in a format the baking service knows how to use. You could also have multiple copies of the wearable assets so if you changed your eyeshadow from blue to green it would only change in those outfits referencing that particular copy of the wearable, and all the outfits that did reference it would automatically.

 

[Tarani Tempest]

Hi Blush! We MLFs miss you

 

1 hour ago, Blush Bravin said:

I make stockings so I understand all those options I have to make when making appliers because I have to think of every possible way a customer might want to use the items I've made, but if a set could have one system panty (mod so that panties can be tinted any shade the customer can dream of), one system stockings (again mod), one system garter (mod), then the customer can determine the combination desired. I don't have to make a ton of combinations hoping I've covered every possible combination. 

I get that for makeup it's possible that appliers will still be necessary if we want to use materials, but I have to say being able to layer tattoo makeups and then saving the combination of my choice as an outfit and not having to use an applier ever again is very exciting to me.

I love your makeups Tara. The idea of using one of your eyeliners with one of my own lipsticks, and my favorite set of freckles and then saving that as an outfit seems ideal for me. Doing that with appliers means I have to save all those appliers and somehow make a list of what color I used so that when I want to wear that combination I can hopefully get the same look I had before. 

Of course I'm not saying that having appliers as an option should not exist or be figured out, but I don't want to see this project delayed as a result on waiting for an applier solution. Personally, I don't like appliers but I'm certain that for everyone like me who doesn't like appliers there are just as many who want appliers. 

 

I don't disagree with any of this.  My own work would, of course benefit from not having to make added textures with...lets say an added eyeliner to each eye shadow. So yea, I totally get it. And I am very excited about being able to layer make ups in using the BoM system, it is something I've wanted since I began doing what I do.  I feel very restricted when creating textures for appliers, but only because I have to think my way around layering transparencies and the built in designated mesh areas of mesh heads.  BoM would completely change that for me, for all of us.  However, I still want the best of both worlds.  I want to the ability to HUD up my system layers.... for all the same reasons I previously stated.

1 hour ago, Blush Bravin said:

Of course I'm not saying that having appliers as an option should not exist or be figured out, but I don't want to see this project delayed as a result on waiting for an applier solution. Personally, I don't like appliers but I'm certain that for everyone like me who doesn't like appliers there are just as many who want appliers. 

 

I don't see this as part of the project that will or should delay it.  I see it as an important aspect of the project that should be integrated while it's currently being developed and not sometime after.  It needs to exist as an added choice for creators, another tool for them to work with.   The more choices the better

 

[Blush Bravin]

1 hour ago, Tarani Tempest said:

I don't see this as part of the project that will or should delay it.  I see it as an important aspect of the project that should be integrated while it's currently being developed and not sometime after.  It needs to exist as an added choice for creators, another tool for them to work with.   The more choices the better

 

I may be wrong but I thought I heard Chey request in the last content creators meeting that was live streamed by Medhue that BoM not be released until the API was made available and the applier situation sorted. Again I may have misheard, but I thought Vir said doing so would delay the project.