Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[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

Closed
1 task
sl-service-account opened this issue Sep 18, 2014 · 9 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Sep 18, 2014

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
Field Value
Issue BUG-7306
Summary PRIM_ALPHA_MODE_DEFAULT to revert alpha to old "if the texture has an alpha mask, use alpha. If not, don't" behavior.
Type New Feature Request
Priority Unset
Status Closed
Resolution Duplicate
Assignee Maestro Linden (maestro.linden)
Created at 2014-09-18T08:53:27Z
Updated at 2014-10-01T21:11:29Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-09-18T08:42:19.506-0500',
  '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.',
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  '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.\r\n\r\nA 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.\r\n\r\nThere\'s no way to revert that face back to the traditional behavior. Addition of PRIM_ALPHA_MODE_DEFAULT would correct this oversight.',
}
@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2014-09-18T13:42:20Z

Alpha Blending is the default mode for both alpha and non-alpha textures.
Alpha mode and cutoff persist with scripted changes to alpha or non-alpha textures.
Changing to non-alpha textures through the viewer will revert alpha mode and cutoff to default.
There may be applciations where a persisted value is desired with scripted texture changes.

How would the proposed constant work specifically?

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

Kyrah Abattoir commented at 2014-09-18T15:04:04Z

Seconded!

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2014-09-18T15:55:00Z

I'm having difficulty creating this "false alpha" condition.
Can you provide the steps for a repro.
Also, does this repro on legacy prims and sculpts as it does on mesh?
Can you also confirm that what you're seeing isn't the same issue as described in https://jira.secondlife.com/browse/BUG-6061
Sorry in advance for any misunderstanding.

@sl-service-account
Copy link
Author

winter.ventura commented at 2014-09-18T16:32:47Z, updated at 2014-09-18T16:57:56Z

Literally the repo is:

default
{
state_entry()
{
llSetPrimitiveParams([PRIM_ALPHA_MODE, ALL_SIDES, 1, 0]);
}
}

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.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-09-18T18:30:04Z

Hmm related to BUG-6187 & BUG-6649 I think?

@sl-service-account
Copy link
Author

Strife Onizuka commented at 2014-09-21T02:28:37Z

If PRIM_ALPHA_MODE_DEFAULT is needed a value of -1 seems reasonable.

@sl-service-account
Copy link
Author

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:

  1. Rez a box (the default plywood texture does not have an alpha channel)

  2. Save the below script in a box

  3. Observe that face 4 does not render
    {code}default
    {
    state_entry()
    {
    // Set face 0 (+z direction of box) to PRIM_ALPHA_MODE_BLEND
    // This should be a no-op when there is not already a material present
    llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ALPHA_MODE, 0, PRIM_ALPHA_MODE_BLEND, 0]);

     // Set face 4 (+x direction of box) to have a normal map and to also have PRIM_ALPHA_MODE_BLEND
     // Due to BUG-6187, this face does not render properly (appears 100% transparent when 'highlight transparent'
     // is enabled)
     llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_NORMAL, 4, "0a60674c-16ab-eb44-8894-09b1e304f107",
         <1,1,0>, ZERO_VECTOR, 0.0, PRIM_ALPHA_MODE, 4, PRIM_ALPHA_MODE_BLEND, 0]);        
    

    }
    }{code}

@sl-service-account
Copy link
Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant