[BUG-7306] PRIM_ALPHA_MODE_DEFAULT to revert alpha to old "if the texture has an alpha mask, use alpha. If not, don't" behavior. #15036
Comments
Lucia Nightfire commented at 2014-09-18T13:42:20Z Alpha Blending is the default mode for both alpha and non-alpha textures. How would the proposed constant work specifically? |
winter.ventura commented at 2014-09-18T14:50:15Z, updated at 2014-09-18T15:01:18Z Please see the attached image to see the problem here. Notice that the camera angle never changes. A 'fresh' object, with this "Default" behavior is in the top row. If I apply a 24bit texture (no alpha channel), it appears solid. If I apply a 32bit texture(24 bit TGA with 8bit alpha channel), it appears transparent, which is to be expected. This is the "Normal" behaviour. Now let's look at the next two rows. In the second section, I've set the object's PRIM_ALPHA_MODE to "NONE". As you can see, the 24bit texture with no alpha channel appears solid, as you'd expect. When I apply the 32bit texture (same as before), the texture now appears to be solid, because the alpha channel is being disregarded. This is expected behavior. Now let's look at the bottom row. I've set the object's PRIM_ALPHA_MODE to "BLEND". In this case, the 32bit texture looks the way we'd expect it to. Once again it's back to being semi-transparent. But if we look at the 24bit texture, you can see that it's Z-fighting with other geometry behind it (same 'face', same texture). The viewer is rendering this object as if it had a 32bit texture.. a 24bit image with an "All white" 8bit alpha channel. The textures used in all three examples are the same on the left, and on the right. There is no alpha channel present in the textures used on the left, there is an alpha channel in the textures on the right. The camera angle does not change, this is not simply a matter of the z-fighting flickering visible in one shot and not in the others. Based on this experiment, I conclude that "PRIM_ALPHA_MODE_BLEND" is not the same as the 'default' state of the face. The "Blend" mode applies a "false alpha" to 24bit textures, the "None" mode strips alpha from 32bit textures. It is certainly possible to MANUALLY set 24 bit textured faces to "NONE" and 32bit textures to "BLEND"... But there's no setting that reverts the alpha rendering on that face back to it's 'default' or 'auto' state. The proposed constant would provide that option. |
Kyrah Abattoir commented at 2014-09-18T15:04:04Z Seconded! |
Lucia Nightfire commented at 2014-09-18T15:55:00Z I'm having difficulty creating this "false alpha" condition. |
winter.ventura commented at 2014-09-18T16:32:47Z, updated at 2014-09-18T16:57:56Z Literally the repo is:
However, it seems that this observed issue may actually be related to whether or not the affected face has a pre-existing Specular or Normals setting. I haven't gone into great detail to test every possible permutation, but you can see the results of my tests below. This seems to be more of a bug than a "Feature Request" now. Edit: I can't confirm that it's not the same bug, but I'm seeing "additional issues". They may be related, in fact I'd guess that they are caused by the root causes.. but the issues definitely cropped up from specifically playing with the PRIM_ALPHA_MODE function, and I may have more clues to tracking the source, here. |
Whirly Fizzle commented at 2014-09-18T18:30:04Z Hmm related to BUG-6187 & BUG-6649 I think? |
Strife Onizuka commented at 2014-09-21T02:28:37Z If PRIM_ALPHA_MODE_DEFAULT is needed a value of -1 seems reasonable. |
Maestro Linden commented at 2014-10-01T21:05:34Z PRIM_ALPHA_MODE_BLEND is used as the 'default' (non-material) value. The issue where a face with a 24bit diffuse map doesn't render with ALM enabled and the PRIM_ALPHA_MODE is set to PRIM_ALPHA_MODE_BLEND is a rendering bug, BUG-6187. The workaround for this bug is to always use PRIM_ALPHA_MODE_NONE when the diffuse map lacks an alpha channel. Here's a quick repro of BUG-6187:
|
Maestro Linden commented at 2014-10-01T21:11:30Z By the way, you don't see this issue when adding a material to a box with the viewer, because the viewer chooses PRIM_ALPHA_MODE_BLEND or PRIM_ALPHA_MODE_NONE on the face, based on whether the diffuse map has an alpha channel. The sim has no idea whether a texture has an alpha channel, so it can't copy this behavior. |
How would you like the feature to work?
PRIM_ALPHA_MODE_DEFAULT (value -1?) would be a flag for the PRIM_ALPHA_MODE command, that would revert specified face to the classic alpha-handling mode, where the texture itself determines the rendering mode, based on whether the texture has an alpha mask or not.
Why is this feature important to you? How would it benefit the community?
Currently, you can use PRIM_ALPHA_MODE to switch into the new alpha modes, like the wonderful new "PRIM_ALPHA_MODE_MASK" and PRIM_ALPHA_MODE_EMISSIVE. You can also switch back to either "BLEND" or "NONE" modes. Unfortunately, there's no way to switch back to the "DEFAULT" mode that the face came with.
A face set to "MODE_BLEND" for example, if you drop a non-alpha texture on the face, it's still using the "blend" mode (and can z-fight, be culled by an invisiprim, etc). Likewise, if you set the face to "MODE_NONE" that z-fighting will go away, but if you later place a texture with an alpha-layer on it, the image will show as if the alpha has been disabled.
There's no way to revert that face back to the traditional behavior. Addition of PRIM_ALPHA_MODE_DEFAULT would correct this oversight.
Attachments
Links
Duplicates
Original Jira Fields
The text was updated successfully, but these errors were encountered: