Flickering alpha textures - Any kind of solution?

Jo Yardley · October 2, 2011

This has been adressed before, something that has been pestering us for ages.

When you look trough a transparent texture (such as a window) you see other 'outside' textures flickering.

I am not sure if this is viewer related or SL related, but it is not the colliding problem we have when you put two transparent textures too close, pretty much everything outside the window will flickr.

The weird thing is that there is a solution, but we don't know how or what.

Many of the old textures, like the ones made by Stinky Queso, don't have this problem at all.

I have been experimenting a lot and discovered that creating a texture in Photoshop with a 66% opacity has very little flickering.

What have your experiences been with this?

What is the best way to make a transparent texture without flickering in your opinion?

Void Singer · October 2, 2011

the 66% solution you noted has to do with with how partial trancency is treated... there probably a break point, and it should be just at or over 50%. that's one possible solution.

the thing I've noticed is that normal transparency doesn't usually result in the flickering behavior (just the overlap sorting behavior), but the special single bit transparency that's seen in the two well known "invisiprim" textures do seem to caus it in excess on large surfaces.

I have found that two textured surfaces facing each other with their outsides 100% transparent (by the prim control) seem to sort much better than other methods... I don't know if the non-facing transparency makes a difference, or the intervening extra transparency is somehow buffering the sort order, but it works quite reliably.

Jo Yardley · October 2, 2011

My windows are always complicated, I cant stand totally invisible windows and as I have many poor backstreet kind of houses who of course need dirty old windows.

The annoying thing is that some windows seem fine, others do not.

Some of the old windows that have been around for years got the trick, some Linden should know the trick.

Someone playing with textures for years should know it.

Because it CAN be done, we have seen other transparent textures who do not flickr with their background and who are not 100% transparent.

I keep experimenting, I'm not there yet.

Jo Yardley · October 2, 2011

Ok, it seems the lower the opacity is, the less the flickering is.

Right now in photoshop I have two layers, one normal with a window cut into it, underneath a glass texture layer that is 40% opacity.

Saved as PNG file, this does not cause flickering.

It almost seems like it depends on the kind of picture because it worked with 60% for others.

Somewhere around 50% is the magic number, as you said.

40, 45, 50 work great.

55% and there is the flickering.

For me anyway.

I have no idea if people on different computers and viewers see the flickering when i don't.

There is no information out there on what it exactly is.

Jo Yardley · October 2, 2011

Aargh, enough to drive one mad.

Exact same texture, doesn't flicker.

I change a few pixels, it flickers.

Almost as every single texture needs its own certain type of opacity.

Jo Yardley · October 2, 2011

Ok same texture, same window, same everything except the opacity.

No flickering with 30%,

Maybe... just maybe it is related to the complexity of the texture?

This is an old dirty window with lots of panes, so maybe this one one works with 30% while more simple textures can avoid the flickering with 60%?

It is all very weird but it seems the only way I can get windows that don't flicker is to upload every single opacity version and just try it inworld!

Chosen Few · October 2, 2011

Jo, you're trying to assign undue rhyme and reason to anecdotal evidence. You could drive yourself mad trying these kinds of experiments until the end of time, and you still wouldn't glean any conclusive results. This is because you're operating from a false premise. Your expectations of how it SHOULD work are not in line with how it actually DOES work.

The "flicker" you're referring to is properly called "alpha sorting", or more specifically, "the alpha sorting glitch". It has a lot more to do with how your graphics hardware works than with anything SL is or isn't doing. It's an inherent part of the nature of how blended transparency works in any realtime 3D simulation. There's no changing it.

Understand that depending on your graphics card, your drivers, and a few other factors, the precise order of operations that go into drawing the actual pixels in each frame on your display may vary slightly. Therefore, it's entirely possible that a texture that looks like it's "in back" to you at any given moment, might well look "in front" to someone else viewing it from the exact same angle and distance.

