Transparency problem

I know this is an old SL problem but I was wondering whether there are any building tecniques to minimize the effect of transparency bug in SL... I can't use curtains on windows because both curtains and window glass is semi transparent. Even though I upload both of textures without alpha channels and make them semi transparent later in-world by changing the opacity, they still seem to overlap each other at some angle..Is there a way to avoid such problem?

Thanks a lot!

Use .png format (without alpha layer) to avoid possible bugs that the upload-conversion just adds an unnecessary alpha channel (that can happen in other file formats).

Use sculpted prims without any transparency on them.

In determining sort order, only the center of the prim matters. That is, the prim considered "on top" is the one with its *center* closest to your camera.

Are your curtains two prims? If you've placed one prim on each side of a window it's easy to explain why you're having sorting trouble. When you stand to the side, based on the centers of the prims, the sort order is cutain (top), window (middle), other curtain (bottom). So, you see one cutain on the correct side of the window and the other on the wrong side.

Is this what you're seeing?

From a position where you see the sort problem, edit each prim and look where the center is. I'll bet you'll find the the window prim center is closer to your camera than the errant curtain prim.

Parallel prims with their centers aligned rarely show the problem because it's difficult to maneuver the camera such that the centers aren't in the order you expect. So, to eliminate this problem try to arrange your object such that you have parallel prims with the centers aligned. For your window you could break the window into two prims so that the center of each side is directly behind the center of the curtain, or as close to directly behind as you can manage.

Problematic (plus marks center of prim):

[----------------------+---------------------]
[----------+----------][----------+----------]


(X) - from this position the window is closer than the far curtain


Better:

[----------+----------][----------+----------]
[----------+----------][----------+----------]


(x) - from this position the curtain is closer than the window on both sides


One-prim window:
http://www.vengeancestudio.com/forumpics/windowcurtains1.jpg

Two-prim window:
http://www.vengeancestudio.com/forumpics/windowcurtains2.jpg


If your curtain prims actually do touch, like mine do, you can implement this with one prim for the window and one prim for the curtains. Do that by path-cutting a box prim for the cutains 0.375-0.875. That gives you two faces on one side of your box. Apply a curtain texture to each side. In this way you get two side-by-side textures on one prim, and since the curtain is one prim, the window can be one prim, too.

Unfortunately, sort order isn't as simple as Anya is describing. I would pay good money to ensure that sort order in SL was as easy to fix as Anya describes, and so would most content creators. But it isn't. You can have two precicely identical sized prims, one tenth of a meter apart, both alpha textured, and the sort order will flip almost at random as you change your position and viewing angle, regardless of the relative positions of the prim centers. I've seen plenty of cases where the center of the window prim was on the far side of the wall from where I was looking at it, and yet I could see the whole curtain texture, apparently hanging on the outside of the house.

There are two decent ways to get curtains that work well on your windows.

The first method is to have the window prim scripted to switch between two textures that incorporate both the window frame and the curtain. One prim, no sort issues. This does mean that you may need to edit the textures that you have, to layer the curtain texture on top of the window texture and make a new, single texture. You may also want to use a total of four textures, so the outside looks correct as well.

The second method is to use prim curtains that have non-alpha textures. This means the prims either have to re-size to open or close the curtains, or you need to use something like a sculpted prim. I use the re-sizing prims method in most of my builds where I want the curtain to overlap the wall around the window.

I haven't yet tried making a sculpted prim set of curtains that can open or close. Technically it should be possible to make a script that would not only switch surface texture, but would also switch the sculpt map to reshape the sculpty. Again however, the surface texture would need to be a non-alpha texture.

Unfortunately this isn't an SL bug but one in OpenGL instead. On the bright side the source is there if you want to try to fix it.

S.

It's not an "SL problem", so you know. It's just a fact of life in OpenGL applications. The way to deal with it is to build around it. The options are either texture your curtains onto the same surface as your windows, or redesign the build a little to ensure that the center of the "front" surface is always closer to the camera than that of the "back" surface, or else put a well placed non-transparent surface in between them. That's it.



Ollj, if I'm reading you right, there are at least four major problems with your post.

First, you seem to be implying that using PNG as your source format somehow prevents an alpha channel from being put into your texture in SL. I can assure you that that's completely untrue. If the texture has transparency, it will have an alpha channel in SL, period.

Second, you also seem to be implying that somehow an alpha channel could be erroneously added at the time of upload to a texture sourced from any other format except PNG. You've got it backwards. PNG, in fact, is the ONLY format with which you DO risk the accidental inclusion of an alpha channel. This is because it's the only one that supports multiple forms of transparency. All it takes is for a single pixel in a PNG to be less than 100% opaque, and the resulting texture will end up with an alpha channel in it. That can't happen with any other format. With TGA, the ONLY way to have an alpha channel present is to put it there yourself. And BMP and JPEG don't support transparency at all, so it's a non-issue with them. PNG is the only wildcard of the bunch.

