|
|
|
I changed the title of this issue to better reflect the real problem. it affects all prims that use a texture with an alpha channel for transparency - 'rezzed' prims and attachments alike (sich as prim clothing)
Clock viewed from an angle.
Transparency and real-time 3D environments just don't go well together if you have 2 objects that are both in front of eachother. Avoid prims with transparency intersecting.
Placing two prims on the exact same location (or at larger distances, almost exact) as described in the repro will also trigger z-fighting. Avoid placing two or more faces on the exact same location. I couldn't repro ari's "wall with pillar" either without using a texture with alpha channel (doesn't have to actually use the alpha) on both the wall and the pillar and placing them partially inside eachother (thus having them both in front of and behind eachother at the same time, which, as I said, should really be avoided). I find incorrect sorting of alpha textures particularly annoying... I use apha textures to create complex objects (e.g. aircraft) to save on prims...after all my hard work, the effect is spoilt by alpha textures appearing through opaque objects that should obscure them.
My graphics (NVIDIA GeForce FX5600XT) drivers are up-todate.I do wonder if the problem is peculiar to certain graphics cards, or experienced by allSL residents? Can LL comment? You don't need a LL comment on this, this is not an error specific to SL.
See http://www.opengl.org/wiki/index.php/Alpha_Blending 
"The upshot of this is simply that you can't simply render translucent objects in any order without special consideration. If you have enough translucent surfaces moving around in a sufficiently complex manner, you will find it very hard to avoid errors with acceptable realtime algorithms." Basically: to avoid it, you will have to use more prims. Maybe in 20 years when we have ultra-mega-giga-supercomputers this issue will be solved, don't expect it soon. Whether this is worth anything to anyone, I found the solution that solves this issue completely.
ISSUE DUPLICATION SETUP: OBSERVED ISSUE:
Now for the coolest part!!! 1) Locate the same texture in your inventory that you would have chosen using the texture selection tool, but this time, right click on that texture and click on the option entitled, "Copy Asset UUID". default } 3) Click the 'Save' button in the code editor window. OBSERVED ISSUE: That's the (workaround) solution! Have fun, folks. In addition to Necrotic Lunasea's really, really clever solution (where you have the texture in your inventory) other workarounds include rezzing a solid non-transparent object inside the prim with the transparent textures. This works better for walls with windows and other textures with straight or simple curved edges, but completely fixes the problem, at least for those parts of the alph texture 'backed' by the non-transparent prim. I do this in my builds when using alpha textures that have windows or alpha edges in/on them. It does not matter how thick the inner prim is, nor whether all sides of the inner prim are non-transparent - just as long as the texture on the face of the inner prim that is immediately behind the alpha textured face of the outer prim is non-transparent and non-alpha.
One side benefit of this approach was that it improved our builds, all be it at the cost of more prims, because it lead us to put windowsill's and door frames into walls, etc thus eliminating that horrible paper-thin look that alpha-windowed wall textures deliver. Mind you, now I am going to start using Necrotic's solution. It should be very useful for plants. By the way, who decided this issue was resolved? It most definately is not resolved. Neither work around is really aceptable and the problem still exists. Sorry... I may be being a bit dense, but I REALLY was hoping the fixes mentioned here work. If you follow the series of events by Necrotic, you end up with 3 prims instead of 1, and it looks like the prim with the transparency (say a window) is sandwiched in between 2 other prims, one of which is opaque, thus blocking the view from the window? I tried both of these fixes, and neither of them worked... including making an opaque prim inside the window but hollow where I wanted to see through the window... I still had alpha sorting issues...
Am I missing something? Through experimentation I did find that if you have an opaque texture on one side, and a texture with alpha on the other, this does not seem to happen. But then, that's not at all realistic...your building would have windows on the inside, but not the outside? Anyway, is this a clue? When the competing textures are on the same prim? Charlton. Thanks for the comments
Elleon, That was merely a suggestion to use to try to proven the point of the fix. In actuality, one would only need to do this with 2 prims. It would appear that when you upload a PNG file (with alpha/transparancy in use) as a texture and then use that texture as the main texture that other prims would be sitting atop of, that the problem still remained, even using my workaround. But when you upload that same image from a non alhpa based file, like that of a JPEG...the problem is gone. I hope this helped a tad also. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Normal
Alpha-sorting of prims reversed, causing 'solid, non-alpha' prims to disappear.
Reproduce:
Create a large box (a 'wall') - add texture that includes an alpha channel - such as an exterior wall with a window.
Plase another prim in front of it, such as a tall cylinder (call it a pillar). Texture as desired - full opacity, no alpha...
Viewing it straight on will appear as it is supposed to. Changing angle (only a few degrees off to either side) and an entire chunck of the cylinder will disappear - as the the entire 'wall' prim was placed infront of it - even though it is not.
This freaky situation occures with attachments, too (such as prim dress skirts and things)
Highly irritating, but worse is that my nuilds appear 'sloppy' and I am questioned all the time. Tired of blaming it on SL - which, unfortunately, is the honest answer.