The bottom line is this. When you overlap two or more 32-bit images in 3D space, you're going to have sorting problems, period. Understand, the computer does not think of concepts like "in front" and "in back" in the same way a human being does. When it's confronted with the task of determining how to blend color values together in order to make it look like you're seeing one partially transparent surface through another, it considers a few mathematical variables in order to best guess at how to display both.

The primary factors are the camera's distance from the center of each object, and the difference between the camera vector and the surface normal vector (the angle of view). There are others, but those are the two biggies. Very generally speaking, whichever object's center is closer to the camera will be drawn as "in front". When the two centers are equidistant from he camera, then whichever one is most directly facing the camera will be "in front", again very generally speaking. There are a multitude of other factors which also affect the draw order in various ways.

No amount of tweaking the opacity values of various pixels in any of the imagery itself is going to change the principles involved. The fact is this. If both surfaces have 8-bit transparency, whether it's 1% in 1 pixel, or 100% in 27 pixels, or 66% in all pixels, or any other combination of values you could possibly think of, sorting is sorting is sorting. From certain angles, and from certian distances, "back" textures will appear to jum to the "front", and vice versa.

It's important to understand that this has absolutely nothing to do with SL itself. The alpha sorting glitch happens in every single 3D simulation on Earth, from freebies like SL to commercial video games to high end 3D modeling platforms that cost thousands of dollars. Realtime 3D + 8-bit transparency = alpha sorting, and with the sorting comes the glitch. There's no escaping it.

The only reason you don't see it happening in games very often is because professional game artists are well aware of the issue, and we go to pains to design around it. We simply don't build situations in which mutliple 32-bit images wouild ever overlap (except when we want to actively take advantage of the glitch for simplifying the geometry of certain things like trees, fire, chandeliers, etc.).

SL doesn't provide for that kind of design control. First, even if you do all the right things, your neighbor might not, and then it's back to square one. There's no way to reliably prevent your neighbor's alpha textures from interfering with yours. Second, unlike in games, there's no way to control people's angle of view in SL. Everyone has complete 360-degree freedom of movement for their cameras. It can be very challenging to design an environment that does contain 32-bit textures, but in which no two of them will ever appear to overlap, when every aspect of the scene can be approached from an infinite number of viewing angles and distances. Third, there's no controlling what's attached to avatars. Say you do manage to design an ever-so-carefully-constucted build that ensures no 32-bit textures ever can overlap, from any viewing angle. Well, as soon as someone shows up sporting a big old pair of giant butterfly wings, and hoochie hair from hell, and all manner of translucent bling, then all bets are off. Their crap is going to interfere with your windows and your plants and anything else of yours that has transparency.

My advice, don't drive yourself crazy trying to fix the unfixable. The sorting glitch happens. Live with it. That's all we can do.

Jo Yardley · October 2, 2011

Thank you very much for your reply.

I thought this would be the case but on the other side, at least now I know what works for me.

I would go nuts if I saw flickering textures everywhere.

Even looking trough a window at non alpha textures I would just see them flickr all over the place, enough to drive me mad.

And although people love 1920s Berlin and spend a LOT of time there, I probably still spend more time there then anyone else.

So as long as the stuff isn't flickering for me at least it is all a bit better

And when building a city with sometimes wide streets and modern buildings and sometimes narrow streets with dirty windowed buildings, you can't always avoid windows being too close.

Anyway, thanks again for taking the time to reply.

Chosen Few · October 3, 2011

You're most welcome, Jo. I'm glad you found the information helpful.

I'll be curius to check out your Berlin sim when I get a chance, by the way. Sounds neat.

Void Singer · October 3, 2011

actually I read the flicker problem to be different than the sorting issue... as far as I ca tell the flicker is actually engaged by occlusion code (which is also probably being effected in some case by sorting)

for comparison take a hollow 20m cylinder and drop it around yourself, then use the invisiprim texture on the inside. and alternately just normal transparency.....

