Chellynne Bailey

There is a link at the top of the page for anyone who wants to get listed. I don't actively search the Market for new omega creators. That would be madness.

Because we won't still be able to apply textures using HUDs. If this launches without some sort of solution, and all the mesh makers do what they say they are going to do, years worth of work will need to cracked back open and reboxed. Sometimes even reuploaded if they didn't save the textures. It's going to be a huge economic hit for folks to have to either retire these old products or spend a bunch of time reboxing things. This "great step forward" is going to cost alot of creators back years of work. That doesn't mean BoM shouldn't Launch. If it's done right, it'd be a great boon for everyone. The learning curve could be drastically improved for both creator and customer. But if it launches as is, it's going to be one giant cluster@#$@#$.

That's not much different then whats being requested. The only real difference is my Jira has the scripts creating the new asset themselves instead of relying on a customer to equip it. That doesn't sound important, but it is if we want things to be user friendly going foward. And lets face it, one of SLs biggest issues with growth and retention is user-friendliness. SL is 90% dress up and right now getting dressed is way too convoluted. That's why I'm eager to see BoM done and done right.

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 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. 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. 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. 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...

I know cut lid is rather popular right now, but traditionally shadow frequently touches the brow. And given that brows vary in thickness depending on who draws them, the chance for overlap is high. Even looks that LOOK like they don't go that high, often have soft shimmers or other effects right under the brow for highlight that would look awful layered over the brow.

As requested at the Creator Meeting, a Jira has been constructed for the Insertion of Textures into the Bake Stack. It is here: https://jira.secondlife.com/browse/BUG-216137? I have a couple questions about how things are currently stored. Are the attachments we see in appearance stored in one list? Or is what we see actually the compilation of several stored lists? There's been a bit of discussion about the best way to indicate where to put something in the stack, and it'd be nice to know how things are done now. Also on a related note, has there been any thought about simplifying the current scheme and getting rid of some of the layers? Currently, all they do is force System Layer creators to create more than one layer for their items since everything seems locked to it's own layer.

I can't speak for Les, but I can think of two BIG reasons Backward compatibility for existing appliers. (Something anyone who makes or provides appliers should want. ) 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.)

I wasn't suggesting it had any impact on others. Only that people should turn them off if they want to be able to move. Can't say I've ever encountered anyone who doesn't need to turn down settings for a smooth experience at something like a Skin Fair. If we wanna talk about the impact on others, it's not the settings that need to change, but what you wear. Stripping down to alphas can help your fellow shoppers a great deal.

Yes. There are a plethora of unrigged mesh bits and bobs that I currently offer applier support for that will have a baked option added, either by their original creator or by me.

Well, let us let LL worry about server load. People should br turning off materials affects in busy areas anyways. Yeah, I think 1-4 is basically what I said.. but wordier... but 5 we diverge. I'm suggesting, instead of using alpha channel to define a spec or normals alpha'd out areas, since that's being used for other things, we instead use the corresponding diffuse texture as an alpha. Should be fairly simple for the system to black or white it out so it's solid color + transparencies. As for server load, I don't think it'd be much. There's no real reason to recalculate unless you add or remove something. As long as people aren't sitting at events spamming items on and off if should be fine.

