RuthAndRoth / Ruth

Virtual World Mesh Avatars
26 stars 15 forks source link

Default Texture mode of Alpha Blending or Alpha Masking with Cutoff 128? #36

Open aiaustin opened 4 years ago

aiaustin commented 4 years ago

I had thought that Ruth2 and Roth2 mesh bodies and parts set for bakes on mesh would need to have their textures set to "Alpha Blending" as otherwise, I thought that we could not apply any alpha masks to the body to hide elements without using the alpha cut capabilities via a HUD.

Any clothing with partial alpha, such as lace trim on a skirt, otherwise appeared to be problematic and not everyone would have modify rights to alter the clothing textures settings to try to get something compatible.

Then I came across an issue where wearing a skirt object blanked out the underlying mesh parts with alpha blending set. See

https://jira.secondlife.com/browse/BUG-228209

It was pointed out that Alpha Masking with a cut off set to any value but the default of cutoff 0 would make this work as expected. I tried setting Ruth2 and Roth2 BoM textured bodies and parts to Alpha Masking with Cutoff 1 and it does seem to work correctly.

Anyone have experience of this? It could be that we should make the default for the next Ruth2 and Roth2 be Alpha Masking and Cutoff 1 by default on all parts if this is valid?

AdaRadius commented 4 years ago

WOOT,. So it's a feature, not a bug? Nice. I haven't had time to play with BoM yet, but I'm looking forward to it.

LeonaMorro commented 4 years ago

I use alpha masking wherever possible. From my point of view there are only 2 reasons not to use it: a) you realy need something that is semitransparent b) if you have an (non mesh) object that uses the old formular for land impact calculations and you want that the object keeps it current land impact. (Changing the alpha blend mode to something other than "blending" forces the object to use the new formular for land impact)

For the value I would suggest a value of 128 (nice in the middle). A value of 1 can lead to unwanted visible/unvisible pixels if you use lossy image compression or if you trigger interpolation issues. For example: https://jira.secondlife.com/browse/BUG-225039

manwapastorelli commented 4 years ago

i will try this tomorrow. i thought when i applied a BOM texture it over rode the alpha setting. were you applying it after the BOM texture?

aiaustin commented 4 years ago

Once the head, upper and lower faces of a Ruth2 or Rith2 mesh body are set to BoM, for me I get the options for selecting Alpha Blending, Alpha Masking or None as the mode for each.

manwapastorelli commented 4 years ago

I have just tested this myself. We do not need to worry about alpha at any stage other than when first applying BOM textures. At least not in opensim. I don't have anything set up to test in SL quickly. Maybe someone there can test and clarify what I am about to say?

When you first apply BOM textures the alpha mode changes to "alpha blending". After this, you can change the mode to any alpha style you wish. Setting the alpha mode in the same instruction as the texture with llSetPrimitiveParamsFast doesn't help.

The alpha hud will work even if the alpha mode is set to "None". There is no need to have alpha turned on, on the main avi at all. Changing clothes or skins after the BOM texture has been applied doesn't change the alpha mode, it only occurs when the BOM texture is first applied. A simple workaround for this would be to add an extra instruction to a BOM applier setting the alpha mode to "None" after hitting a BOM button.

When dealing with the head, the eyebrows do need alpha blending enabled, the rest of the head does not. Rather than have alpha channels enabled for the whole head, I think it would make more sense to have the eyebrows link/faces set as an override in the script.

It is possible people might want semi-transparent avatars... ghosts etc. This could be achieved via a hud. It would just mean the alpha hud would either have to store the "last" value or just override any custom alpha settings.

manwapastorelli commented 4 years ago

An afterthought.. if we want to offer alpha levels as an option, it could be done in the same way my sample hud applier in my contrib folder works. The alpha level could be read from the hud directly, like the texture, glow, normals, specualar etc

aiaustin commented 4 years ago

Manwa, yes, it does seem that adding the BoM texture sets alpha blending as the mode. It can then be amended. And as you say we can use the alpha cut HUD completely independently of this.

But for BoM textures mesh bodies to work correcrtly, we cannot set the mode to "None" if we want to add alpha masks to hide certain parts of te avatar, e.g. using the alpha masks supplied with some mesh clothing for "classic" avatars. And I sugegst that we DO want this capability by default. We must use one of the alpha mode for all the BoM textured parts. "None" as a mode will not work. Having tested in SL and OpenSim using Alpha Masking (with a cutoff of 128 as suggested by Leona) for all BoM parts, that seems to work fine when clothing is added over the top of the mesh body that includes partial alphas such as brocade/lace edging or gauze elements.

So my suggestion for the next versions of Ruth2 and Roth2 (for BoM versions anyway) is that we set the mode to Alpha Masking with Cutoff 128. The Alpha Cut HUD will offer an alternative and complementary feature to wearing alpha masks on the underlying textures.

manwapastorelli commented 4 years ago

I don't understand unless the behaviour is different in SL, using system layer alpha masks on an avatar that is using BOM textures doesn't work. Instead of going transparent it turns the area black.

Screenshot from Gyazo

Am I missing something? As soon as I wear an alpha layer the whole body turns to alpha mode "none", if I then take it off again, it will return to whatever the previous alpha mode was before wearing the alpha mask.

aiaustin commented 4 years ago

It may be that you are using a version of the Firestorm viewer that was in flux as some serious issues with the way that the viewer side did baking for BoM were found by Beq Janus and fixed around 11th January 2020. See https://vcs.firestormviewer.org/phoenix-firestorm

aiaustin commented 4 years ago

Interesting... it was not the viewer version.

If you use a classic avatar first... set up a new alpha mask and tick (as an example) the lower to mask that part. The lower part of the classic avatar is transparent when the alpha mask is worn.

BUT, if you have on a mesh body and then wear the alpha then you get a different behaviour... the lower part (if that is the part ticked on the alpha mask) goes black (and the alpha mode is unavailable) rather than it going transparent as for the cl;assic avatar.

You CAN mask out the (e,.g.) lower by instead of ticking the box in the alpha mask actually applying a transparent texture to it.

Also, while editing the appearance it does correctly mask the lower part, its only when its saved and editing appearance is exited that the black shows.

This behaviour is the same in both Second Life and OpenSimulator.

Not sure of the best way to handle this. This should probably eventually via a Linden Lab SL JIRA.

aiaustin commented 4 years ago

Linden lab's own default viewer (6.3.6.535003) does not show this problem, so it may be an issue with the version of Firestorm up to mid January 2020?

When creating an alpha mask and ticking one of the mask out areas, the LL viewer shows the preview as transparent (the squares) not black and correctly masks the relevant mesh body part.

aiaustin commented 4 years ago

Ubit points out this was a known problem with the default transparency texture in 0.9.1.1 and before. It was corrected on 12th January 2020 in 0.9.2.0 Yeti Dev Master.

http://opensimulator.org/viewgit/?a=commit&p=opensim&h=62f3892cd7303c0af2b9970ce1b139e2ad3d3749

If all correct when creating a alpha channel you should see transparency, not black.