Third, you seem to be under the impression that it is the alpha channel itself that causes the sorting glitch. That is also completely untrue. While the behavior is commonly referred to as "alpha sorting", that's only because alpha transparency is the most commonly used form of transparency in use. It would more accurately called "transparency sorting". Any form of transparency will trigger it, including PNG's simple transparency. But that's really a non-issue anyway for SL purposes, since all textures inside SL are saved in JPEG2000 format, which does use alpha channels, regardless of what the source format on your local hard drive happened to have been before upload.

Fourth, you used the phrase, "alpha layer". There's no such thing as an "alpha layer". It's an alpha CHANNEL. Layers and channels are entirely different things. Please use proper terminology. It's challenging enough for newbies to learn this stuff without having to be confused by nonsense words.

It doesn't matter what side of the wall it's on. The curtain can be fully on the far side of the wall, and if you're looking at it at an angle such that the center of the curtain is closer than the center of the wall then you're going to see the curtain on the outside.

I've never seen this random swapping that you describe. It's always been perfectly predictable once you realize you're working with prim centers and not prim faces. If you have a test case that shows otherwise, please do share.

Unfortunately, this is very easy to demonstrate. Here is an in-world example that proves the alpha sort glitch is not as simple as "Whichever prim's center is closer will show first".

Go to http://slurl.com/secondlife/FairChang%20Calypso%20NE/130/92/24

You will find two large green-framed windows just outside my store there.

The one with red curtains has the red curtain prim exactly centered on the window frame, but just a little South of the window prim. The curtain prim is 0.2M smaller in Y and Z dimensions than the frame. The two prims have the exact same X and Z positions. So there is no way that, when you are standing on the same side as the red curtain prim, the window frame's center could ever be "closer" to the camera than the curtain prim's center.

The one with blue curtains has the curtain prim INSIDE the window prim, and they share exactly the same center point for both prims, exact to three decimal places. So it should be mathematically impossible for the center of the window frame to ever be "closer" than the center of the blue curtain prim. The distance from camera to centers will always be precisely equal.

Walk or pan your camera around these two windows, at varying distances from them, and pay particular attention to how it looks when you are close to edge-on. You will still find some angles and viewing distances where the prims switch sort order unexpectedly.


Both windows sorting as expected


Red curtain sorting wrong, though it is definitely closer than the frame is.


Red curtain showing through the far side, although the frame's center is definitely closer.


blue curtain showing before the surrounding frame prim, although the frame's center is identical. Red curtain is also sorting wrong here.


And this is rather extreme... The red curtain, which is closer than both frames and the blue curtain, is rendering as BEHIND both frames and the blue curtain! The calculation to its own frame might be close, but the second frame and curtain are quite a ways farther away.

SL has gotten better at this over the last year, especially if the prims are linked to each other. But the glitch remains a fact of life for any Open GL application. Your suggestion may reduce the effects of the glitch, but it does not avoid it entirely.

System info used in test:
Second Life 1.19.0 (5) Feb 28 2008 17:18:12 (Second Life Release)
CPU: Intel Pentium 4 Northwood (2259 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce4 Ti 4400/AGP/SSE2 (128 MB VRAM)
OpenGL Version: 1.5.7

Thanks, Ceera. I was able to reproduce all of those, but once the scene finished rendering it rendered correctly 98% of the time. When I do see a fault, it's stable for a while, even as I move the camera a little bit. And then -snap- it's back to being correct, and is persistently correct even with the same camera movement.

I'm no longer convinced this is a GL bug. The alpha sorting that I described is something GL can't do anything about (and probably shouldn't be called a bug), but I'm now convinced that SL also tries (and fails) to influence the sort order.

From what I've been told, SL caches the sort order, to save on processing. Rather than recalculating the order within every frame, it saves and repeats the last known state for a few frames before recalculating again when it thinks it needs to. If it didn't do that, frame rates would be significantly lower than they are now.

I don't pretend to understand the programmatics of it myself. This is just how it was explained to me by someone who's heavily involved with viewer development.

If my understanding is correct, this could explain why an incorrect sort remains for a little while and then snaps into correctness, and vise versa. The caching trades a small potential sacrifice in rendering accuracy for a big gain in speed.

Thank you everyone for taking your time to help me! I understood a lot more about it now and will try to build my way around this problem! Thank you guys! ^-^