SL Alpha Bug: Will it ever be fixed?

Hello all, am just wondering whether the sl alpha bug ever gonna be fixed? If you don't know what I mean, well its an ugly graphics visual that occurs when 2 alpha images are close...here's an example below...

Not likely. First, it's not really an SL feature, it's a GL Open Source one. And second, it's not really a bug. The problem occurs because there's no logical way to determine the order in which graphics routines should present information to your screen when two of them have transparency. With opaque objects, it's easy .... the one closest to you shows. With transparent objects, the routine has to decide which image is really "closest."

This question has been asked and asnwered many times, and is the subject of a sticky on the Texturing Tips forum, where it is explained much better than I can.

Okay, thanks for the reply.....gonna have to find a way to solve....

If only you could have a choice of applying it to prims, or not.

If it is taken away, or fixed, then ALOT of plant life in SL will be broken. Most rely on the Alpha Sorting Bug to look good.

It WILL be fixed, if not by Linden Lab, by another client developer. A lot of content currently will be broken definitely but it opens up a lot more content to be created in the feature.

What makes you think it will be fixed, Nexii? Is that just wishful thinking, or do you have some specific technical knowledge leading you to that conclusion?

The sorting glitch has existed as is, practically since the dawn of computer graphics. Professional game artists are well aware of it, and utilize it well, both by taking advantage of it for things like trees, fire, etc., and by making sure to steer clear of it in situations where it would be problematic.

Without the sorting glitch, many established conventions would need to be abandoned. The increased poly count of trees alone could bring many real-time environments to a standstill. And that's before you even get to the increased intelligence that would need to be built into the graphics processing pipeline in order to make sorting happen in a better way.

The only reason the glitch is a problem in SL at all is because inexperienced amateur 3D artists don't know to expect it, so they're surprised when they encounter it, and then some of them complain that they can't do their intended build now because of it. In reality, they can certainly still do it, just not by quite the same procedure they'd expected. But since it's so much easier to complain about a perceived "bug" than to rethink your own methodology, somehow it's this huge obstacle to SL's would-be greatness. Never mind that the glitch also exists in every 3D video game in the world, even the ones with the most stunningly beautiful graphics you can imagine. It's a problem, right? We should all demand it be "fixed" right? Wrong. Just accept that it's always been there, and learn to work with it and around it, just like the pros do.

Don't get me wrong, though. I'm not saying we should just be complacent, and accept all existing limitations forever. That's not it at all. The day will come when computers get smart enough and powerful enough that graphics as a whole can be approached from an entirely new paradigm, something more closely resembling how vision works in the real world. When that happens, then silly little things like the sorting glitch will certainly go away (the whole concept of "sorting" won't even matter at that point). We're just nowhere near that point yet. We'll get there, but not any time soon.

It will never be fixed...it's an OpenGL issue, not a SL issue. Until they switch to DirectX...it will always be a problem.

We have learned to design around alpha-fighting since the creation of OpenGL over a dozen years ago.

Chosen, I see your point...but come on...even to us veteran cg artists it's a huge annoyance. If I want to create a glass table which casts a shadow (alpha) this will not work the way it should work--unless I don't mind alpha flickering. Instead, you claim we designers should be aware of this and simply work around it...yes, this is absolutely true...but it's much more time consuming to create a shadow for a glass-top table that doesn't flicker...you have to bake the texture into the ground texture itself...making that little ground area a separate prim, and matching that texture to the main ground texture. It's annoying...even for me, someone who's able to whip around SL and PS no problem.

I think the most troubling aspect of it is that you can't resonably control it, because transparency is so heavily used in avatar attachments, especially hair and skirts... making it extremely difficult if not impossible to include realistic transparent elements in your builds, such as windows... because they combine in unpredictable ways... nevermind your neighbors pine grove.

there are some ways to work around it, as I've demonstrated before with 2 prim high detail tables. but the applications are VERY limited at this time for preventing bad interactions with other objects.

it might get fixed, by an openGL update, but it's not likely anytime soon, for the reasons Chosen points out, untill someone comes up with an effecient way to make it workable, without breaking the curent rendering method.

EDIT: shadows are another good point... and must be built in place to prevent problems, meaning single object can't safely incorporate them. DirectX isn't a likely solution either, since LL doesn't want to tie itself to a single platform, or the liscencing issues, when it's core ideal is to be the next stage internet platform. but wouldn't M$ kill for that kind of exclusivity....

I'm not sure DirectX would solve the issue, either. I can't pretend to know much about it, but from what I've seen in DirectX games, it seems the same glitch exists there too. Anyone have any more specific knowledge on that?

DirectX doesn't have alpha-fighting like OGL. Amateur coding in DX can lead to alpha problems, but modern iterations of DX, and proper coding keep the problem at bay--at least well enough where you don't have to design around it.

If that's true, then how come in DX games, I see things like trees and vegetation built the same way they're built in OpenGL games? Unless I'm missing something, without the sorting glitch, that technique wouldn't work so well.

"difficult if not impossible to include realistic transparent elements in your builds, such as windows..."

What's the problem with windows? Thanks.

That must be the alpha to coverage thing. It is of course also available for OpenGL, it's all the same hardware with the same capabilities, just different APIs. And your guess was quite right, it makes some problems go away only by swapping in new ones. Example at http://www.humus.ca/index.php?page=3D&ID=61

You'll find out when you try putting a plant on your window sill and looking at it from different angles.

A plant: you mean one of those usual "crossed alpha texture" plants?
Ok, I can understand what happens.

Thanks.

same thing happens with that alpha textured prim/flexi hair... and destroys the effect of both =(

since i use the windlight viewer that problem seems to be gone for me. i tested it in several areas.

Vegetation in games is created with the X format, because it's the easiest way to achieve photo-realistic results with high optimization--this is a design concept, not simply an alpha-issue work around.

Play a game like Crysis...and look at the vegetation--you won't see alpha-sorting issues, nor techniques that work around it. I say Crisis, because their vegetation is so lush and realistic. No matter how many layers of alpha you're looking through in DX, you won't see flickering (at least not with quality scripting).

no comment

No comment

Just out of curiosity, is your alpha-textured horizon painted on the inside of a big hollow mega-prim?

You are pretty much guaranteed to see this problem if the center of the prim with the alpha texture is IN FRONT OF another alpha textured prim. Even if the other prim is smaller.

This could probably be addressed... but I'd put money down that proper alpha culling could increase rendering lag.