That actually explains alot. But it sounds like the system could use the corresponding diffuse layers as the Alpha Map (They'll need to be flattened of course). We just need to make sure spec and normal maps are attached to diffuse textures. Start with skin spec- (if it exists) Alpha out the shape of the 1st diffuse texture. Add that texture's spec map. Alpha out the shape of the 2nd diffuse texture Add that textures spec map rinse repeat till you reach the top of the stack. You should end up with all the visible textures having their spec map visible where the diffuse is visible and nowhere else. The same process should be useable for Normal maps. We will need a tag for items that should be skipped in the process. Ie, Tattoos that want to adopt the spec map of the skin could skip the Alpha out step. Unless there's some flaw in my logic?

So what makes Normal and spec maps trickier? They're just textures like any other. I'm sure clothing makers would need to alpha out unused sections just like they do with diffuse textures, but once they've done that, what is keeping the system from baking those spec/normal textures together?

Well I don't think this is going to have any affect on UV issues. Textures will still need to be tailored to meshes and meshes to textures for them to all be happy. SLUV is a convenient UV, simply because dispite it's flaws, it's freely available with no one to yell DMCA! at creators using it. As for the normal and skin maps, it's an issue with texture clothing, not Fitmesh Clothing. I know people like fitmesh, but there are literally hundreds of Bodies on the market atm (maybe more, my spreadsheet was at 500+ before I quit counting a year ago), and there's only about a dozen getting any support from Fitmesh Clothing creators. So I'm heavily invested in making sure those creators aren't any more disadvantaged then they currently are. So the better this bakes thing works for meshes stuck with just applier support, the better. So, right now, without changes to the system, the only way to keep the materials on the body after clothing is added, and to still look right, would be if whom-ever made the skin-materials, usually the skin or body maker, made a version of the spec and normal maps tailored to that specific clothing/skin combo. This... if you can't tell already is not a viable solution, since 99% of the time your skin creator and your clothing creators are two different people. Without baking, the spec set ups needed would be.. infinite.. There's alot of ways this could be addressed. One would be adding spec and normal maps to the system layers. Spec/normal makers WOULD need to alpha their textures correctly, but it'd bake together just like defuse textures I'm sure. Another would be Cathy's idea of adding an Integer value to system layers, so we can filter them. I could see it being a tad confusing, but it'd allow us to hijack the system a bit and bake some spec/norms together and slap them in the spec/norms slot instead of the bakes spot. (not sure if it's possible via edit atm, but should be possible via scripting). It'd also let us expand the system as needed to include asymmetrical appliers and other fun things like wings, tails, mesh clothing. Really the sky would be the limit in that scenario.

I'm sorry I came off as rude. I tried to phrase it as nicely as I could. But clearly, you and I disagree a great deal about what the current state of things is. It's a pity, because you did have a really good idea about adding an integer for filtering.

Yeah, I was hoping to put off releasing anything at this point. Who knows what the API will look like by release, but someone went and did it with my Dev kit, so had to put out something free so people aren't flinging money at something that may not work in a month.

Better in this thread then out in the world where the Facebooks morph it into who knows what!

Say what now? First, the one on the MP isn't mine. It was released without my consent using my applier dev kit and I've asked them repeatedly to pull it down. It is against my TOS to use my Applier scripts to make appliers for items and textures that you don't have the rights to. Frankly, the baked applier fundamental breaks our design philosophy we've had since Maitreya of being "opt-in" only. But frankly, there is no way to easily stop it at this point. Any body with an applier dev kit can be switched to baking with a simple applier. The only way for a Mesh to stop it is to Filter their appliers and have me update their kit to filter mine. It's a whole lot of wasted dev time just to say "no" to something. Rather then doing that, I just put one out on the counter so people at least aren't spending their money on unauthorized products. Any Mesh Maker who WOULD like to filter it out is welcome to let me know and I will get them new scripts that will do so. I don't think I'll have any takers. As for mine (or any bakes applier) not doing what normal baking is doing... it is normal baking. All it does is switch the Mesh to baking. Everything Baking does, will be done with the Applier. All they did was tie the baking system to some specific UUIDs. Those UUIDs are what is in the applier. There's nothing you can do with manually turning it on that doesn't work exactly the same with appliers. If you don't believe me, go grab it and try it out. It's functionally the same. You also seem to be fundamentally misunderstanding the issue with Materials. No one is saying you can't put materials on a mesh with bakes on it. That is silly. The problem is how to generate a material's texture that is useful. If you put clothing over a skin with materials, those materials are going to peek through even though they make no sense. If you put a T-shirt materials on there instead, you're covering up the lovely skin materials that comes with most Mesh Bodies.

The biggest offender "This can be used on mesh clothing". You CANNOT claim this right now. They haven't done anything to enable this without a bunch of conflicts. The other offender "This works with Materials". It simply doesn't. Yeah, you can apply materials to the mesh still, but which one are you going to apply? The Skin Materials or the Clothing Materials? Neither will look right on the other. It doesn't even look right in the example you give. If you want the Lindens to actually fix these things, don't start rumors that they are already fixed. You're gunna fuddle things up. Frankly, you should just take that whole video down.

Er... Cathy.. Be careful how you describe things. You're listing a bunch of things you want, but then not being clear that it's just hopeful thinking until > 25mins into the video. We're going to have a bunch of people running around thinking your ideas are ALREADY in the system when they are not.

