Ever notice that the Linden trees have no trouble with alpha sorting? It's because the alpha channel in those textures are being treated in a 1-bit format. The z-buffer is able to utilize them. So parts of the texture are either 100% opaque, or 100% clear. (Semi-transparency is not an option.) The Second Life client has the ability to do this already built into it. There's so much potential there, but we have no way of tapping into it! There are probably many ways to implement this, either in combination or independently. Here are two proposals: 1. On upload of 32-bit images, the user selects 1-bit or 8-bit for the alpha channel. If the texture uploaded contains grayscale values and the user selects 1-bit, there could either be an option (ie. slider) to set point at which gray values are converted to black & white (preferable) or LL could arbitrarily set this value to 50%. 2. When a texture containing an alpha channel is applied to an object, the Texture tab would contain a checkbox to treat the texture as either 1-bit alpha or 8-bit alpha. Again, as above, there could be a slider to set the point at which gray values are converted to black and white (preferable) or LL could arbitrarily set the value to 50%. This solution is the most flexible since it allows any texture with an alpha channel to be treated during content creation as either 1-bit or 8-bit alpha. Also, since objects already carry detailed texture usage information, it makes more sense for the object itself to decide how it should be rendered rather than dedicate the texture to a particular usage. In both 1 & 2 above, if LL sets the black/white threshold arbitrarily to 50%, then it is up to the texture designer to make their textures appropriate to the application. Either way, speed of implementation is probably more important than how this is done since this feature would make such a difference in how we see things. Come on.. RELIABLE Alpha Sorting.. to any degree.. would be awesome.