Bakes On Mesh - Releasing Soon!

[Ai Austin]

Just to be clear Vir, I was not expecting a HUD itself to be seen by other avatars at all.  Its the side effect of the HUD on the visual appearance of the avatar I was talking about. As other users can see something very different to what you see yourself.

[Sean Heavy]

28 minutes ago, Ai Austin said:

Sean.. try this.  Remove all BoM attachments and mesh body parts and any alpha... stay as classic avatar underlying that. Now add your HUD... and observe that in your viewer the part(s) of your avatar corresponding to those BoM textures you have included in the HUD will be hidden.

Ai, I get the same result. When wearing an all classic avatar *and* a HUD that has BoM textures; the same textures that are BoM'd in the HUD show as alpha'd out. For example, if my HUD has a head, lower, and upper BoM texture on it, the same items on my all classic avatar are alpha invisible in my view, but not alpha invisible in the other viewer logged in with an alt.

I would guess it has to do with *you* seeing the HUD instead of the alpha'd body, but the other user *not* seeing the HUD so nothing gets alpha invisible. It appears that the alpha of the classic body only gets alpha invisible if there is a mesh to see instead. (It's not smart enough to know that your HUD isn't exactly a mesh body; it just knows it's mesh, or prim, and visible to you.)

Edited August 30, 2019 by Sean Heavy

[Vir Linden]

On 8/27/2019 at 5:04 AM, Ai Austin said:

Can you enable the bakes radio button to apply one of the BOM textures to faces of objects in normal build mode , not actually attached at the time.

We are planning to change this in a future release, so you can flag non-attached objects as BOM.

[Vir Linden]

46 minutes ago, Ai Austin said:

Vir, I understand what you say, but the difference in behaviour I think is a bug.

I agree it's a bug, not sure what the right fix is.The standard behavior for BOM is that attached objects that use a given channel will cause the corresponding body region to be hidden. Standard behavior for HUD-attached objects is that other viewers don't know about them. We could change it so the avatar-hiding is not done for HUD-attached objects, which would make the behavior more consistent. Or we could discourage people from attaching rigged meshes to HUD attachments at all. Or some combination of those.

[Sean Heavy]

13 minutes ago, Vir Linden said:

I agree it's a bug, not sure what the right fix is.The standard behavior for BOM is that attached objects that use a given channel will cause the corresponding body region to be hidden. Standard behavior for HUD-attached objects is that other viewers don't know about them. We could change it so the avatar-hiding is not done for HUD-attached objects, which would make the behavior more consistent. Or we could discourage people from attaching rigged meshes to HUD attachments at all. Or some combination of those.

Vir, The HUD in question is not rigged, just normal mesh/prims with an assigned BoM texture, but still causes body parts to go alpha invisible. (Underline my addition.) If a there is a non-rigged HUD attached, it should not cause any classic body/clothing parts to go alpha invisible. I'm not sure what use-case there is for attaching rigged mesh to a HUD position.

Edited August 30, 2019 by Sean Heavy

[Ai Austin]

I think the best route would be the fix of “avatar-hiding is not done for HUD-attached non-rigged elements of objects which have BoM textures set”.

I can see many useful use cases for HUDs that show the current bakes textures in HUDs that can also apply textures directly on Mesh body parts, and HUDs that are used for monitoring purposes. I have already fixed several long term issues with basic body parts such s the classic feet, some skin issues, etc by seeing they were not baking as I expected.

Edited August 30, 2019 by Ai Austin
clarified that i meant for non-rigged BoM HUD parts.

[Ai Austin]

Just to be clear Vir, I was not expecting a HUD itself to be seen by other avatars at all.  Its the side effect of the HUD on the visual appearance of the avatar I was talking about. As other users can see something very different to what you see yourself.

And a HUD that is rigged would just be weird... mind you I have seen mesh body HUDs that have the head attached! You add the HUD and the rigged head part plonks on top of your body... take it off and you are decapitated!  First thing I do, if I have modify permissions, is unlink the head from the HUD part.

The HUD I was using to expose these issues is simply 11 linked prims textured to monitor the BAKES texture contents...

Edited August 30, 2019 by Ai Austin

[Henri Beauchamp]

@Vir Linden

There is a feature I already wrote about on this forum (it was last year, in the initial thread about BoM), that I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar.

I encountered no later than yesterday a use case for such bakes: a mesh body avatar (that lets you use the SL avatar head) with a half-neck mesh part, that allows a smooth blending of the mesh and SL avatar head/neck: when applying the baked head texture to the neck (so that the neck part of the mesh is colored like your SL avatar neck), the head vanishes... You can't use a bake on the neck, meaning that particular mesh body cannot blend properly at the neck level...

Other use cases would be mesh bodies with parts of the underlying avatar showing (think cyborg, amputated avatars, etc): for those you don't want the full upper or lower body to vanish when using baked textures on the mesh parts, but instead would use appropriate Alpha layer(s)...

The implementation would be trivial, as I see it; in the texture picker, add a ”auto-hide body part” check box (and IIRC that check box existed in the initial BoM implementation, but was not ”wired” to any code in the viewer), and when not checked, instead of applying, say, ”IMG_USE_BAKE_HEAD”, the texture picker would apply a new ”IMG_USE_BAKE_HEAD_NO_HIDE” UUID to the edited face. Then, in the viewer code, skip the body part auto-hiding when any of the ”*_NO_HIDE” bake textures are used instead of their counterparts.

Edited August 30, 2019 by Henri Beauchamp

[Ai Austin]

If default was that the tick box was ticked and all existing items had it set to on, but a user could edit/texture any face to set it off for new items and change previous previous items, then Henri’s idea would be compatible with all existing content too

[Ai Austin]

A good example of something that would benefit from @Henri Beauchamp 's suggestion of allowing a tick box to disable making the underlying body parts transparent when applying an attachment with a BoM texture would be elf ears. You might want them to have the HEAD bake texture applied, but leave the head visible.

[Ai Austin]

On 8/30/2019 at 5:44 PM, Vir Linden said:

Objects attached to HUD attachment points are only visible to yourself. This was originally by design - it's your HUD, why would anyone else see it? - but when the "HUD" object is a rigged mesh that displays on your avatar, the behavior probably isn't what most people would expect. We have a JIRA to look into this, probably by warning people when they add such attachments.

@Vir Linden can you point us at the JIRA number? I was not sure which seemed to be related to this issue.

[LucyHerne]

@Vir Linden I had an issue with my Slink body when BOM went live that meant I had to buy a set of Slink mesh hands. Before BOM I was using the Slink Mesh Body & Slink Feet but kept my System hands. With BOM I found my System hands were invisible because the BOM system was assuming the whole of my Upper Body was mesh. Is it possible the above suggestions from @Henri Beauchamp & @Ai Austin could be used to overcome this issue?

[Henri Beauchamp]

46 minutes ago, LucyHerne said:

@Vir Linden I had an issue with my Slink body when BOM went live that meant I had to buy a set of Slink mesh hands. Before BOM I was using the Slink Mesh Body & Slink Feet but kept my System hands. With BOM I found my System hands were invisible because the BOM system was assuming the whole of my Upper Body was mesh. Is it possible the above suggestions from @Henri Beauchamp & @Ai Austin could be used to overcome this issue?

Yes, this is typically a case that would be fixed by my suggested NO_HIDE set of bake UUIDs...

[Carol Darkthief]

On 8/30/2019 at 8:04 PM, Henri Beauchamp said:

@Vir Linden

There is a feature I already wrote about on this forum (it was last year, in the initial thread about BoM), that I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar.

I encountered no later than yesterday a use case for such bakes: a mesh body avatar (that lets you use the SL avatar head) with a half-neck mesh part, that allows a smooth blending of the mesh and SL avatar head/neck: when applying the baked head texture to the neck (so that the neck part of the mesh is colored like your SL avatar neck), the head vanishes... You can't use a bake on the neck, meaning that particular mesh body cannot blend properly at the neck level...

Other use cases would be mesh bodies with parts of the underlying avatar showing (think cyborg, amputated avatars, etc): for those you don't want the full upper or lower body to vanish when using baked textures on the mesh parts, but instead would use appropriate Alpha layer(s)...