There it is! Yeah, I actually really like this idea. I'm torn on if they should make a new object that is essentially a Texture + Integer, but I suppose adding integers to existing items would work. What is particularly brilliant, and potentially job-ending for me, is that if they did this, we could assign channels 1-6 to be the current baked textures. then 7-12 to be spec and normal map textures. Spec and Normal map creators would have to change how they build their maps, but there's no reason why the baked textures couldn't be used for them. The big thing will be retraining people not to do normals that are full texture and instead only have them affect a certain area. Actually, we could do this: 1-6 Current Baked Textures 7,8 Left and Right Arms 9,10 Left and Right Feet 11: Lashes 12: Neckblender 13-24 Repeat above for Normal Maps 25-36 Repeat above for Spec Maps 36,37,38: Top Diffuse, Normal, Spec 39,40,41: Pants Diffuse, Normal, Spec 42,43,44: Bra Diffuse, Normal, Spec 45,45,46: Undies Diffuse, Normal Spec 47+ Everything else. With your numbering system, we could actually keep the onion layers and be able to bake multiple textures into them AND support Materials. We still need to be able to insert textures into the stack though. llInsertBakeTexture(Integer Bake_Slot, integer Bake_ID, Integer Position)? Just so we're not making creators update a bunch of their old stuff alllll over again. They've been through this once already going from system layers to appliers. >.> As for possible conflicts, you're right, the chance is slim, but we could also cut down the chance of conflicts by releasing a "suggested" list of "channels" for people to use. Wings 100k-199k Tails 200k-299k Ears 300-399k Mesh Pants.. x-x Mesh Shirts.. x-x etc etc etc.x-x It wouldn't cut down on the absolute possibility of two mesh makers picking the same thing, but it'll cut down on the possibility of you wanting to wear both at the same time.

Did you remove it? I coulda sworn I read your idea about adding a integer to a auxiliary bake before bed, was going to respond to it this morning, but now I can't find it! x.x (I actually thought it was a really good idea! ) Yeah, I'm still not sure what you're suggesting, but you need to remember, there's only a small handful of bakes, 6, that are shared by everything you wear. That really isn't alot. It means that anyone wanting to use bakes on something other than a body, has to directly compete with everyone else doing that exact same thing for that same space. Skirt and Hair seem like likely targets for non-body mishief, but what happens when both your mesh tail and a mesh shirt you wanna wear are using the same Skirt bake? You won't be able to wear both. This is why I say, unless they do something different than currently advertised, do not use this on anything but a body.

Well they were asking how it would work as it is presented now. And right now, any attempts to use Bakes for things other then what they are intended WILL lead to conflicts. No matter how many slots you add. By all means, try and convince the Lindens to flesh the system out more. but I don't think extra slots is a meaningful solution. Ultimately, even though she's being rather mean about it! -pokes Kly and wags a finger at her!-, she is right, this all would have worked better if they'd instead given us access to the baking system and let us compose our own list of textures to be baked together. Then again, the two are not mutually exclusive. They could finish this feature and then also give us that baking API. That would allow System Layers to work AND would let us use baking on a multitude of items without conflicts. That at least would be my dream scenario.

My lord this thread gotten a bit nasty. Lets all be kind folks x.x Well, specifically for mesh clothing: Linking/unlinking multiple pieces to save attachment points. Renaming it for easier searching. (Handy if there's a color hud. Often it's easier to make copys of an item in the various colors you like once rather then pull out the hud each time) And of course altering the appearance via tinting or textures. I know you think you lost a sale from that guy. But it's clear they were just being assholes to that person. They probably won't even remember your shop name. When they go looking for clothes, your items are still going to show up in search in the exact same way as before. Really, unless you're killing puppies and advertising that fact, it's kinda hard to lose sales due to reputation in SL. People just don't have the head space to remember they once saw a crappy item from ____.

Non-SLUV bodies, yes. Non-Body meshes.. no. I see no reason this can't be used for Furry bodies and their UVs, but non-sluv makers will need to keep in mind there's only 6 (6 right?) bakes available for use, and no real authority on what to use where. So using them for things that aren't the core body is going to lead to a ton of conflicts when people try to mix and match brands. People are already talking about using the skirt bake for an arm, what happens when someone tries to use that same layer for a tail? Suddenly you can't wear that tail anymore. If you're a furry that mixes and matches, you might find out both your ears and spines are trying to use the hair Bake! So, I will say this again. Do. No. Do. This. Bakes on Mesh is for bodies, and only bodies. All other attachments, if you think there's a 1% chance it might be used with something that isn't your brand, just say no. We have a wonderful Furry Community in SL that does all sorts of creative things. Let's not ruin it by forcing them to stick with a single brand for their looks.