Jump to content

Materials Project Wishlist


Ashasekayi Ra
 Share

You are about to reply to a thread that has been inactive for 4160 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Ah, I'd forgotten that trees utilize 1-bit alphas. Thanks for the reminder.

I didn't know that it treats 8-bit as 1-bit under certain circumstances.  If that is indeed the case, then the suggestion of making into a user-controllable setting should be pretty easy to implement, at least in theory.

Link to comment
Share on other sites


Chosen Few wrote:

What you're referring to is properly called a 1-bit alpha map, as opposed to the 8-bit alpha maps that SL currently supports.  1-bit alphas are pure black and white, no grayscale.  The transparency per pixel is either full on or full off, no blending.

[...]

I've never seen it referred to as a "hard alpha" before, by the way.  Out of curiosity, where did you pick up that term?

 It's normally referred to as alpha testing. 

 


Kwakkelde Kwak wrote:

SL already supports 1 bit alpha. Since "the olden days" it has linden trees. Since more recently SL turns 8 bit alpha channels into 1 bit sometimes. Someone explained when and why, I'm sure someone will respond again. It's not a setting you can turn on and off though and I think it only works with either certain viewers or certain display settings.

More correctly the viewer doesn't turn anything into 1 bit, it just switches from alpha blending to alpha testing (i.e. the data stays the same, it's just changing how it's drawn). The settings are called 'Automatic Alpha Masking', there's separate ones for deferred and non-deferred. You can find them in develop->rendering.

Link to comment
Share on other sites


leliel Mirihi wrote:

More correctly the viewer doesn't turn anything into 1 bit, it just switches from alpha blending to alpha testing (i.e. the data stays the same, it's just changing how it's drawn). The settings are called 'Automatic Alpha Masking', there's separate ones for deferred and non-deferred. You can find them in develop->rendering.

Good to know, that's the display settings I had buried somewhere in my memory. Still it doesn't work on all alpha maps and it doesn't only work on alpha maps that were only black and white on upload. Any idea what the criteria are for the viewer to prevent blending?

Link to comment
Share on other sites

LL has adjusted the heuristics several times since the feature was first added in v2. I can't remember what the exact values are now but basically something like 'if overall alphaness is less then X use alpha testing'. It's supposed to look for alpha channels tha have very little grey in them and are thus mostly black and white since those would be the least changed when using alpha testing. It seems to work well enough now in v3 but I've never really tested it.

Anyway that's kind of off topic. The real feature that was being asked for was a per material flag to specify whether to use alpha blending or alpha testing. I think this is a worthy addition that should be at the top of the list along with normal and spec maps. It would greatly increase the amount of flexibility creators have, allowing them to both optimize for performance (alpha testing is much cheaper then alpha blending), as well as give them the best tool they'll ever get for minimizing alpha sorting problems.

It's also an indirect prerequisite for using the 'true' solutions to alpha sorting. There are several ways to fix alpha sorting but they either require tight control over the content creation pipeline, which is not possible or wanted in sl, or they have high performance costs that make them impractical to use in sl. By allowing creators to specify which to use, and encouraging them to use alpha testing instead of blending whenever possible, would greatly lower the performance cost of the true solutions (i.e. the less there is to sort the cheaper it is).

Honestly I'm rather disappointed that LL still hasn't added this feature, or even talked about it other then a few odd comments in jira. It's not exactly a hard thing to add, assuming they don't have to change the wire protocol to make room in the object description packets for the flag.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4160 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...