we know that the first should just engage occlusion culling, but it tends to lead to flashing flickering alpha items. the sencond generally suffers sorting at less than 100% transparent.... but I've seen circumstances were both seem to be in play for normal transparent textures... and I've never figured out the source of that one. it's definitely not the sort order alone, as the textures actual disappear momentarily. and when it's happening the scenes are always complex so I don't think it's a buffer problem.

this may not be what the OP was referring to though, it's hard to get a clear understanding when we all have different frame of reference

Chosen Few · October 3, 2011

Void Singer wrote:

clear understanding

Heh, nice one! I do hope that was intentional.

In any case, yeah, it's possible we're all talking about different things. For practical purposes, I'm not sure it matters, though, because in each case, there's really nothing to be done about it.

Regarding the invisiprim texture in particular, my understanding is that's a special case. From what I was told, it reverses the draw order for certain scene elements, forcing avatars and alpha textures to be rendered "behind" everything else. Contrary to its name, it doesn't actually make anything invisble; it just sends them to the back of the scene. It was originally a bug, which was deliberately left unfixed, because it turned out to be useful.

Void Singer · October 3, 2011

I can't believe I missed my own pun =D

I had thought it was an artifact of single bit (really single value) transparency similar to linden plants... which we can't actually upload ourselves because the conversion to jp2 treats all alpha as a channel, rather than a pallet value?

Chosen Few · October 3, 2011

I don't know for certain. You'd be better equpped than I to dive into the code, and try to figure out what's really going on with invisiprims. A freind/colleague of mine gave me the reversed draw order explanation a few years ago, and it did seem to make sense.

If it were just an issue with how 1-bit alpha is treated, then I'd assume trees would produce the same effect, but they don't. It also wouldn't explain (or at least I don't THINK it would) why invisprims hide water, which is a GL effect, rather than a texture.

By the way, I do see what you were talking about, regarding invisprims making alpha textrures appear to flicker on and off. They didn't used to do that. I wonder what's changed. From my experiments just now, it only seems to happen with very distant objects. Objects close to the invisiprim itself seem unaffected. Weird.

Void Singer · October 3, 2011

I'm thinking it has to do with ambient occlusion, but TBH I'm not certain, and 3d graphics rendering code just make my head hurt, though I can understand most of the low level and format portions, the render and draw manipulations are mostly out of my arena.

Jo Yardley · October 3, 2011

In short; when I look trough certain alpha textures pretty much ANYTHING behind it dissapears and reappears really quickly, not just water, trees and other alpha textures, no EVERYTHING.

And yes, as someone else just mentioned, it does seem to be a new thing.

I can remember that in 'ye olde days' the only alpha problem was when you put two alpha textures close together.

But for flickering it doesn't matter where other alpha textures are.

And the weird thing is that it doesn't happen (for me anyway) with some alpha textures and that I can avoid it by tinkering with my textures.

I don't know if other people still see the flickering though.

It is odd, odd, odd.

I'd love a Linden to share with us some facts and figures and if we're all imagining it.

Void Singer · October 3, 2011

just a thought, are you by any chance using camera focus settings?

Jo Yardley · October 3, 2011

Erm.... I have no idea.

Chosen Few · October 4, 2011

Jo Yardley wrote:

In short; when I look trough certain alpha textures pretty much ANYTHING behind it dissapears and reappears really quickly, not just water, trees and other alpha textures, no EVERYTHING.

Jo, my apologies. I misunderstood what you were talking about. Questions about the alpha sorting glitch come up so often, I just assumed that that was what you meant. But the rapid flickering you're describing is an entirely different thing. Had I not tried Void's experiement with an invisiprim, I never would have figured it out.

Now here's the good news. As Void surmised, the problem does indeed appear to be linked to occlusion culling. If I disable object-object occlusion, the flickering behind invisiprims stops instantly. Turn it back on, and the flickering resumes.

I'm not able to replicate the problem with alphas on my end, so I can't verify it specifically for that. I only see it with invisiprims. But I'd bet dollars to dounuts it's the same exact thing.

