Fem Darcy

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.

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.

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.

Ok, after long without stepping into SL. Some of the updates and upcoming projects draw my attention. So since this is one of them I will give my opinion with the hope it can help. Security issues that some mention: I agree, even there are simple ways to rip off textures from SL, bakesonmesh just makes it way more simple. Tho no clue how to solve it without killing the project. Personally I would rather see development than stop it by a risk that's already there, and tackle the issue of copyright the same old way that has been done till now. A Question! that For all that I read at http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Project_BakesOnMesh/5.1.3.513936 there are 6 textures that will work with bake on mesh (BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR). So, for my understanding only 3 are useful since BAKE_EYES, BAKE_SKIRT, BAKE_HAIR can't add anything on top to bake it, since the only way to add is with tattoo layers, which will only cover BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, . Am I missing something? Main suggestion: I think this could be used in a way more useful way developing it a tiny more further.I guess the reply from LL will be as always that's too much work. But I leave the idea here. What if once the texture is baked it can be saved (usual upload cost). Forget about it been face,torso,legs textures. Think of it as a texture that could be applied to any object/body part. People could use a base texture designed for that object and then apply the FXs layers that they want. Then 'bake it' for real, creating a texture with fixed UUID. That way they won't be limited to 3 bake textures like the current development is making it. Then just retexture the object/body part with edit or via script and they will have that object part customized. The upside of using bakeonmesh as a customization tool like that is that people can also bake the specular and normal maps too. Example for mesh head: Base layer as normal skins are done without make up, freckles or marks. Then many layers could be sold with freckles in different spots, scars, make up,... So the user/client buys as many as they want, apply them in the way they want and then bake. Example for mesh jacket: Buy the jacket style you like, apply the base color/material you like. Apply effects like worn out, cloth patches, logos,.... Bake and enjoy your customized jacket. Example for a table/car/objectsInGeneral: Buy the object, add effects like scratches, dirt, logos, decals, rust, worn out effects. Bake and enjoy. So this idea, focuses on using the body layers to achieve personalized/customized textures for any object/mesh in SL. Now I will explain the development required to achieve it and then some pros and cons. Development needed compared to the current one. LSL, generate the 3 calls/commands needed to apply a bakeable texture : BAKE_HEAD, BAKE_UPPER, BAKE_LOWER. Examples of use: llSetTexture(BAKE_HEAD, ALL_SIDES); llSetPrimitiveParams([ PRIM_NORMAL, ALL_SIDES, BAKE_UPPER, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0, PRIM_SPECULAR, ALL_SIDES, BAKE_LOWER, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0, <1,1,1>, 200, 0]); LSL, generate the function to add textures to the current layers : llBakeAdd([ BAKE_HEAD, "TEXTURE_UUID", BAKE_UPPER, "TEXTURE_UUID", BAKE_LOWER, "TEXTURE_UUID",]); This would work as if the user was adding more layers on top but way cleaner for the user since it could be done with a HUD, that has the effects layers better sorted and not tons of names in the inventory that will confuse people. LSL, generate the function to bake permanent: llBakeBuild(BAKE_HEAD); Here could be one at a time or more, depends on the way of developing since this step would generate a 'real' texture, it would ask the user for the 10L$ cost before doing the bake and when done, would replace anywhere where BAKE_HEAD is applied with the UUID generated, and also give the texture to the user's inventory. That way the user wouldn't have to worry anymore about the texture going away and the bake system would be free to be used in any other object or body part. If the develpment does several textures at the time the process should be the same and just ask for the L$ sum equivalent to the number of textures baked and when done replace each of the BAKE_(part) for the UUID generated. With those tool making HUDs that really help you 'setup' your character or cloth to your liking wouldn't be too hard. I wouldn't mind doing a open source one so people can pick up from there. But it's quite simple to setup the HUD so people can add and remove effects and use the real_time bake as a test and then use the final texture when they make their minds. Pros: Easy to use for the end user if creators do HUDs focused on setup the looks (that way those won't be attached more than during the moment they do the setup. Too many mesh items keep you using a hud while wearing the item = LAG). Let's customize the three textures at the same time (Diffuse, Specular and Normal map). Reduces baking in crowded SIMs. People tend to add and remove clothes and other gear as they go around SL, but fit the clothes or try make up usually happens at their SL home or in stores, so the real time bake will happen less on those SIMs focused to hang out and enjoy. Which will reduce load times for clients and server process to do each baking. - Will indirectly make mesh creators use less textures. For the sake of not making complicated HUDs most creators will want meshes that only have a texture since if they want to bake diffuse/specular/normal at the same time, they won't be able to display it. So a mesh piece of cloth will tend to be more optimized if people want to fully enjoy the bake feature without having to do several parts one by one. - I'm sure there are more but I rather more people input. Cons: People might use LSL to animate textures in objects or badly script those functions that do useless calls. (Suggested solution add 2.0s delay or similar to llBakeAdd, since is the only function that could increase load in the server. Nothing more beyond that because animating textures already has quicker ways of been done and there won't be a point of using this call for it if the delay makes it slower. Another way would be limiting the amount of request within a time period like some other functions have). A mesh like a body that might have several textures won't be able to have the diffuse/normal/specular customized at the same time. That's a limit we had till now so developing the feature this way won't make it worst, simply won't solve it. And as I pointed out I think it's good that's not posible so maybe people limit the texture on simple objects to one, as they should be for efficiency. Sure mesh bodies will miss this feature been able to handle (to use SL body as an example) 3 textures x 3 types (diffuse, normal, specular) a total of 9 textures baked on the fly. But that sure would mean more development from LL and also more resources from the server. (Solution: HUDs could tackle changing the whole body diffuse to choose the general tone and then have the HUD with 'detailing' for effects on face/torso/legs/feet, whatever is the area the single texture would cover and those do them with the diffuse/normal/specular together on the fly.) More work for LL. (My point of view: Agree might be more work. But sometimes doing something halfway renders it useless or way less useful that it could be if pushed a little further. I think the power of pushing this development a bit further will be way rewarding for LL and those that enjoy SL). Pro and/or Con: If my undersanding of the limits of the current bake layers, question I did at the start of this post, (BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR) is limited to 3. The use of LSL could unlock the use of 6 textures at the same time without having to create a tattoo layers for eyes, skirt and hair. Those are my thoughts, hope my contribution helps in someway in a shorter or longer term. I really want to have a SL that everyone enjoys more because even it's 2018 I don't think any other game/platform can compare to SL in customization, creativity and freedom for an open world. And sadly it feels more outdated each day it passes but good developments like this one (I mean the original not my suggestion) might help SL stay attractive even with the time passing by. That's why I really thing the project should be pushed further a tiny bit to get all the juice from the same resource instead of stopping half way. Regards to the LL team and any resident reading this post!