Looking through one partially transparent texture into another causes visual error

If you have a texture that has partial invisible and partialy visible image, say a texture of a window, where the frame is visible and the window is transparent or partialialy transparent (via alpaha chanel TGA).

If you then put this texture on something like a cylinder that is hollow, you will notice strange visual effects. The side you are looking at often times disapears completely showing you the inside of the back rim of the object. Or you will see that non transparent sections are partialy transparent and you can see the world behind them.

This has been happening since I first joined SL. Its a *REALLY* Annoying bug, Id love to see it fixed.

They seem to be getting around to it little by little. The problem used to make overlaying alpha channel'd-textures pretty much a don't do (one would completely vanish). It's a lot better than it used to be, but still ain't "fixed".

I've seen a lot of people (myself included) who get glitchy alphas if they wear glasses and they have their hair hanging across the front of their face such that the two alphas are layered. Looks completely awful =D

To some extent, this is a fundamental limitation of the way OpenGL rendering works. It's part of the tradeoff between speed and accuracy you need to make to get reasonable framerates. It could probably be eliminated by switching the z-buffer to floating-point, but even if graphics cards supported that option, it'd slow things down by an order of magnitude or so.

Transparent polygons need to be sorted from back to front. This is necessary in OpenGL as well as other 3D libraries.

When a polygon is rendered it affects the contents of the z-buffer. OpenGL uses the z-buffer to decide wether it needs to render something. When for example a wall is rendered, OpenGL will decide not to render the people behind it because you will not be able to see them anyway.

When a transparent polygon is behind another, already rendered, transparent polygon artifacts will occur.

yeah its a pretty fundamental limitation with how real time polygonal rendering works... once you know what to look for you'll see it in everything from retail computer games to clips from renderings in movies from the 80's and early 90's

the only real way to avoid it totally is to start incorporating variants of raytracing.. but rather than do multiple frames per second, you start talking about multiple MINUTES per frame.

There are several hacks that could be done to limit the effect abit more with transparent objects overlaying eachother, but then that could cause things like the particle engine to get all strange


(for another funky 3d inconsistency try making color 'filters' by overlaying part of a blue 50% transparent square ontop of a red transparent dube, depending on your view perspective it will look either like the blue or the red has eaten part of the other, not like a proper overlap)

I've got two machines capable of running Second Life, one with a Nvidia Gforce 5900 FX, and an ATI Radeon 9500 Pro. The two cards handle overlapping transparencies pretty differently, and oddly enough, I think the ATI card in at least this respect does a better job of it. Which machine do I prefer to run SL on? The Nvidia one of course...but there are many differences between the two cards.

Lum

at the moment ati has the superior openGL implementation, the problem is simply that SL was built for nvidia's and is bein kludged over to ati with some rough edges, instead of bein built with the general abstract openGL, and then optimized for each seperately

but the actual overlap, thats simply how realtime polygonal rendering works.. there is no 'way' it can be done right, jus hacked to varying degrees to be wrong less