|
|
|
[
Permlink
| « Hide
]
uchi desmoulins added a comment - 19/Apr/08 07:42 PM
Here I've attached 'Alpha Sorting - Linden Trees.png' demonstrating that Linden Trees, with their alpha textures, are able to utilize the zbuffer. No sorting problems here.
Attached 'Alpha Sorting - Typical.png' demonstrating alpha sorting the way we're used to it, where the sorting is practically random! The object doesn't exist at all in the zbuffer, but, if you enable "Pick Render" (accessed through Advanced->Rendering->Info Displays), suddenly the textures appear in a stencil-like format and are sorted correctly. The textures are visibly seen intersecting through one another.
Gee, I want an option to STOP having the linden trees use a 1-bit channel because it makes them look horrible.
Plus, it's likely what's making them turn the ground behind them semi-transparent. Ironically, you COULD make alpha textures where 1-bit alpha works just fine, for windows and things where you don't need to antialias the edges. But leaves and grass are a really bad application of it. Argent, Uchi's suggestion does make a lot of sense. 1-bit alpha channels are part of the standard feature set of any game related 3D engine for many years now, because it's a way to address the alpha sorting problem that is inherent in today's hardware rendering. It absolutely should be implemented in SL, since designers who know what they're doing can produce much more convincing effects with low rendering cost.
Leben: I'm not arguing with Uchi. I'm agreeing with him, just noting that Linden Labs is using them in a place where they aren't really well suited, while not making them available in places where they are.
Very useful, I figure gif's would get the 1 bit sorting (as thier transparency is 1-bit) if they could be uploaded but they the ability for many colors, is it possible to create a targa with a 1-bit alpha channel?
PNG-8's use a 1-bit alpha channel, however they are resolved to 8 bits during upload. (its was a decent attempt) Actually it's possible to just do a check for full transparency and generate a 1-bit map out of any transparent image on SL now. In that case, perhaps a multi-pass render using the 1-bit map to do alpha sorting and then the regular alpha map for blending would be possible. It might even let me stand on a mostly opaque platform (like a dirt path which a friend has made, with fades edges) without my tail (uses alpha texturing, as most canine flexi-tails do now adays) blending against my avatar and disappearing against the pathway. You'd just have to check for 0 transparency to draw a 0 bit, and anything higher would be a 1. Or for more granularity, perhaps a user setting to change the threshold at which 1 is set (like 127, half transparent).
Uchi just directed me to this jira -
there's an identical task in our internal jira - the concept is to provide an option in the texture parameters to switch between alpha-blending and alpha-masking. when it'll get done is anyone's guess, but 51 votes is nothing to sneeze at. useful link about 1 bit alpha for Direct3D (explains well)
http://msdn.microsoft.com/en-us/library/bb147243(VS.85).aspx useful link about alpha to coverage (how MS solved (kinda) the alpha problem) http://msdn.microsoft.com/en-us/library/bb205072(VS.85).aspx yus I know we are using OpenGL. But they are informative about the alpha issues we're facing. http://www.humus.ca/index.php?page=3D&ID=61
OpenGL alpha to coverage Hypatia Callisto, that doesn't seem to hard of a fix, if anyone is savvy enough on the viewer code they could attempt to impliment that and see how it goes, assuming SL uses multiple samples. It might also improve the enlargement of tranparent textures.
Another awesome feature that would make builders so happy. Including me! Has there been any development or work around on this? I see the last entry was since July and we've been through a few viewers since then.
I believe there are more pressing matters to deal with first before worrying about this, but I believe in fixing this it will also fix the issue where alpha prims interfere with water in world water and what not, so, in short, this issue will receive my vote.
Since it's clear from the fact that LL has once again closed
 I voted for this, but I think it would be better if instead of fixing a texture to be 1bit alpha'd or not on upload. a checkbox would be added to the texture tab sp images with all range of alpha could be used with 1 bit alpha if desired, or perhaps have both options, so if people want they can have the upload proccess modify the alpha of the image