If you don't already know how to disable occlusion culling, here's how:

1. Press ctrl-alt-d to add the Advanced menu to your top menu bar.

2. Press ctrl-alt-q to also add the Develop menu (or click Advanced -> Show Develop Menu).

3. Press ctrl-shift-o to turn occlusion culling on or off (or click Develop -> Rendering -> Object-Object Occlusion).

Note, the shortcut won't work without the menus first being enabled.

Give it a try, and please let us know if it solves the problem.

Jo Yardley · October 4, 2011

Thanks for the suggestions I'll try them later.

As for the other kind of flickering, where prims use the exact same spot, I have done this on purpose with some builds to save on prims.

As the prims use the exact same spot but their textures match exactly, they should not flickr, at least they don't do to me.

It may have something to do with the kind of viewer or graphics settings someone uses.

I'll ask some of the regulars if they see something like that .

Got any specific locations where this was bad?

Chosen Few · October 4, 2011

I'm at the 1920s Berlin sim right now. I've looked around pretty throroughly (with occlusion culling enabled), and I don't see anything flickering at all. I do see a few instances of Z-fighting, as Parrish mentioned, as well as a few alpha sorting issues here and there, but nothing like the kind of flicker you described. If it helps, I'll list the issues I do see.

In the NE corner of the Antiques & Curiosities building, there's a plywood cube Z-fighting with the outer wall, at ground level.

The "Dance, drink, flirt" poster Z-fights with the wall it's mounted on, when viewed from a good distance away. Consider moving it just a smidge further away from the wall. (Nice poster, by the way.)

The Otto Griebel sign on the North side of the Coming Events wall wall is slightly crooked, relative the the wall, so its upper right corner Z-fights with the wall. Snap it stright, and it should be all set.

The posters in the windows at the Millinery Shoppe all have alpha sorting problems with the windows themselves. As the posters are all rectangular, there's really no reason they should be alpha in the first place. I'd suggest replacing them with 24-bit versions.

The chandelier in Solitaire Creations has alpha sorting issues with the rounded corner window. There's probably no way to fix this, other than getting rid of either the chandelier or the window. I'd say live with that one.

Separate issue, but your one-prim sculpty chairs in the upper window of the Weimar building don't hold up well over distance. From the street, the become blobs. They don't look like chairs until your just a few meters away. I'd suggest replacing them with chairs made from a few more sculpties, or with meshes. A similarly designed mesh chair would likely have a prim equivalency of less than one.

You might want to lose the Second Life Marketplace sign. LL doesn't allow that kind of use of the SL logo.

I love the African gray parrot, in the antique store. I've got pet birds in RL, so I'm always a sucker for a well made bird. Please tell Oriolus I like his/her texture work, on that, and just about everything else in the store. Nicely done.

Overall, I have to say I like the build. Just about everywhere, the texturing is very period-appropriate, and well painted. You've captured the style of the period quite well. The Tophat sign, in particular, is a really nice touch. There are a few textures here and there that don't quite match, such as some of the rooftops on the shops, but they're hardly showstoppers.

My only major critique is I wish the street had shading. Most of the buildings are so carefully textured, with faux lighting and shading, but the street is just flat. It kind of spoils the feeling. A shadow prim, placed just above the street, would do wonders to bring it all together.

Jo Yardley · October 4, 2011

Thank you VERY much for that.

I'll fix those and also talk to shopkeepers and tenants who are responsible for some of the things mentioned.

Not sure what you mean about street shading, but if it is going to cost prims I'm afraid we're running short and want to use the few prims we have for other stuff.

Maybe in the future, when we get started with mesh.

The marketplace sign is actually the marketplace box as they gave it to me, everyone who uses marketplace has one rezzed in SL so I think LL don't have an issue with it.

Have you also been to the city or just looked at the teleport area?

Jo Yardley · October 4, 2011

Chosen Few wrote: