3D Draw Order / Occlusion is frequently screwed up

(EDIT: Problem found and bug reported. See followup post, below..)

This is a 3D rendering problem where sometimes hidden surfaces are visible in front of surfaces that should be hiding ("occluding" them. I cannot determine the cause. It seems to happen with both ATI and GEForce cards, and it will not go away no matter what I try to do.

This for example is simply a bunch of cubes arranged to make a flat marbled floor. As I pan the camera around the draw order keeps flickering and jumping around.



Let's work in the corner, with a single prim acting as a corner post to see how badly this problem can manifest itself. The floor prim will undercut into the post prim:



As I rotate the camera around the post, SL is consistently getting the rendering completely wrong, and cannot figure out how to make the big cube undercut the post cube:




So, I decide, I'll go easy on the renderer, and specifically split and cut the corner post so that it doesn't interpenetrate the big cube at all. This should fix my rendering problems, right? Wrong.



In the end, a cut-prim-post does absolutely nothing to correct the rendering problems:




This problem has been around a long time, and it is deeply frustrating to me because the renderer apparantly cannot handle even the simplest sort of occlusion calculations.

Whoah, I found the cause of the problem! There's something wrong with the way SL is rendering the texture on the prims.

I was about to give up, when I selected all the prims and blanked the texture. POOF, the occlusion problem instantly disappeared. Oddly enough the default wood texture renders fine without any problem.

If I use the eyedropper to apply the stone texture back on all the prims, the occlusion problem immediately reappears.



Taking it a step further, what is the interaction between blank-textured prims and prims that share the stone texture? Oddly enough the occlusion problem ONLY appears where two prims both share the stone texture. The blank prim looks just fine overlapping the stone texture.



So, the next question is, why is THIS texture exhibiting this problem? What makes this texture any different from the default wood or blank texture?


To test this yourself, the texture is from a freebie box.

The key: 5e234454-ab05-a685-79a3-3aa6de01db65
Texture name: marblewhite
Description: C:\Documents and Settings\veronica\Desktop\New Folder (5)\New Folder\94435075.tga


This is probably worthy of being called a bug report, and so I'm sending the URL of this thread to LL's bug reporting..

Sounds like this texture is a 32 bit targa rather than a 24 bit. The 32 bit targas are used for transparency effects, and suffer from these kind of sorting problems. Apparently it is a very widespread bug, in many many 3d applications. The plywood and blank textures are 24 bit, so work properly.

I see. So even though this texture uses no transparency effects and is completely opaque, it is still subject to transparency sorting problems?

In which case perhaps the client should be slightly modified, to check if an uploaded 32-bit Targa has no transparency. If so, the client will "flatten" it to 24-bit before upload to help reduce the appearance of this ordering problem.

It's not really a proper fix but it at least would help a little for the people uploading opaque 32-bit Targas, and then wondering what's wrong.

Actualy quite a few of the freebie marble textures do have a certain amount of transparency in them. It gives a more realistic marble look at a high cost in some circumstances unfortunately. I was "bit" by the same problem a couple of months ago.

Yeah, you have to be careful with any transparent texture in a dynamically rendered game like SL.
Your tests and documentation of your findings are however excellent and very informative, but unfortunately it's just not an easy problem to solve

The client does that as of a version or two ago.

Okay, well I'm just trying to cover all the bases for dealing with this apparanrtly undocumented but extremely annoying rendering bug.

The next step towords helping making people aware of the bug, is to build it into a help system tip for new/inexperienced people like me, when we are in edit mode and either rez up an object using transparency for the first time or apply a transparent texture to a prim for the first time.

TIP: You've just created your first object that uses transparent textures. Please note that overlapping transparent textures may be drawn incorrectly, and will flicker and seem to move in strange ways. This is not a graphics card driver problem, and affects both ATI and nVidia graphics cards. To keep this visual bug from appearing, try to prevent any two of your transparent textures from overlapping.

Also, the texture viewer in the inventory should specifically say in the Properties and in the texture Preview whether or not the texture uses transparency, and offer an option to flatten it if no transparency is actually being used.


No wonder my attempt at building a skyscraper using transparency to simulate the many windows, and transparency to simulate a wire-grid emergency stairwell, was a complete disaster. Every which way there'd be at least 6 transparent textures overlapping and at least one of them being occluded incorrectly.

here's something REALLY annoying.

make a cylander.. hollow it. Spend hours tuning your texture settings so that some alpha-channel windows on the inside, match up with a texture on the outside...

Now cam around, anw wait for the point where the floor vanishes and you can see right through the outside of your airplane into the inside.

You might have rights to that texture such that you can save a copy of the file, open it in a paint program and save it without the alpha layer.

I had one of those translucent marble textures.

Though this may be a hard problem TO fix, it can be fixed, yes? How does the GL-based design/engineering program Pro/ENGINEER deal with this problem?

Probably what you're not saying here is that "it can be fixed via a brute-force calculation, but at a cost to your framerate".

To which I would say, great, do it, and just add it as another selectable rendering option in the client Preferences. Not everyone uses the avatar vertex program either, so might as well offer this up as another option that not everyone would use.


System message: Multiple overlapping transparant textures have been detected. If the you find the view to be flickering and distracting, you can force transparency correction in the Video Preferences. Note this option will reduce your graphics framerate.

You fail to understand just how much of a rendering cost this would incur. Your framerate would stop being "frames per second" and would become "seconds per frame," or possibly even "minutes per frame." In order to be fast enough for realtime use, occlusion calculations of this sort would require bsp or octrees, and that would require a known static environment (eg. the buildings can't change.)

Your first tip message is a good idea though. SL really ought to warn people this would happen, since for so many people this is their first experience building 3D models, and this is a non-intuitive consideration.

My solution was just to have opaque windows on the outside, and transparent, tinted windows on the inside. Works pretty well.

Admittedly, that's a workaround.. but maybe that's the old-school mac-user in me.

I know that when you have a hollowed prim with transparent textures.. and the draw order is screwy.. retexturing ONE FACE (even a hidden face) can force the object to draw "more correctly" (we use this trick on windshields on the cars.