I agree. But then where exactly would we put the checkbox? That's by FAR the biggest obstacle in having this feature implemented.
Ideally though, there'd be a checkbox and a value dictating at what point alpha is rejected. I'm no expert on all the tech stuff but I can totally appreciate this discussion as someone who likes to design clothes and things in SL.
It seems to me that the 1-bit or 8-bit checkbox belongs on the Texture panel and not on the upload. Isn't the transparency channel always going to be 8-bit when exported from various programs? If I use Photoshop CS2 and save to TGA, it's a 32-bit to support alpha. So it should be the SL side where you decide to use that file as 24-bit RGB + 8-bit alpha or 24-bit RGB + 1-bit alpha. It's up to the creator to make sure, if she/he intends the alpha to be 1-bit, that the channel only contains black or white pixels. Maybe in implementing a 1-bit alpha feature on the Texture panel, SL arbitrarily does a +/- 5% around 50% gray to decide how to render an 8-bit channel as 1-bit? After all, isn't it the object that's carrying the information about how the texture is to be rendered?? I could live with something like that in trade for simplicity. Again, I don't see the point in arbitrarily forcing the upload process itself into an 8-bit vs 1-bit decision. Does this make sense? is it would make this feature arive sooner, have just a checkbox at first, and continue to work on getting an slider for setting the exact threshold, and yeah, in the texture tab is where I was thinking about having it
I changed the tittle since the previous tittle might be (miss)interpreted as taking a texture and using it as the alpha channel of another texture instead of being about using 1 bit alpha channel
I agree with Tigro's title change and have also edited the description to include a different approach to making this happen.
Yes I agree snickers, there's no foolproof way for software to determine that an alpha channel is supposed to be 8 bit or 1 bit with any certainty. And having some textures uploaded with 1 bit and some with 8 bit would in effect create a new asset type. It would make more sense, and be more useful/flexible to have this attribute specifed on the edit pane on a per-face basis.
There's a bit of misunderstanding on what treating textures as having 1 bit alpha actually requires. There is no requirement that your textures actually have 1 single bit for alpha, they are only treated that way at the end with the masking. Alpha masking works as follows in OpenGL:
1) Disable blending (this makes your polygons completely opaque with no partial-transparency) This means that a texture with a one bit alpha will have the texture's pixels always be 0 or 1.0, and fail or pass accordingly. However you can use any texture in this fashion, but with the caveat that pixels that have an alpha between 0-0.5 will not be drawn at all and pixels with an alpha of 0.5 or greater will be drawn as fully opaque with no transparency. To sum up, whenever we mention 1 bit alpha masking, we mean treating the textures AS IF they had 1 bit for alpha, NOT allowing for specifically created 1 bit alpha textures and requiring them to actually only have 1 bit for alpha. BigPapi,
This makes my edit to this issue even more appropriate since I added item #2. From your description, #2 is the correct approach – or would be – should LL add this requested feature. As I said in one of my previous comments, no program I work with can specifically create a texture that has essentially a 24-bit + 1-bit channel scheme. It's always going to be 32-bit with the alpha channel in 8-bit. It would be up to the texture creator to make sure their textures had only black and white pixels in the alpha IF they intended it for use as a 1-bit alpha test mask. The implementation issue is up to LL to allow that choice in the Object Texture tab, right?? The technical term IS called "Alpha Masking", so lets continue to just call it what it is.
 I have searched and searched and there is no general agreement that "alpha mask" always means 1-bit. Thus, I think the title change leaves this ambiguous. I have found the terms "alpha blending" & "alpha masking" – "alpha mask with blending" & "alpha mask with testing" – "alpha channel with blending" & "alpha channel with testing" – "8-bit alpha maskiing" – "8-bit alpha channel".
Here's what I do know as a graphic artist. In Photoshop (and most 2D paint programs) that regular content creators like me use, the term "Mask" by default is an 8-bit grayscale alpha channel. While Big Papi may be "technically" correct (and I don't think there's agreement on that), the understanding level is lowered. So for clarity, I propose one of the following: Allow alpha channels in textures to be used in either 8-bit blending mode or 1-bit masking mode (user selectable). Allow user to select alpha mode (8-bit blending or 1-bit masking) in textures with alpha channels. Slight modification to remove the ambiguity that bothered Tigro, while retaining the correct terminology for Uchi.
 Argent, I think my title proposal would have been even more unambiguous...
"Allow user to select alpha mode (8-bit blending or 1-bit masking) in textures with alpha channels." The problem with your change is that the feature (1-bit alpha masking) apparently already exists – Linden trees use it. So the point of the JIRA is to allow the content creator some sort of access to it. But I'm surrendering on doing anything more with this Jira since everyone seems to have their own personal definition of what the proper verbiage is. @BigPapi Linden Since VWR-812
is being worked on and will be incorporated into 1.23, anyone know if this one will go along with it?? @snickers - To clarify the back end functionality to allow VWR-812 to occur is a part of 1.23. Actually exposing the ability to use it needs to wait until 1.23 is the minimum viewer version available for SL, since otherwise alpha masked avatars will appear broken for pre-1.23 viewers.
This jira won't be a part of 1.23, but will be worked on after the successful completion of VWR-812 and other tasks. Actually there is an option in DebugSetting (RenderFastAlpha). Small alpha textures at a distance turn into this "masked Alpha". And it assumes the %50 gray as the cut off for being visible or not.
@gearsawe Correct, but that is an opt-in client side feature that applies to all visible content (often visually breaking other things as well). This jira requests the ability to have this effect be inherent in chosen textures, not something opt-in or opt-out globally.
This feature request has been here for well over a year. It seems like such a simple thing that could have a dramatic impact on the quality of many builds. The unavoidable alpha texture flutter we have now... I'm really sorry, but its an embarrassment both to content creators and to SL. It would be nice if a LL dev could at least comment on the actual difficulty in implementing this (as opposed to my removed perception.) Is there some difficulty with adding a bitflag or something where an image is stored? Did the LL viewer GUI run out of checkboxes?
Sorry. But... grrr! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Allow Alpha Channel of Textures to be used as a 1-bit Mask (Alpha Masking)
