the Alpha textures problem

Hello I am sure all of you know the alpah texture clipping when two transparent textures overlap in the line of view , I would like to ask if there is any trick or solution to minimize or counter completely this problem , I am interested into that becouse its one thing that prevents a lot of trasparent overlapping prims to show correctly .....

I know that this is a bug mostly of SL couse in other games there isnt such a poblem , the only oine I saw it in is oblivion but I solved it by detaching poligon faces from and reworking the normals over the surface of the object this solved the problem with no other graphical issues , but here in SL we can't import poligons neither detach faces or the like , is there any other way that we can study around to fix or minimize this problem?

The alpha problem isn't an SL issue, it's an OpenGL issue (I think it's Open GL, definitely not SL though).

The reason it seems worse in SL is that most of SL is not created by professional 3D artists. I have alpha problems because I don't know enough about it to design my builds so it doesn't happen. And even if I did, the guy on the next parcel could mess up my careful work by the way he used alphas.

Most games are designed by people who really know how to minimise the alpha problems, and the whole game can be designed with that in mind, and properly tested to check for bad instances of the problem. In SL, the designers are the players, and most of us are amateurs when it comes to things like this.

There are things that can be done to reduce the problem, and doubtless someone like Chosen will be along shortly to explain some of them, but most of us simply don't know enough, or have the time to learn enough, to really deal with it.

Well said, Wulfric. The alpha sorting problem in SL is largely a price we pay for having more free will. If we were living in a world that somebody else built, and were just playing in it, there would be fewer of these problems. Let amateurs like me be creative, and you have to put up with some clumsiness.

The best advice is the most obvious .... avoid designing things that have overlapping textures with alpha channels in them. The best way to do THAT is to avoid using transparency unless you really need it.

The best way to avoid it is definitely that.

A lot of people use alpha textures to have walls with windows instead of a few more prims. What they don't realize until after they've made the textures or build is that while it saves prims, it looks worse. Always, unless EVERYTHING in the build is made to work without the alpha sorting problem, including furniture and deco, it's going to look worse than those few extra prims.

While that's not always the case - sometimes people have no choice but to use alpha for various things - it seems too common to me. People are always complaining about the problem with alphas in that kind of situation, when it's easily solved for architectural builds.

If you look in professionally created environments, in other games and SL both, they don't use alphas where they have those bad overlapping issues, because they know how to avoid it. In other games you won't find buildings with wall and window as one big alpha piece, it will be architecturally windowed, not texturally (OMG Firefox says that's a word..awesome!). This means you won't find the alpha overlapping problem in their environments, because there is no chance for it.

The best way to avoid the alpha overlapping problem is to not use them unless necessary, as already said. I figured I'd just explain a bit more.

Another way you can get the alpha sorting glithch even if you have no window or opening in, say, a wall. If you save the texture as 32 bit without any transparency evident you still have that alpha channel in the texture and subject to the alpha sorting. Save all textures to be uploaded to SL as 24 bit if you don't have transparent areas in it.

Everything Wulfric said is 100% correct, including the fact that I'd chime in.

As for how to minimize the problem in your own builds, there are only two things you can do. First, never use 32-bit textures unless you absolutely have to (and that includes adding in-world transparency to a 24-bit texture; it has the same effect). Second, build around the issue. If you've got two 32-bit-textured surfaces, don't let them overlap in space. If that means redesigning your structure, so be it. There are some designs that just can't work.

If there's absolutely no way to prevent two 32-bit-textured surfaces from overlapping, then put something 24-bit in between them. Depending on the specifics of the build, this won't always make a difference, but often it will.

Beyond that, there's really noting more you can do. And as Wulfric said, even if you make your own build perfect, your neighbor might not, and then you're still stuck seeing the problem on his stuff if not your own. And even if you and your neighbor are both super careful to make sure that both your builds don't have issues, either internally or with each other, someone wearing a big old pair of fairy wings or a poofy skirt or something can always wander in, and their outfit can cause problems while they're there.

Bottom line, build as best you can to avoid the issue, but accept that you'll never be rid of it entirely (at least not until OpenGL applications get more sophisticated in this regard).




On a side note, I think it's important to realize that as bad as SL might seem at first glance to be at alpha sorting, it's actually quite a bit better at it than most other realtime programs. From what I've been told, SL has got some pretty clever programming in place to maintain the best possible the balance between accuracy and rendering speed. There are other OpenGL programs in existence that can sort perfectly, but I know of none that can do it at speed with just any arbitrary number of surfaces. Maya, for example, actually allows you optionally to turn the glitch on and off in each of its viewer panes. But when any pane is set to sort perfectly, the entire program's frame rate plummets if the scene has more than a relative handful of transparent surfaces in it.

In SL, you're dealing with thousands of surfaces at a time. I've never actually thought about how many it is before, but when I think about it now, I'm actually quite humbled by just how fast SL is able to sort. What I'm about to lay out is a VERY unscientific accounting, but I think it's worth considering anyway.

If your draw distance is 512, and you stand at a corner intersection of 4 sims, you can conceivably see everything in all four, plus parts of the surrounding 12. Cut that in half to account for the fact that you can only look in one direction at a time, and you're talking a maximum of six sims at least partially in view. That's a possible total of 90,000 prims. But since it's extremely unlikely that 6 sims worth of people would ever arrange all their prims in such a manner that they would all be visible within a single avatar's viewing cone, let's cut that in half a couple more times. I'd be comfortable saying the practical maximum number of prims that would ever be in view at one time is around 22,500 or so. But that's just the maximum, not the average. The average is obviously far less than that, since most sims are not full, and since smaller objects do get culled over distance. So let's cut it roughly in half a couple more times, and call it an even 6,000. If even 10% of those have alpha textures facing the camera, that's 600 sortings that have to happen in the time it takes to draw one frame. And that's before you even begin to think about everything else it needs to do.

If you tried to do that much in Maya with accurate sorting turned on (glitch disabled), it would choke. So would SL. Computers just can't do that amount of calculation that quickly at this point in history. One day they will, but not yet. With that in mind, I think it's pretty impressive that SL operates in any semblance of real time at all.







P.S. Minor Technical Vocabulary Note: "Clipping" wasn't the best choice of words to describe the problem. In 3D graphics lingo, to clip means to select which areas of a scene are drawn and not drawn. For example, In SL, when you set your draw distance, what you're actually doing is altering what's known as the "far clipping plane", or as some might call it, the "far clipping radius", or just "far clip" for short. The word that would have been the proper choice here is "sorting", not "clipping", since the problem is a result of the order in which surfaces are drawn.

I do not think the problem is opengl , I have worked with alpha in a bunch of other games ,mostly morrowind and oblivion , I also checked crysis and ok no alpha problem,Sometimes come out with bad designed normals of poligon surfaces and I ffixed it by detaching faces... inall ways I noticed a waay to minimize prob in sl is to use different surface with textures trasparency not directed along same normal ans being different surface butthis immmplies more prims to be used... the main problem is clearly seen with plants when u crossposition 2 prim surfaces one onthe other u get alpha problem, instead if u use4 prims aligned like cross u get no alpha prob , this forces u to use more prims tough.
AN evidence that is a sl bug is from linden plants , they use many facets with alpha trasparency and no problem... may be if dds format will be inttroduces we could get an improvementb iin texture

Naiman, I'm about 95% sure that all three of the games you mention use Direct3D, not OpenGL. Do you have any evidence that they are indeed OpenGL apps?

The OpenGL website specifically mentions Oblivion as NOT an OpenGL program, so I think we can rule that one out entirely. http://www.opengl.org/pipeline/article/vol003_9/

According to this, http://morrowind.ttlg.com/mwfaq.shtml#9.2, Morrowind is also NOT OpenGL.

And according to Wikipedia, CryEngine 2 is also Direct3D-only. http://en.wikipedia.org/wiki/Crysis#Game_engine I believe CryTek is in the process right now of porting it to OpenGL so it can run on the Playstation 3, but I don't have confirmation on that.

As for the DDS format you mentioned, I don't think it would make a difference. When all is said and done, it's just an image format. The format itself has no power to control how the engine renders it.


In any case, the alpha sorting glitch has been a well known OpenGL issue for many years. I'm sorry if you don't like that answer, but wishing it weren't so (which we all do) doesn't make it any less true.


As for your experiments with plants, I'm not sure why you feel adding more planes eliminates the problem. It doesn't. What it does do is increase the increase the likelihood that any given camera angle will be perpendicular, or nearly perpendicular, to one of the planes. Planes that more directly face the camera tend to render as "in front" of planes that are at more oblique angles, when all planes in question share the same center point. So the more planes you have, the more convincing your plant will be. But whether it's 2 planes or 2000 planes, you're still not solving the problem. You're just making it work for you more effectively with more planes.

What a surprise

That I'd be right, or that Chosen would pop in and explain it all properly?

"...evidence that it's an SL bug is from Linden plants..."
Actually, (Chosen didn't catch onto what you were saying here) Linden plants are a special case that render in a distinctly different manner. I don't know what to call it, but it's so strictly opaque-or-transparent that it's even devoid of all antialiasing. Avatar impostors use it too, and it either IS or at least once WAS applied to very small, distant alpha textures (because it's easier to render).

It's therefore no BUG that other textures don't render as 'flawlessly' as Linden plants, but you could reasonably request that this FEATURE ought to become applicable to individual prim textures (that is, if there's room for the feature in the UI...).

chosen about the trick to avoid as i said works if you use mire prims but not aligned along the same normals.... about morrowind , oblivion and crysis yes they are direct 3d samples...... then to se a more opengl sample you can check the many ogre 3d applications in particular pagedgeometry application... a sort of speedtree for ogre and no alpha problems there.... or you can check also project wish of the same engine... I am still convinced this is a sl unresolved bug than a opengl issue...

Unless I'm misunderstanding what you mean, then as I said, adding more prims doesn't make the issue go away. It just makes it more likely to work for you instead of against you.


I don't know enough about what PagedGeometry is actually doing to comment intelligently on it. From what little I've read so far, it seems it makes heavy use of impostor rendering, which basically means most of the trees at any given time are rendered as 2D images, rather than 3D objects. I'm not an expert on impostor rendering by any stretch, but I know that depth sorting can work differently with it than with purely 3D scenery. I wish I knew more about it to give a better answer, but I don't.


I looked at their website. Unfortunately there doesn't seem to be much to see on it. Can you point me towards any screenshots or videos demonstrating the game's alpha sorting capabilities? I watched both videos and looked at the small handful of images on the website, and none of them fit the bill. Got any better ones?

Alpha sorting problems apply to DirectX too. It's a fundamental issue of how videocards operate, not a software thing.

I don't know what naiman created in those other games so obviously I can't say why he wasn't noticing alpha sorting problems. It's possible that he simply wasn't doing something where problems would be apparent (in particular, his insistence that using more prims solves the problem makes me think he simply doesn't know what to look for,) or it's possible those game engines were doing some sort of pre-processing of the polygon occlusions (I've heard of this before) like BSP or something, in which case that couldn't apply to SL because you can't pre-process geometry that is created on the fly by users (just like you can't lightmap it etc.)


You are correct. You are describing masked transparency; this is distinct from alpha transparency. For people familiar with web graphics, think about transparency in GIF and in PNG. In the former there's only on/off, while in the latter there's shades of semi-transparent. Masked transparency doesn't look as good because there's no semi-transparent and thus no anti-aliasing, but as Al noted it has the advantage of being much simpler to render.

To understand why there aren't sorting issues with masked transparency you need to understand how videocards determine what to draw in front of what, and for that you need to understand the z-buffer. You can google that term; long story short, the z-buffer is how videocards do pixel accurate sorting of polygons, and the z-buffer can only be used with pixels that are totally opaque (ie. not alpha transparency.)

Thanks, Johan. I was hoping someone more knowledgeable than I on Direct3D (like you) would chime in. I really have no experience working with Direct3D applications, so I have very little understanding of where its similarities and differences to OpenGL start and stop.


Out of curiosity, since you say the sorting has more to do with the internal workings of graphics cards than the software engine, do you have any idea what Maya is actually doing when it's set to display accurate sorting? I don't know how it does it, but it works pretty flawlessly. Any insight would be appreciated.

My assumption (ie. I don't actually know this for sure) is that Maya doesn't use the z-buffer. The z-buffer is a feature of graphics cards used to speed up the rendering of polygons; if you don't use the z-buffer for sorting draw order and instead figure that out in a more brute force approach using your own code, it'll take longer to draw a frame but it'll also be more accurate.

Ah, that would make perfect sense, given the observed behavior. Thanks, Johan.

I am not insisting that using more prims solves the problem but to use more pirms oriented in differing normal along the surface of it ......

try 2 planes in cross with alphed texture of a plant for example and then try to put 4 planes of same texture in cross but attached by ony a side....
about the other game I show u this

http://www.theeasyco.com/view_full.php?obr=img_content/gallery/mb_04_1024.jpg

from motormax

http://www.alsbonsai.com/john/Jungle1.jpg

from pagedgeometry add on ...

I see lot of overlapping trasparent textures without this problem , I dunno if it holds a trick or a solution but nevetrheless looks good , may be something like that could be used in SL too , most of the application that would benefit by this is the vegetation I think ...


what about using a z sorting about considering the dimension of the surface and distance innormal projection by the viewer position?
or make use of glAlphaFunc ( GL_GREATER, 0.1 ) ; glEnable ( GL_ALPHA_TEST ) to prevent the pixels with a specified set of alpha to be in Z buffers. May be using just a 0 or 1 technique for alpha could work , we dont really need to make shades degrees of trasparencies for plants at least I guess....
or dunno .....

if in direct 3d there is a solution why cant be in opengl?

btw the dds textures I think would help a lot , couse not only they allow a size reduction according to mipmapping but also can allow a 2 bit alpha texturingto be simplier caught by the game engine , I guess this could help may be .....

this is actually something I can comment on intelligently (to a degree)

the reason both directx and opengl both have the alpha sorting problem is they, basically render 3d images the same way, namely rasterisation. the images you see on screen are not what you would think true 3d objects, but a series of clever tricks the graphics cards pul off to render them extremely fast.

as far as I know, the only way to render reflections, alpha's, refractions and other effects like that is ray tracing, which is wholly cpu dependent, and can't be done at all on the GPU, which I am assuming is why maya slows down to a crawl, am guessing it prolly uses some quick and dirty raytracer to get all the alpha's right.

I'm sure there is someone a lot more familiar with all the technicalities involved than I am who might be able to explain all the nitty gritty details.

there is a bit of a media war going on between nvidia and intel over it at the moment, intel wanna go raytracing cause they think cpu's may be able to render it realtime sometime in the near future, and nvidia don't, cause it would basically mean throwing out all their graphics cards and starting again from the ground up

I'm coming to this thread a bit late, but I've been making my first pieces of furniture, and I've been contemplating the alpha vs prims tradeoff. I've made few nice pillows and the like with ZBrush, but it's hard to get the Prim3Ds in ZBrush to make the straight edges you need for furniture, such as a mattress or a bed frame. So I'd been contemplating either (1) using basic SL rectangular prims and applying alphas to soften edges and add curves, or (2) resurrecting my dormant and uneven Max skills to make a sculpty mattress -- or getting more clever with ZBrush. It sounds like I should lean toward (2)?