The implementation would be trivial, as I see it; in the texture picker, add a ”auto-hide body part” check box (and IIRC that check box existed in the initial BoM implementation, but was not ”wired” to any code in the viewer), and when not checked, instead of applying, say, ”IMG_USE_BAKE_HEAD”, the texture picker would apply a new ”IMG_USE_BAKE_HEAD_NO_HIDE” UUID to the edited face. Then, in the viewer code, skip the body part auto-hiding when any of the ”*_NO_HIDE” bake textures are used instead of their counterparts.

I have a mesh body that has that neck feature, and a few other features that may be problematic. I was using your Cool VL Viewer, which I keep on my system as a sanity check, and I think I shall wait and see if experienced Creators can get Bakes-on-Mesh working. Seeing some of the things they do, I don't feel optimistic.

The particular mesh body also has overlapping sections. They map OK to the class UV map, but there are panels which are distinct, such as the front, sides, and back of the upper body, which overlap. It's one row of quads (which each comprise two triangles), I suspect it avoids problems with gaps at extreme shape settings, and the body looks fine with the pre-Bakes-on-Mesh tech. But go Bakes-on-Mesh and you get all the seams showing, internal to the upper body and at the upper-lower boundary.

I do wonder if the Lindens responsible really knew what they were doing. Or was it whoever set the test criteria?

Another reason I wonder about the Lindens is the 1024 textures on those freebie outfits for SL16B. 

 

 

[Vir Linden]

On 9/2/2019 at 4:24 AM, Ai Austin said:

can you point us at the JIRA number?

It doesn't look like there's a public-facing (BUG-) JIRA for this. Two different ones filed by Lindens at different times, both in the SL- project.

[Vir Linden]

On 8/30/2019 at 3:04 PM, Henri Beauchamp said:

There is a feature I already wrote about on this forum (it was last year, in the initial thread about BoM), that I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar.

Henri,

I think this is a good idea, and I've added it to our list of possible work for a Bakes on Mesh follow-on project.

We strongly encourage folks with these kinds of suggestions to file a JIRA about them; this gives the best chance of having the feature worked on. We will look through existing JIRAs when planning new projects, but it's much easier for us to miss something that's mentioned in a forum thread.

 

[Ai Austin]

On ‎8‎/‎30‎/‎2019 at 8:04 PM, Henri Beauchamp said:

I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar.

More UUIDs and fallback textures would be a bit of overkill don't you think?  Better if it can be done to have a (one bit boolean) flag (default "on" for compatibility) to let you turn off alpha hiding of the relevant part.

[Henri Beauchamp]

32 minutes ago, Ai Austin said:

More UUIDs and fallback textures would be a bit of overkill don't you think?  Better if it can be done to have a (one bit boolean) flag (default ”on” for compatibility) to let you turn off alpha hiding of the relevant part.

This is not how things work: for a start, your ”flag” cannot be transmitted together with the avatar bakes.

The new UUID set will be ”transparent” to the final users: it's the code behind the UI of the texture picker that will take care to pick the ”*_NO_HIDE” version of the UUID constants when the ”Auto hide body part” check box is un-checked. It will also be fully backward compatible with the current BoM implementation.

 

1 hour ago, Vir Linden said:

Henri,

I think this is a good idea, and I've added it to our list of possible work for a Bakes on Mesh follow-on project.

We strongly encourage folks with these kinds of suggestions to file a JIRA about them;

Frankly, this is so trivial (it can be implemented and fully tested in a mere couple of hours, at the very worst), that it would be a shame to wait months and an hypothetical ”follow-on project”  to have it...

I bet you will see more and more reports about ”BoM is broken because I can't have my feet/hands/head/whatever shown while using a bake texture on the rest of the mesh body part”...

As for the JIRA, I gave up using it, sorry. It does not even remember the login credentials over sessions (even with the ”Remember login” check box checked), and most things I reported on it over the many years I contributed to the SL viewer development and debugging got mostly ignored... This is without mentioning that (long time: 12 years already) viewer developers such as myself cannot even see or contribute to most of the JIRA issues (apart from the BUG ones, provided you are the initiator)... :-/

[Theresa Tennyson]

50 minutes ago, Ai Austin said:

More UUIDs and fallback textures would be a bit of overkill don't you think?  Better if it can be done to have a (one bit boolean) flag (default "on" for compatibility) to let you turn off alpha hiding of the relevant part.

