The IMVU transparency bug and why stuff disappears

Update:

IMVU Client version 410.0 appears smarter, either that or some of the affected objects have been fixed.

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.

If you must use blending on clothing then please ensure the mesh is appropriate, if you want to make a short skirt then derive from a short skirt, do not take a long skirt and cut it down as this will leave a "blend halo" where the mesh extends.

If you must cut a product down using opacity then do not use blending. Non blended/alpha opacity does not cause this problem.

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 (As of version 410 this may no longer apply).

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 important thing to note is that once a pixel is drawn it cannot be overwritten by pixels of something further away.

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 incorrectly 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 Since Z-buffering works well for solids drawing the solids first 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.

The worst case scenario is water. There is frequently no "correct" draw order for a scene depicting an avatar swimming. If the water is drawn last this generally gives the best results but may result in a "hole" if the avatar has a lot of transparency. To fully render a blended avatar floating on a blended water surface you might need to add an extra "draw behind" render pass. First the water's Z values are written to a special buffer, then the avatar is rendered, but only the parts underwater, e.g. the parts with Z values behind the water Z. Then the water may be drawn and finally the avatar is drawn again to draw the parts above the water. Throw in intersecting opacities and the problem gets worse.

Hints and cues

One possible fix for Rear-to-front rendering is to build in cues for IMVU to enable it to determine the best draw order. The simplest one might be to give everything a node, even immovable room fixtures. This means everything exists in a specific location and the draw order may be sorted. Since this demands a change in how rooms are developed it cannot be applied to existing products.

The problem with Hints and Cues

The biggest problem with hints and cues is that it depends on the developer building in the information. Unfortunately this only works if all developers have access to clear instructions indicating what files should contain. At present they don't, a lot of developer instructions come from third parties and are based on experimentation not a published specification. This means that any product may "break" in future due to using a feature or format that seemed OK at the time of publication.