The Battle of the Alphas! (who's on top?) :)

I've posted here before discussing the issues we all have with textures possessing alpha channels (transparencies).

Why, for the love of God can’t LL figure out how to correct the alpha-fighting in the SL engine? Other “games” use alpha channels in their dynamic models, and you don’t see graphical anomalies, why can’t LL figure a way to fix this.

I was once explained about DirectX and OpenGL, and how because of the choice LL made about graphical display, alpha channels tend to have issues and always have. So, basically, anything running on OpenGL will always have alpha fighting?

I think that stinks. There are so many things created using alpha channels in SL—and this magical effect is dispelled by graphical anomalies. This needs to be remedied.

If it is an OpenGL issue, than how come SL is the only place I’ve witnessed such anomalies? Are you to tell me that (somehow) other content using OpenGL has been so cleverly designed, that you never get two alpha channels lined up with each other? Impossible.

I want answers LL!

I’m just venting. I love you all.

I'm not sure how other games or whatever solve the alpha glitch with OpenGL but a friend in SL sort of explained how to get rid of the problem in SL............she's some graphics whiz in RL. Make a prim with no apha at all (the basic plywood prim is fine)............make the full length or height of your prim with alpha and very narrow and thin. Push it inside the prim that is giving you problems.......bury it, so to speak. It works.

Maybe that's what the pros do for those games to eliminate the problem.........I don't know. But we are mostly amatuers here so we have to try out stuff.

Good luck....hope my second hand tip helps.

I don't see how that work-around is supposed to work....you still see right through the original prim with the alpha-channels, and now see the new prim.

I'm trying to make a window box with flowers. When I put it in front of the window, well, I have problems, as you know.

Yes Idunna, this is a problem. You think you have problems with your flower box? My entire AV is created with alphas, and every time there is an alpha behind my AV, the magic of my disguise is revealed.

I have plants in front of windows too…it’s a glitch in the OpenGL code…and unless Second Life goes DirectX only…hell, I don’t know.

I don’t think there is a valid work-around here. You just have to place objects with this glitch in mind. It sucks too, because I work heavily in custom light and shadow work…and anytime there is an alpha in front of, or behind my light and shadow work, complications arise…

Humbug. Humbug I tell you.

The reason LL hasn't solved this problem is because NO game maker has. It's certainly possible to do "the right thing" as far as ordering how alpha textures are drawn, but unfortunately, the only algorithms known for doing this take a ridiculously long amount of time... your framerate would be in the sewer. It's generally accepted that there's no efficient way of sorting alpha-channel surfaces in a 3d scene efficiently enough for a real-time game. Yet.

The reason other games still use alpha channels and use them effectively is that their makers are very careful to avoid creating scenes in which the inaccurate alpha-texture rendering is actually noticeable. They try to avoid having more than 2 alpha channels visible at any time, and they're careful about the angles those textures are seen at. In SL, there's nothing stopping you from making something that exacerbates the alpha flaw... except your own sense of aesthetics.

Right, the problem in SL is all the Bozos running around creating content willy nilly!

(signed, a Bozo)

i cant log in sl they said 11 am and so i cant get n sl

and directx X is a big no no anyway, it's crap anyway.

I ran into the alpha issue a long time ago, and my "fix" has always been to avoid overlaying multiple alpah channeled items. I once had a clockface that "had" to be alpha channeled, but cant do that, because the clock hands are alpha'd too and "disappear" behind the face, so, to fix it, I made the shape of the clock face in prims, and applied the clockface (non alpha'd), to each prim, and adjusted the offset and scale such that it recreated the same effect without using alpha. In other words, I recreated the shape of the face with prims, then textured each piece with that part of the face. Anyways, the lesson here is don't whine about it, since there's nothing that can be done, back off, think about it a bit, and ususally u can find a way around it.

Now I'm not going to pretend I understan anything about programming or how alpha channel objects work in the game environment. I merely was thinking logically that the crux of the problem seems to be that two alpha objects fight to be in front of each other as to which one takes precedence.

I notice that I can force precedence by clicking on the texture I want to take precedence, and it jumps into focus and pushes the other behind. At least until I or the camera moves again.

Surely then (coding aside, I am sure it is complex) the answer is for the programme to decide that if there are two alpha channel objects fighting for precedence, then the one closest to the camera viewpoint should win.

Now, as I said, *how* you would implement that I don't know, and I don't expect it would be simple, but logically, surely that is what you need to aim for.

The secret =is= who is on top. From the viewer perspective, the alpha textured/transparent object that is closer to the avatar is going to appear in front of other alpha textured/transparent objects. That center is the x,y,z position.

This may be my first pro-huge prim argument! For application of a large pond surrounded by willow trees, all with alpha transparencies, if the pond water is created from 10x10x.01 prims the alpha textured tree branches that are further than the center of a section of pond water will appear behind the pond water prim when visually, they should not. But, If I manipulate a huge prim, the tree branches look correct.

The alpha sorting seems to be correlated to the prim center coordinates...

I posted a link to a solution earlier.

It only works on alpha images where the alpha channel is always 0 or 255

I can't find a link at the moment, but the idea was to have a checkbox that would cause the graphics engine to draw the alpha "cut out" images using a filter during the normal non-alpha pass.

Edit:

/13/90/187723/1.html

http://www.opengl.org/wiki/index.php/Alpha_Blending#Another_Good_Trick

I don't know much more about the technical aspects of this, but I believe that's exactly the crux of the issue. The question of "which one is closest to the camera" is much harder for a computer to determine than you think.