Remember, it's not just you that this will affect, but everyone else as well. It's probably easier for other viewers to look for a texture UUID than to check a flag.

[Theresa Tennyson]

On 9/2/2019 at 4:41 AM, LucyHerne said:

@Vir Linden I had an issue with my Slink body when BOM went live that meant I had to buy a set of Slink mesh hands. Before BOM I was using the Slink Mesh Body & Slink Feet but kept my System hands. With BOM I found my System hands were invisible because the BOM system was assuming the whole of my Upper Body was mesh. Is it possible the above suggestions from @Henri Beauchamp & @Ai Austin could be used to overcome this issue?

In this particular case there's a problem. Right now I'm sure that you're using an alpha to hide your default body and leaving your system hands visible. When you do that with BOM, that means that the alpha is erasing everything that you'd want to bake onto the body. The only way that could work is by making it impossible to wear alphas on your BOM-enabled body and that's going to be one of the big benefits of it.

[LucyHerne]

@Theresa Tennyson @Vir Linden What I was hoping for was a way to be able to wear a mesh body but NOT mesh hands and have the System hands remain visible. Up until BOM went live (and I changed to a BOM compatible viewer because I love BOM) I used an alpha layer to hide all my System body but not the hands. That meant when I wore my Slink BOM mesh body my hands were invisible as well as the rest of my System body. So I bought a pair of Slink Redux mesh hands and solved the problem. I was asking the question for others who I'm sure will encounter this same problem and similar ones caused by the new system not recognising when a part of the System body is NOT wearing mesh. The system sees the Upper Slink Body as having the BOM texture and assumes the whole Upper System Body should therefore be invisible. I hope this makes sense. 

Edited September 3, 2019 by LucyHerne

[Theresa Tennyson]

Just now, LucyHerne said:

@Theresa Tennyson What I was hoping for was a way to be able to wear a mesh body but NOT mesh hands and have the System hands remain visible. Up until BOM went live (and I changed to a BOM compatible viewer because I love BOM) I used an alpha layer to hide all my System body but not the hands. That meant when I wore my Slink BOM mesh body my hands were invisible as well as the rest of my System body. So I bought a pair of Slink Redux mesh hands and solved the problem. I was asking the question for others who I'm sure will encounter this same problem and similar ones caused by the new system not recognising when a part of the System body is NOT wearing mesh. The system sees the Upper Slink Body as having the BOM texture and assumes the whole Upper System Body should therefore be invisible. I hope this makes sense. 

It does. The problem you were having is doing what you are asking for requires two opposite things to happen at the same time - the texture on your system body needs to be erased to hide it under your mesh body, but you need an un-erased texture in those same areas in order to have something to "bake" onto the mesh body. Right now BOM works around this by using a separate way of erasing your system body that doesn't require worn alphas, but the way it works means that the entire texture for that part of the body becomes invisible.

There is a theoretical way of making what you want happen - by using an alpha to hide part of your body, and making the BOM attachment ignore alphas altogether. (This won't work now because of the way BOM automatically hides part of your body now.) However, if this is done, the BOM body can't recognize worn alphas.

[LucyHerne]

Ty Theresa for that explanation. It was a small niggle and, frankly, having BOM live is worth far more than the 800 odd lindens I paid for a pair of Slink mesh hands. I am having way too much fun going through my Inventory and unpacking all the old clothes, footwear and skins that I've put away over the years. Of course I have alpha layers to create but Slink's helped there supplying basic alpha layers and textures plus I've made quite a few alpha layers myself in the past. Oh, and I have to Edit a lot of the foot shapes / system shoes that come with footwear because they use the white default texture which now shows up on mesh BOM feet and need to be changed to transparent! Easy till you come across one that's No Mod.

Edited September 3, 2019 by LucyHerne

[Ai Austin]

@Vir Linden I wonder if you can get whoever looks after the Wiki to update the UUIDs for the BAKES channels/fallback textures to the up to date ones... and add the extra 5 added BAKES?

https://wiki.secondlife.com/wiki/Internal_Textures

 

[Vir Linden]

4 hours ago, Ai Austin said:

I wonder if you can get whoever looks after the Wiki to update the UUIDs for the BAKES channels/fallback textures to the up to date ones... and add the extra 5 added BAKES?

We'll take a look at that, thanks!