Linked prims moving as I pass them. Is this a bug

In creating a building using linked prims I found some of them were moving when I walked past the building or when I cammed around it.

The prims in question were all thin prims (windows & a sign - 0.01mtrs) and had alpha (invisible sections). Is this a known bug? If so, how do I correct this problem (I might add that some of the thin prims with alpha sections in this build do not malfunction in this way).

Eliver Rang

I might add, this happens when the prim is linked or unlinked. It is not a doubled up prim. The prim is a hanging sign, which is partially transparent to show up the chains holding the sign.

When I stand in a particular position the sign appears to be behind the building (part of the building shows through even on the visible part of the sign). If I then change the texture to a solid (no transparent sections), the sign appears normal (covering whatever of the building is behind it).

Eliver Rang

that's common problem when you use half-transparent textures.. from one angle it seems that one texture is before the other ,.. from other angle second texture brings itself in front of the first one.. etc.

As far as i know there is no workaround to this.. it is a common problem for 3d game engines.

This is probably the most common question in these forums, asked on average once a week it seems. You have rediscovered the alpha sorting problem that affects any environment based on OpenGL architecture. In simplest terms, when your graphics card has to deal with overlapping textures it follows a straightforward algorithm to determine which one is "in front" of the other other, and therefore which one occuldes the other. When one texture is transparent and the other is opaque, the answer is trivial. When BOTH are transparent, the answer is impossible to determine. (In fact, in RL your own eyes would usually have a hard time figuring out which one of two sheets of glass is in front of the other one.)

Unfortunately, the problem extends to cases where both textures contain 32-bit pixels, even if the 8 bits that carry potential information about transparency aren't actually transparent. If two 32-bit textures are close together and overlapping, the system simply can't decide which one to display, so it flickers back and forth between them, depending on your viewing angle.

There is no cure. Avoid using 32-bit textures unless you really need them (they require 33% more memory than 24-bit textures anyway). If you need 32-bit textures for transparency, avoid overlapping them in close proximity.

Thank you Rolig.
That was a perfect explanation and I thank you for your trouble.

Eliver Rang

They did recently make some improvements to the way that SL handles multiple 32-bit surfaces that are part of the same linkset. Once you focus on a linkset that has more than one 32-bit surface, a calculation is performed that bases which one is "in front" based on the relative positions of the centers of the prim. The prim whose center is closer to you gets priority in the sort order. But this doesn't come into effect immediately, nor is it 100% reliable. It also does not always affect prims that are not part of the same linkset. So a tree that is beyond the wall may show through the wall, in spite of this 'fix'.

An example. TP to the middle of the RUCE 4 sim, and walk East, looking at the three low-prim dorm buildings that are on the East edge of the sim. As you first start to see the buildings, the walls at the corners may show the alpha sort glitch - showing you a white stucco interior wall that is in the same line of sight, rather than the brick exterior walls. But if you focus your camera on the glitch, and get a little closer, the glitch fixes itself, and will not recurr. This is because of the calculation fix that they added to the client.

That's cool. I hadn't heard of that fix, Ceera. It makes sense that there ought to be a way to calculate which texture is in front if you already know the relative physical positions of two textured surfaces.

They need to go back to whatever they were doing before Windlight, though. The Z-buffering should be based on the center of the *face*, not the center of the prim (let alone the center of the object!).

I agree, Argent. It would be far better to base it on the center of the prim face. But from what I sould tell when experimenting with it late last year, it is the center of the prim that is closest to your camera that will be the deciding factor.

Indeed, but I'm pretty sure that wasn't the case before Windlight.