The transparency bug, why stuff disappears

This is a long running issue with IMVU and although I do not have inside information on IMVU code I have experimented with 3D enough to have an idea what's going on. It is not fair to blame IMVU for this really as its a problem with the current state of 3D graphics technology.

In short: If you don't need blending then don't enable it. To mitigate the effect if part of a shape needs opacity and most of it doesn't then consider dividing the object into two materials and only blending the bits that need it, example: a big round rug that is mostly solid but has a blended border. Only the border is affected by the bug.

In simple terms if a material/texture has the "blending" attribute enabled then it may vanish when viewed through another material with blending. Unfortunately it is often checked by default, making otherwise solid objects seem to vanish at random.

The key issue is how the rendering engine (graphics card/driver) handles the "blending" attribute. The blending attribute has two effects: one intended effect and one side effect.

1. The intended effect: If a mesh part is drawn with blending and it has an opacity map then the opacity map will be used as an alpha channel, controlling how solid the object appears (it makes it partly see-through).
2. The side effect: If the mesh part has the blending attribute then it is drawn in the opacity pass, after all the non-blended mesh parts have been drawn. This applies even if the material did not include an opacity map.

Technical stuff

As far as I can determine IMVU use fairly standard rendering techniques.

1. backface culling
2. z-buffering
3. solid first
4. rear-to-front draw-order

Backface culling

In this technique each triangle of an object is tested to see if it is facing towards the "camera". If it is facing away it is not drawn. Backface culling has little or no bearing on the transparency issue.

Z-buffering

This is a tricky concept. the "Z" in question is not the "Up" direction in the room, it refers to the coordinates after they are transformed to the screen. Z refers to how far an object is from the camera. Each pixel in the draw buffer also has a Z value.

Each time the screen updates the draw buffer is cleared and the z values are reset to maximum distance. When an object is drawn each pixel is marked a Z value. Each time something else is drawn on a pixel a check is made to see if it is in front of the existing pixel. If an existing pixel has a Z nearer than the new object then the existing pixel is kept. If the new pixel has a nearer Z then the pixel is updated and given the new Z.

The problem with Z-buffering

The problem is that Z-buffering works very well with solid objects but it doesn't cope well with objects with opacity. If something is drawn with opacity then anything that is behind it and has already been drawn will be correctly blended, BUT if an object is behind and it gets drawn AFTER the opacity then it will be hidden because the renderer has no way to determine that it should show through.

Solid First

A very simple way to mitigate the effects of opacity is to ensure that everything solid gets drawn first, followed by the opacity bits. This ensures that all the solid (not blended) parts get rendered correctly and the opacity parts get rendered reasonably well provided that there aren't many of them or they don't overlap.

Rear-to-Front

Another obvious way to mitigate the effects of opacity is to try to draw the rearmost parts first. This way all the bits with opacity are built up progressively by drawing each nearer part over the more distant parts.

The problem with Rear-to-Front

The problem comes when two objects intersect. If an avatar is inside a blended sphere then it is hard to see which should be drawn first. Ideally the inside back face should be drawn first, followed by the avatar, followed by the front face. Unfortunately it is hard to make these decisions at runtime and for some combinations of objects there may be no correct draw order.