Bakes on Mesh Feedback Thread

[Cathy Foil]

2 hours ago, Stickman Ingmann said:

So me and several other avatars makers create non-standard "onion skinned" avatars. I've made dragons, gryphons, and wyverns. I'm working with someone who does horses. I have friends who make dinosaurs who use a similar method.

In order to aid in customization of these creatures, it's common to have a "texture HUD." Select a body part, select a texture, and it gets applied. Pick a decal/tattoo layer, and apply some spots or stripes or a stocking or whatever. The system can get pretty fancy, allowing you to have certain patterns on legs or arms, and different patterns on wings and tails, etc.

From what I understand of Bakes on Mesh, in order to use this new feature, it would be necessary for the consumer to manually apply textures from inventory, rather than using a HUD to layer and bake the textures. Is that correct?

If it is, the Bakes on Mesh project asks the question: which is better? A texture HUD with preview images, or a series of folders with various named skins in them? I'd pick the texture HUD every time. So unless I'm mistaken, for now I'll be continuing my onion skinning designs, but hope to hear more developments soon!

Unfortunately we won't have another Content Creators meeting for two weeks but I plan at the next meeting to bring up LL incorporating some of the RLV viewer code that a lot of third party viewers have, like Firestorm, that allows scripts to make an avatar wear system clothes and system tattoos.  Since this already exists I would think it wouldn't be that difficult or time consuming to bring it into the LL default main viewer.

If this happens we get the best of both worlds.  We can have huds that make it easy to pick out and wear system clothing and tattoos which are less lag producing than regular huds and we can get rid of onion skinned avatars whether human or other.

[Coffee Pancake]

1 hour ago, Cathy Foil said:

Unfortunately we won't have another Content Creators meeting for two weeks but I plan at the next meeting to bring up LL incorporating some of the RLV viewer code that a lot of third party viewers have, like Firestorm

Firestorm uses RLVa which is developed by the Catznip viewer by Kitty Barnett. Kitty has said that she would be willing to let LL have RLVa should they want it, and she is planning on making RLVa commands specifically for mesh baking anyway. 

It's worth mentioning that we have tried to get wider usage of RLVa outside of the adulting community (and being able to script the viewer via commands is broadly useful), but there has never been much uptake or interest, the association between this technology and kink is set in stone. If (and it's a HUGE if) LL did take the code then we would fully expect it to end up rolled into experience tools and the end result would almost certainly not be the RLVa we have and use now.

