[sldev] Alpha Blending Settings Included in Texture Metadata

[Soft]

On Fri, Jan 16, 2009 at 8:50 AM, Carlo Wood <carlo at alinoe.com> wrote:
> Would this solve the simple problems that I ran into?
> For example:
>
> A house (with four walls), each wall is nearly opaque, but
> they contain an alpha channel (for a few very small windows).
> If you stand outside and rotate around a bit, you see walls
> that are *behind* the wall that you're standing in front of
> first, as if big parts of the wall that your standing in front
> of don't exist.
>
> Or, I have a house where a part has floor-to-ceiling windows,
> with a stripe (in the texture) every 2 meters or so to 'support'
> the glass. If I put an Xmas tree in my livingroom that is
> partly transparent, at some angles (most of the angles actually)
> you see those stripes in full through the tree - as if the tree
> wasn't there at all.
>
> I've never understood why this ordering bug exists; because
> I can't think of a reason that makes it hard to get it right :p.
> Can someone explain what the problem/reason is for these "features"?

Yes, clip mapping would solve that problem at the expense of not being
able to have partially transparent pixels.

Efficiently sorting polys with alpha surfaces is actually an unsolved
problem in computer graphics. To understand why, make two walls out of
glass in SL and then arrange them so they intersect to form an X when
seen from overhead. Now, look at the pair from the north, south, east
or west side, and ask yourself which wall is in front. The answer is
neither... or both.

One naive solution is dividing objects in half wherever two planes
intersect, but even a few dozen prims could degenerate into tens of
millions of new surfaces with this approach. That X would turn two
surfaces into four. Try a tic-tac-toe board, #, and four surfaces
becomes twelve. Add just two more lines and the twelve becomes twenty
four. Follow that trend and imagine what it does to memory and
performance.