Bakes on Mesh Feedback Thread

[Vir Linden]

53 minutes ago, Blush Bravin said:

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.

This was discussed at the last meeting. Basically anything in software development takes time - the more features we need to get done before release, the longer it will take to release the project. So any discussion of features needs to be looked at in those terms; there's always a tradeoff between less stuff sooner and more stuff later. Of course, there are always other projects that need resources too, so sometimes the decision on what gets included in a project is going to be influenced by that as well.

[Tarani Tempest]

 

1 hour ago, Blush Bravin said:

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.

Well, that is disappointing.  Without it , I will consider the project unfinished.

I will wait and see how things work out, and no matter what ... I will deal with what comes my way

 

[Nalates Urriah]

20 hours ago, Blush Bravin said:

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.

Fair enough. I like the water drops material for my skin. Also, there are types of glamour shots where high shine is needed. Some of us want materials but not all.

[Cathy Foil]

3 hours ago, Vir Linden said:

This was discussed at the last meeting. Basically anything in software development takes time - the more features we need to get done before release, the longer it will take to release the project. So any discussion of features needs to be looked at in those terms; there's always a tradeoff between less stuff sooner and more stuff later. Of course, there are always other projects that need resources too, so sometimes the decision on what gets included in a project is going to be influenced by that as well.

I understand why people want an API for Bakes On Mesh and why they want it in the initial release of Bakes On Mesh.  An API would make backwards compatibility with content people have made for appliers much easier and give Bakes On Mesh more versatility.  I also understand that the fear is if it isn't included in the initial release that no followup project to seriously look into adding API will ever happen.

For me personally the addition of API for Bakes On Mesh isn't that important and I be happy with a firm commitment by LL to do Bakes On Mesh in two stages.  One release Bakes On Mesh with what can be accomplished in a reasonable amount of time say 4 to 6 months.  Then stage two which seriously looks at things that will take longer which probably includes a more extensive API.  If LL would commit to that I would be for it.

The API I like to see added LL should be able to get from the RLV viewer code.  I see a big benefit of a HUD that has pictures representing system clothes and when the resident clicks on one an LSL function causes the avatar to wear it.  The HUD LSL would just need UUID of the system clothes to be worn for that particular picture.  I agree with what was brought up at the meeting that staring at a folder in your inventory that might have a hundred different system clothes and tattoos with just their names to describe what each represents would be less than optimal.  A HUD in this case would be a big asset and make things a lot easier for the end users.  It shouldn't cause lag since it would be communicating directly with the viewer and is only worn for a short period of time.  Once the resident is happy with their look if they want they can simply right mouse click on their avatar and edit their outfit to save the whole thing using "Save As" to create a new outfit folder they can wear anytime.

[Chellynne Bailey]

6 hours ago, Theresa Tennyson said:

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.

 

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.

Edited April 24, 2018 by Chellynne Bailey

[Theresa Tennyson]

14 hours ago, Chellynne Bailey said:

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.

If you want something else to do something for you, you need to make your request practical. I work in a business where people frequently ask me to do things for them that aren't necessary to the project but would make their lives easier. If it's a simple request that I can do quickly and easily while I'm doing the rest of the things, I'll usually do it. If it requires a lot of work and time that will take away from the work needed to successfully complete the overall project I say no.

Your proposal involves creating a new type of inventory asset and a new type of temporary storage to hold information from them. They don't have equivalents anywhere in Second Life now and you can't give a clear description of how they'll work. It would be a tremendous amount of work to do things that can be done with much less work in other ways.

(There, that's much more calm and polite than my original reply that I edited out, isn't it?)

Edited April 25, 2018 by Theresa Tennyson
Because sometimes saying something heartfelt that feels good but is rather confrontational isn't the best way of dealing with people.

[Sachios Feden]

I've been reading the topic since it came up on the forum and just watched the last creators meeting video. I can understand the applier systems and applier makers trying to save their business but come on now! you can still apply textures using HUDs right..whats the big deal? Appliers were a necessity but not anymore so I hope the dilemma of applier systems won't stop LL from 'taking another step forward' (please overlook the irony of backward compatibility also, avatars are anything that's attached to the skeleton (i guess) and not necessarily generic male and female avatars and certainly not just something with SLUV maps. For the record, I used to make skins for SL before mesh and appliers became a thing and am excited about BoM making it finally possible to make avatar textures available again with system layers without middlemen, so there's my not so hidden agenda! Will keep my fingers crossed to the next official announcement.

[Chellynne Bailey]

On 4/25/2018 at 6:09 AM, Sachios Feden said:

I've been reading the topic since it came up on the forum and just watched the last creators meeting video. I can understand the applier systems and applier makers trying to save their business but come on now! you can still apply textures using HUDs right..whats the big deal? Appliers were a necessity but not anymore so I hope the dilemma of applier systems won't stop LL from 'taking another step forward' (please overlook the irony of backward compatibility also, avatars are anything that's attached to the skeleton (i guess) and not necessarily generic male and female avatars and certainly not just something with SLUV maps. For the record, I used to make skins for SL before mesh and appliers became a thing and am excited about BoM making it finally possible to make avatar textures available again with system layers without middlemen, so there's my not so hidden agenda! Will keep my fingers crossed to the next official announcement.

3

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@#$@#$.  

[Sachios Feden]

On 4/27/2018 at 12:24 AM, Chellynne Bailey said:

Because we won't still be able to apply textures using HUDs.

Really? I thought BoM is not going to break anything that's already working and certainly not 'putting texture on a face'.

[Vir Linden]

4 hours ago, Sachios Feden said:

Really? I thought BoM is not going to break anything that's already working and certainly not 'putting texture on a face'.

Bakes on mesh won't do anything to break the ability to apply a texture to a face via scripts (using the llSetTexture() call). If someone wants to continue doing things exactly the way they do today then they can do that without problems.The difficulty is that BOM isn't compatible with the existing mechanism for putting textures on a face, so if you want to take advantage of the capabilities of BOM and switch a face over to use it, then you can't also set its appearance the old way. So various proposals have been made to help with the transition process, allowing applier-based texture manipulation to coexist with bakes on mesh.

[Fionalein]

If it isn' t compatible it will be DOA as not many (well the usual fashion victims aside) will go and buy a second bento head... 

Edited April 30, 2018 by Fionalein

[Theresa Tennyson]

1 hour ago, Fionalein said:

If it isn' t compatible it will be DOA as not many (well the usual fashion victims aside) will go and buy a second bento head... 

Heads will become compatible almost by default. All it involves is applying a special texture that is read by the viewer to display the avatar bake normally used by the default avatar, and it can be done with any head that takes appliers. What won't be compatible right now is the various applier-only skins and tchotchkes in the actual baked portion. If you are using an existing head, though, the layers the head already has will work the same way it does now. Also, if new heads come out without the makeup layers they won't be compatible with the old appliers.

(I'm in the LAQ group, by the way. Some people buy almost every new head that comes out - they're like crack addicts...)

[69xenuno]

I'm all for this BoM. A clothing texture based alpha with no need for alpha segment hud (eventually) is a fabulous idea. Baked on with a minimally layered Maitreya & Logo (in my case) is a win win, though I already burn my tats onto my skin with no need for appliers except for hose. So .. with all the benefits this will bring, it's quite disheartening to see all negative comments on the initial implementation. This is about base avatar improvement and reducing lag. Bitching about materials, clothing and other features outside the scope of the 1st edition is just .. stupid and childish. 

Edited May 2, 2018 by 69xenuno

[Tarani Tempest]

2 hours ago, 69xenuno said:

I'm all for this BoM. A clothing texture based alpha with no need for alpha segment hud (eventually) is a fabulous idea. Baked on with a minimally layered Maitreya & Logo (in my case) is a win win, though I already burn my tats onto my skin with no need for appliers except for hose. So .. with all the benefits this will bring, it's quite disheartening to see all negative comments on the initial implementation. This is about base avatar improvement and reducing lag. Bitching about materials, clothing and other features outside the scope of the 1st edition is just .. stupid and childish. 

The name of the thread is, "Bakes on Mesh Feedback Thread".  The very point of it , is to get feedback on what works, what might work, what we want to work...... I could go on and on with this.  If that was not the point, It could have been called, "Bakes on Mesh Nothing to talk about Thread"...which makes little sense.

Materials, clothing and other features are not outside the scope of the conversation.  And all those things are legitimate concerns that many of us have.  And what do ya know!! Here is the very place we can talk about it to get a better understanding....... go figure

 

 

[Theresa Tennyson]

3 hours ago, Tarani Tempest said:

The name of the thread is, "Bakes on Mesh Feedback Thread".  The very point of it , is to get feedback on what works, what might work, what we want to work...... I could go on and on with this.  If that was not the point, It could have been called, "Bakes on Mesh Nothing to talk about Thread"...which makes little sense.

Materials, clothing and other features are not outside the scope of the conversation.  And all those things are legitimate concerns that many of us have.  And what do ya know!! Here is the very place we can talk about it to get a better understanding....... go figure

 

My science teacher used to have a reply to most students saying something that began with "If..."

It was, "If a frog had wings, he wouldn't bump his butt when he jumps."

Looking at this thread, I'd imagine that some people here who heard that statement would say, "Great! All we have to do is get wings on frogs and then we can use them to deliver airmail!"

Others would say, "Frogs!?! They bump their butts when they jump! If we can't get wings for them right now, they're completely useless! Might as well just gig 'em all..."

It must just be my personality - the catchphrase used to the Meyers-Briggs personality type I seem closest to is "Making the best of what I'm given." What I'm inclined to think is, "Okay - frogs... Jump like crazy? Good. Breathe on land and in water? Can't beat that. Brain the size of my fingernail? Well, we'll just have to work around that.... Bump their butts when they jump? Hmmm.... Okay, can we get wings? No? How about little gliders they can wear? Probably not for a while? Okay..."

Then I ask myself, "Is the butt bumping thing really a problem? After all, they've been doing it for millions of years and it doesn't really seem to bother them." Then I work out a plan for what I can do with frogs that works to their strengths and minimizes their weaknesses.

The way I see things, that's what this thread would be useful for.

[69xenuno]

Well Tarani ... I guess I'm largely speaking of the near trolling by a few on here whom keep repeating inaccuracies when the Lindens themselves have addressed their concerns in posts either before .. or after, the issue was raised. 

[arton Rotaru]

9 hours ago, Theresa Tennyson said:

How about little gliders they can wear? Probably not for a while? Okay..."

At least there are these...

 

[Stickman Ingmann]

I'm new to the bakes on mesh project, and a scripter by trade. I know there must be some script functionality going on here because of the Omega HUD already on the market ( https://marketplace.secondlife.com/p/Bake-on-Mesh-skin-applier-Omega/14391590 ) But I cannot find any documentation regarding script-based mesh baking.

Can anyone point me in the right direction?

[Klytyna]

1 hour ago, Stickman Ingmann said:

I'm new to the bakes on mesh project, and a scripter by trade. I know there must be some script functionality going on here because of the Omega HUD already on the market ( https://marketplace.secondlife.com/p/Bake-on-Mesh-skin-applier-Omega/14391590 ) But I cannot find any documentation regarding script-based mesh baking.

Can anyone point me in the right direction?

You don't need "scripting api" to make an Omega applier, just the UUID's of the final bakes.

A scripting API for Bake-Fail-on-Mesh has been requested, but don't hold your breath, the feedback exercise seems largly a formality, people point out the obvious flaws and suggest improvements and the official reply is...

"Hmmm, interesting, we'll think about it BUT... We don't want to delay the already planned Official Release party, so we won't ACTUALLY make any changes to what's currently being *cough* tested *cough*. Thank you for your time!"
 

[Fem Darcy]

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!
 

Edited May 3, 2018 by Fem Darcy

[Whirly Fizzle]

14 hours ago, Stickman Ingmann said:

I'm new to the bakes on mesh project, and a scripter by trade. I know there must be some script functionality going on here because of the Omega HUD already on the market ( https://marketplace.secondlife.com/p/Bake-on-Mesh-skin-applier-Omega/14391590 ) But I cannot find any documentation regarding script-based mesh baking.

Can anyone point me in the right direction?

It's actually simple to do.

Just apply the desired baked texture UUID to each face of the attachment.

BAKED_HEAD 11c5d053-0ea9-a529-46cb-351d4e84d17a

BAKED_UPPER 149e7c88-74ef-995b-5e23-a27208de3193

BAKED_LOWER 066d5659-0856-748e-a6de-495d896fe93b

BAKED_EYES  136c0789-b42c-4c6c-134b-63669d981fcb

BAKED_SKIRT baf656f8-0b45-a85a-244e-f3bdb835f1a2

BAKED_HAIR  1ba5b07f-2d59-21ed-066c-1e188f9a8cad

 

Ref: https://bitbucket.org/anchor17/viewer-release-baking-updates/commits/ca8049747764e9c52d7d4729c6c9f85eaa20b8c4

 

[Vir Linden]

10 hours ago, Fem Darcy said:

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?

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.

[Vir Linden]

10 hours ago, Fem Darcy said:

Main suggestion:  I think this could be used in a way more useful way developing it a tiny more further.

Thanks! For feature suggestions I'd also suggest filing a JIRA. JIRAs are much more persistent, so for example if we flag something as "possible future work", JIRA is where we're going to find it later. At least for the initial release of bakes on mesh, we are not planning to add a general baking API.

[Blush Bravin]

12 hours ago, Fem Darcy said:

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.
 

I totally agree. I in no way want to hinder the progress being made with this project. I really believe it will be a mini revolution in fashion. I only brought up the security issue so that we could be thinking about it and together possibly come up with solutions to make the wide scale sharing of UUID more difficult. I am fully aware that there is absolutely no way to completely protect ones work.

[Stickman Ingmann]

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!