(It's also worth pointing out that due to licensing issues, LL can not just take third party viewer code, there is a process to be followed inc handing over some rights.)

Edited May 4, 2018 by CoffeeDujour

[Kitty Barnett]

18 minutes ago, CoffeeDujour said:

It's worth mentioning that we have tried to get wider usage of RLVa outside of the adulting community (and being able to script the viewer via commands is broadly useful), but there has never been much uptake or interest

That happened even when I went in an entirely different direction and added client side scripting to the viewer (so as opposed to in-world scripts, you write scripts that directly interact with parts of the viewer). Every now and then someone will always speak up and "if only we had..." or "why can't we...?" but it turns out to be a solitary voice. So client-side scripting died and is collecting dust in my piles of "unwanted try-outs".

[Coffee Pancake]

Just now, Kitty Barnett said:

....and is collecting dust in my piles of "unwanted try-outs".

Um .. Maybe we need to go over that folder sometime, we probably have a couple of years worth of headline new Catznip features just sat there all unloved.

[Klytyna]

4 hours ago, Cathy Foil said:

I plan at the next meeting to bring up LL incorporating some of the RLV viewer code that a lot of third party viewers have

 

4 hours ago, Cathy Foil said:

We can have huds that make it easy to pick out and wear system clothing and tattoos which are less lag producing than regular huds

Sorry but this is utter rubbish. If you are claiming that an RLV/RLVa shared folder wear hud will be "less lag producing" than an applier hud using texture uuid's to put textures directly onto a surface using llPrimParam commands, then either you have NEVER used RLV/RLVa shared folder wear (I have, regularly, it's how I normally change my clothing, it's also how I script RLV based transformation traps) or you know absolutely nothing about setting textures via a script with a uuid, or both of the above.
 

[Klytyna]

2 hours ago, Kitty Barnett said:

and is collecting dust in my piles of "unwanted try-outs".

 

2 hours ago, CoffeeDujour said:

Maybe we need to go over that folder sometime, we probably have a couple of years worth of headline new Catznip features just sat there all unloved.

Start with something useful such as...

Un-greying the greyed out boxes on the edit panel when editing attachments, such as position/rotation (the latter expecially when editing linked), 

Restoring the "share" option to the right click context menu in inventory (you broke that in R12)

 
 

[Coffee Pancake]

1 minute ago, Klytyna said:

Un-greying the greyed out boxes on the edit panel when editing attachments, such as position/rotation (the latter expecially when editing linked), 

Use the feedback button and ask for it ^^

1 minute ago, Klytyna said:

Restoring the "share" option to the right click context menu in inventory (you broke that in R12)

It's fixed.. Will be in next release. LL changed it and we missed it.

[Klytyna]

3 minutes ago, CoffeeDujour said:

Use the feedback button and ask for it ^^

Actually, I spoke to Kitty about it about 6 months ago... It was supposedly going to be in R12...  
 

[Coffee Pancake]

1 minute ago, Klytyna said:

Actually, I spoke to Kitty about it about 6 months ago... It was supposedly going to be in R12...  

Use the feedback .. don't ever depend on our memory to have something in if it's important .. even if we say "oh sure, no probs". 

[Callum Meriman]

6 hours ago, Cathy Foil said:

I plan at the next meeting to bring up LL incorporating some of the RLV viewer code that a lot of third party viewers have, like Firestorm, that allows scripts to make an avatar wear system clothes and system tattoos.

There is a portion of the Resident Base who will be stubbornly opposed to any import of RLV code, they will rant and claim you are trying to force BDSM on them.

Instead of RLV and the luggage that carries, experiences allow attachments, this could be extended grid wide and include also system items. Having it in an experience locks the creator into paying for premium, but prevents griefing that could occur with other's changing your textures without permission.

Imagine a griefer tattoo that puts a huge L on the victim's forehead because she didn't have her RLV permissions correct.

[Cathy Foil]

41 minutes ago, Callum Meriman said:

There is a portion of the Resident Base who will be stubbornly opposed to any import of RLV code, they will rant and claim you are trying to force BDSM on them.

Instead of RLV and the luggage that carries, experiences allow attachments, this could be extended grid wide and include also system items. Having it in an experience locks the creator into paying for premium, but prevents griefing that could occur with other's changing your textures without permission.

Imagine a griefer tattoo that puts a huge L on the victim's forehead because she didn't have her RLV permissions correct.

You bring up some good points and concerns.  I would probably limit the RLV code to just system clothing and not extend it to attachments.  Hopefully this would make it different enough so less association with BDSM.  As far as griefers using it perhaps the RLV code can check to see if you do indeed have the UUID in your inventory before proceeding.  This would mean even if you unknowingly click on an object that contains griefer RLV code that tries to force you to wear a UUID the viewer would stop it since it is not in your inventory.  Another way might to make it built in that only objects owned by the resident can run the RLV code.  So if you click on an object owned by someone else the code doesn't execute the rest of the code.

[Klytyna]

And once again, we have a "brilliant idea" to which ZERO thought and planning has been given by it's originator, thus leading to another total failure...

6 hours ago, Cathy Foil said:

I would probably limit the RLV code to just system clothing and not extend it to attachments.

RLV/RLVa does NOT make you wear system layers or attachments, what it does is add or wear all the contents of a NAMED subfolder in the #RLV folder in the root of your inventory. What gets worn or added is determined by the CONTENTS of that folder, not the RLV/RLVa code.

6 hours ago, Cathy Foil said:

Hopefully this would make it different enough so less association with BDSM

Good luck with that.

6 hours ago, Cathy Foil said:

As far as griefers using it perhaps the RLV code can check to see if you do indeed have the UUID in your inventory before proceeding

Read the paragraph above where I describe what RLV Shared Folder Wear does, again...

6 hours ago, Cathy Foil said:

This would mean even if you unknowingly click on an object that contains griefer RLV code that tries to force you to wear a UUID the viewer would stop it since it is not in your inventory

I mentioned in my first reply to your earlier post that...

9 hours ago, Klytyna said:

it's also how I script RLV based transformation traps

To make you wear items that are NOT in your inventory, first theres an offer of a subfolder full of items to your #RLV folder, for that to work you have to either click a popup asking if you want to accept the folder, OR use FS, and have already set the "auto accept inventory offers" option in that viewer.

Then you would need to wear an active RLV Relay hud (yes a second hud besides the one you were planning on) to allow the traps RLV commands to act on your viewer.

Then the trap tells your viewer to add or wear the contents of the offered & accepted #RLV subfolder.

There is no convienient way for it to check the uuid of a texture inside one of the clothing items in a folder.

6 hours ago, Cathy Foil said:

limit the RLV code to just system clothing and not extend it to attachments

Even if you did that, with Bake-Fail-on-Mesh it wouldn't matter, some comic's RLV weapon makes you add a system alpha layer that cuts out the letters "Idiot" in your BFoM mesh forehead, or alphas out your BFoM mesh hair and the back of your BFoM mesh head, so people can see into your empty head, or...

The list of possible "amusements" available with BFoM via RLV-worn system layers is just endless...

13 hours ago, Cathy Foil said:

I plan at the next meeting to bring up LL incorporating some of the RLV viewer code

Before planning to Lick-A-Linden into adding RLV/RLVa to their viewer, MAYBE, just MAYBE you should have thought about...

1. Testing RLV/RLVa to find out what it actually entails and what it actually DOES.

2. Spoken to some RLV/RLVa coders to find out if what you wanted was in fact actually possible at all.

3. Found out who holds the IP on RLV and RLVa, and spoken to them, to see if either of them were in fact WILLING to let LL add their code to the  LL viewer.

4. MAYBE just MAYBE... Engaged in actual THOUGHT, before announcing that you intend to bring up another poorly planned "feature request" at these damn meetings.


 

Edited May 5, 2018 by Klytyna

[Blush Bravin]

I really do not know all the ins and outs of using RLV. I do know I use it with my CTS Wardrobe. I use it to dress nearly everyday, but I don't have it set so anyone else can use it to do anything to or with my avatar. I know there are many of us who use the CTS Wardrobe who have no connection to the BDSM lifestyle. I think it's a matter of educating people on how to use it and more importantly how to keep anyone from using it to do anything to your avatar that you don't want happening. 

I'm all for using it if it means we can get the system to work and in the process protect our UUID numbers from being ripped from system layers to be used and passed around to who knows how many people.

[Fem Darcy]

On 5/3/2018 at 4:40 PM, Vir Linden said:

That is indeed a problem. We are looking to add additional channels to the tattoo wearable so you can use tattoos to build up layers of textures for any of the bakes. We may also add additional channels to the current 6 - still looking into that one.

Unfortunately tattoos with extra channels are confusing to older viewers, so we'll also probably need to release a fix to prevent crashing.

Thanks for confirming that. Hope that you guys find a work around that doesn't confuse viewer or casual users since those tend to suffer the most. 
And about the JIRA sure will take the time to add it in, just hope that somehow LL sees the potential of it and addresses it in a reasonable time and not too late. I understand that those are separated branches so the development team/resources might be different just pointing out the much usefulness of this development if the LSL is also added even if it comes at a later time.

@Whirly Fizzle 
 Thanks for that link. I tested it right and seems like we already can apply the base  BOM by command tho for the sake of coherence in LSL the nomenclature should be also usable not just the UUID like TEXTURE BLANK  TEXTURE MEDIA TEXTURE PLYWOOD TEXTURE TRANSPARENT. But once more good find, sure is a good way of doing it even if the nomenclature gets released in LSL.

@Blush Bravin
I also agree is a good point since it was well stated in previous posts. No matter if stealing textures isn't hard, the fact people see a way that seems quite simple might cause panic and it's something to keep in mind.

-------------------

I'm currently redacting the JIRA for the suggested features and I found out a few issues that maybe need to be tackled on the current project as it is. So I will post them here before I go back to the JIRA. Because even LSL might seem something you want to add after this project is finished and live. There are upsides that can't be achieved without LSL. Some are small but others are huge. <3 Don't hate me Vir Linden, just trying to make the project way more useful for SL. I also understand that I can request things on a JIRA and that I missed community meetings where this project was planned, yet I think that the right time to implement the good BOM is now and not as a fix/mod later on. And since this is a feedback thread I think that even if none of the project will change at the current state, things need to be said to point out what can be improved and what's currently a risk for content creators.

One of the main goals of this project is to remove onion layers from avatars, but wouldn't it great to remove from other many objects around SL? The less number of onion objects around the better, no matter if static or moving with the avatar. I think that the current approach of limiting it to only worn objects is a missed opportunity.  Of course it makes sense if the project stops with BOM as the active element it currently is and doesn't bake it to and an end texture. But if BOM does complete the task of baking to a finished texture then the level of customization of product, worn and not could increase a lot. And custom or not people will still carry and use plenty of textures on the objects they wear and rez, but with finished baked textures the number of textures should actually reduce since those places that used to have onion effects to add details would need less number of textures to achieve the same effect.

What do I mean by fully bake textures? After adding the needed layers have a button in the edit window or by script. That turns the temporal mix of textures into a permanent asset with UUID and applies it where the BOM texture was on the moment of 'bake'.

Now let me explain you the deep of such feature and how it really makes BOM better.

• Safer for creators! - If the viewer limits each BOM texture to be applied to objects that are made from the same creator at the same time, there is no way to use the 'apply head to a box' then rip off the skin. The viewer should keep a list of the creator name where any of the BOM textures is applied if BAKED_HEAD is applied to a object created by Whirly Fizzie and then I apply the same BAKED_HEAD to a box created by Fem Darcy, the viewer should reset BAKED_HEAD to a blank texture before applying it to the object created by Fem Darcy . And so it should be for each of the 6 BOM textures. This doesn't seem to solve the issue but read further, since just having 'skin' and 'tattoo' layers doesn't make it hard to simply apply the combination to the box once you decide what you want to rip off. But there are many reasons why I think that BOM needs LSL and one of those is this. If base skins and additional layers gets applied from a HUD, the HUD can be targeted to work only with certain objects and if those are no mod, there is no easy way to rip the textures since applying BAKED_HEAD to a box created by you would just reset BAKED_HEAD to a white texture. In fact, releasing it as it is makes current skins and tattoo layers quite vulnerable, a very easy exploit that people won't even feel guilty of using compared to having to deal with any of the other methods to rip off textures. In my opinion it should only work by LSL and not 'skins' and 'tattoo' like it's currently been applied.
   
• Less clutter in inventories and asset manager. It might sound like if each end user permanent bakes their own textures we might generate way more assets than with the layer system. But reality might tell otherwise since creators creating the texture and then applying it to a tattoo layer, many dependen on the amount of effects they add, will already generate double the assets than just creating the textures and putting them in a HUD that would only take 1 more asset instead of doubling the amount. Then each time a client unpacks it they would get the bunch of tattoo layers in a folder instead of just a single object like LSL BOM could do. Most of the products that will feature BOM sure might have quite some good amount of variations, lets say for example 20, I bet no end user will go and permanent bake 20 variations or close. To make things better for LL the permanent bake would support the asset server with the fee of the upload. 
   
• If allowed on unattached objects, it could really help SL have way less onion object, and textures everywhere. While increasing the amount of customization in almost any kind of product, making creating simpler and personalizing items for end users too.

I could go in more detail but I will try to wrap this up. The biggest one most content creators would want is safety. BOM doesn't make adding details simpler or safer, instead makes it quite more easy to rip off skins and will increase clutter, The most of the important creators and most of main stream won't embrace it. So it will fail on it's task. I really encourage to focus it in a safer design that is more simple to use for the end user and safer for the content creators. Keep the Skins as they were, opening them with a code like this is not breaking content but close to it, since things that were safe now can be used in a way more different than intended. Use the BOM capabilities to allow bakes under a more controlled situation. Either by limiting in where they can be shown at the same time (recommend for each texture to just in items made by the same creator) or focus the control in scripts that will call UUID so creators don't have to share the texture inside a tattoo that is almost like giving it away given how exposed BOM can make them.


I need more time to redact a JIRA appropriately but there is a way of making it work without exposing content, the one that was already in SL and the one that will be made. But once more I'm unsure if the effort of redacting it's worth it or  might end ignored. 

[Fem Darcy]

Small note for those that mention RLV. There is a reason why RLV is not implemented on SL main viewer. It's because it grants permissions that might generate risk for the end user and with malicious scripting could get the user in trouble. Yet I agree it's quite useful and I have quite a few scripts that simplify my life a lot and use RLV because with LSL alone wouldn't be good enough. It would be neat to be able to connect better the viewer with scripting but if that ever comes might need to be something different to RLV.

Yet on that same page as BOM is been created. The only use that I see for content creators to have bots to display their skins, so users can customize them with a HUD, while the bot is wearing them. And once they make their choice save a code or made an order with the code just to get that skin delivered later on by a HUD applier. That way no skin or layers would be exposed. Yet instead of simplifying the process makes it quite more tedious for skin creators and final users. That's why I believe that such development won't be used and will fail on it's main goal. I used skin as an example but you could put any other product.

[Coffee Pancake]

38 minutes ago, Fem Darcy said:

Small note for those that mention RLV. There is a reason why RLV is not implemented on SL main viewer. It's because it grants permissions that might generate risk for the end user and with malicious scripting could get the user in trouble. Yet I agree it's quite useful and I have quite a few scripts that simplify my life a lot and use RLV because with LSL alone wouldn't be good enough. It would be neat to be able to connect better the viewer with scripting but if that ever comes might need to be something different to RLV.

As I have said, the creator of RLVa would be up for porting the code to the official viewer, but we are under no illusions. The end result would NOT be the RLV everyone is used to and more like script extensions to experience tools.. it wouldn't even be fair to call the ends result RLV. Ironically.. this would probably be more useful to more people than what we have now.

[Klytyna]

1 hour ago, Blush Bravin said:

I'm all for using it if it means we can get the system to work and in the process protect our UUID numbers from being ripped from system layers to be used and passed around to who knows how many people.

Using RLV to let a scripted hud add system clothing layers to your avatar, won't do a damn thing to stop people ripping texture uuid's from the worn system clothing, at all, ever.

Appliers are safer, don't drink the BFoM coolaid, it's spiked with dis-informative tech illiterate propaganda.
 

[Theresa Tennyson]

50 minutes ago, Klytyna said:

 

Appliers are safer, don't drink the BFoM coolaid, it's spiked with dis-informative tech illiterate propaganda.
 

Why? Several people have already pointed out that a mesh textured with an applier broadcasts the original UUID to everyone who sees it.

[Cathy Foil]

22 minutes ago, CoffeeDujour said:

As I have said, the creator of RLVa would be up for porting the code to the official viewer, but we are under no illusions. The end result would NOT be the RLV everyone is used to and more like script extensions to experience tools.. it wouldn't even be fair to call the ends result RLV. Ironically.. this would probably be more useful to more people than what we have now.

Well said CoffeDujour!

The whole reason I brought up the RLV viewer code was that it had a feature I thought would be very useful for Bakes On Mesh.  I also knew that LL has limited resources for any project and so why reinvent the wheel if code already exists that can make HUDs to trigger an avatar to wear a system clothes UUID.

I have never used RLV or RLVa myself so I am not aware of its limitations and problems.  That is why I brought it up here so they can be discussed by everyone and potential problems be avoided or solved.

I really appreciate your input and ideas.

Cathy

PS I thought of a 3rd way to stop grievers from using this feature.  If the code were only executable from an object worn on the HUD attachment point. 

[Blush Bravin]

4 hours ago, Klytyna said:

Appliers are safer, don't drink the BFoM coolaid, it's spiked with dis-informative tech illiterate propaganda.
 

Keeping our current method with appliers sucks! BoM will finally put an end to alpha cuts and alpha glitching between layers. There's lots of dis-information and propaganda going on, but in my opinion it's not coming from the proponents of BoM.

[Fem Darcy]

2 hours ago, Blush Bravin said:

Keeping our current method with appliers sucks! BoM will finally put an end to alpha cuts and alpha glitching between layers. There's lots of dis-information and propaganda going on, but in my opinion it's not coming from the proponents of BoM.

With all my respect, I guess big post don't get read. So I will make it clear. Current development of BOM won't change anything in that way because it's so easy to rip off textures that good creators won't use it or pack their items anymore that way for safety and will move to Appliers if they weren't using it. Appliers with decent scripting, because any applier that doesn't encrypt the UUID when sending it to the object is dumb. There are plenty of real appliers that even if the message gets intercepted still needs to be decoded. So way safer than BOM for average users.

Till BOM a skin or tattoo layer was safer than the average applier. BOM just make it the more easy to rip option available. And unfair to any that has ever published skins or tattoos till date thinking they would be safe.

Apologies for those that in fact read. But I wanted this point to be displayed clear to the mainstream posters in this thread.

[Coffee Pancake]

BOM is much safer than an applier .. as you seem to be talking about people using copybot viewers and thinking they can just rip the texture from the clothing item, then you're neglecting those same viewers being able to rip the texture right off the mesh body. So for those people, an applier is no more a hurdle than an avatar layer item. Your encrypted scripted magic .. it adds nothing to the equation for dedicated thieves, making it 100% pure snake oil.

However BOM + avatar layer also defeats people trying to get the texture from the cache as the original texture willl never be in the cache, only the final bake. This is a bigger issue as many are scared to run a fully evil client as it will be stealing their account information at the same time.

LL have stated they are reworking the image cache

[Blush Bravin]

2 hours ago, Fem Darcy said:

With all my respect, I guess big post don't get read. So I will make it clear. Current development of BOM won't change anything in that way because it's so easy to rip off textures that good creators won't use it or pack their items anymore that way for safety and will move to Appliers if they weren't using it. Appliers with decent scripting, because any applier that doesn't encrypt the UUID when sending it to the object is dumb. There are plenty of real appliers that even if the message gets intercepted still needs to be decoded. So way safer than BOM for average users.

Till BOM a skin or tattoo layer was safer than the average applier. BOM just make it the more easy to rip option available. And unfair to any that has ever published skins or tattoos till date thinking they would be safe.

Apologies for those that in fact read. But I wanted this point to be displayed clear to the mainstream posters in this thread.

Apparently I wasn't clear in my response. I fully understand that BoM has the very real possibility of making it super easy for anyone to rip UUID numbers from any viewer. No special tools needed. You just need to pull a report from the developer menu. But that was not my point. The issue is that BoM is necessary because using appliers as they are currently, as those who oppose any implementation of the BoM project propose, is simply broken because of the very real issues with alpha glitching and the limitations of the onion skin mesh bodies. My point is that we need BoM. I don't know what the answer is to safeguarding our texture work. 

I know when I make appliers for Catwa I have to drop the actual texture into an encryptor and then a script is created with the UUID being encrypted so it can't be stolen or at least it can't be stolen as easily as simply running a report from the developer menu. So perhaps something along those lines might work. If using RLV to do something like that would make it easier than by all means, if feasible to do so, then do so.

I am greatly encouraged that we are at least discussing the issue and getting our minds into thinking about how to address the problem before BoM goes live.

[Blush Bravin]

1 hour ago, CoffeeDujour said:

However BOM + avatar layer also defeats people trying to get the texture from the cache as the original texture willl never be in the cache, only the final bake. This is a bigger issue as many are scared to run a fully evil client as it will be stealing their account information at the same time.

 

The problem is anyone who has purchased the system layer and is wearing it can pull the UUID of the single texture and not the full stack. All they have to do, if they really want to get the UUID to pass it along to friends or whomever, is wear the one layer and pull the report from the developer menu. The final bake solution is only helpful for those using those special viewers to scan avatars and pull UUIDs from those avatars. 

The wide scale passing off of UUIDs between friends for free almost bothers me more than the issue of a copybotter getting the info. At least with a copybotter my work has not lost all value, and I have some recourse through DMCA and the Lab to stop the botter. How would Linden Lab address the problem of a large group of people who are passing UUIDs?

[Coffee Pancake]

1 hour ago, Blush Bravin said:

The problem is anyone who has purchased the system layer and is wearing it can pull the UUID of the single texture and not the full stack. All they have to do, if they really want to get the UUID to pass it along to friends or whomever, is wear the one layer and pull the report from the developer menu. The final bake solution is only helpful for those using those special viewers to scan avatars and pull UUIDs from those avatars. 

Then maybe you need to verify this with a repro and file a JIRA .. and not discuss it on the public forums.