Occlussion culling flickering

I bug reported this and still have no response to it, and with 1.10.x naively slated for release TOMORROW despite outstanding issues this has me concerned!

Basically, if you go to Morris (89, 215, 73) you will find my occlussion culling box, the top of which is phantom, and insides of which are 'invisi-prim'. From this you can observe occlussion culling.

At the moment OC is berserk! Move around, look at different angles, you will notice that more often than not the areas that are culled flicker horribly into and out of view again. FPS for me spikes as a result between 5 and 25 fps, which is WORSE than with OC disabled, as with it off I'm at least consistently low around 12fps.

I submitted a bug report on Sunday (report #291903) and have no response. But it's a horrible one, I dunno if it's Mac only, but what I do know is that it's killing performance for me completely where I go in Preview, whatever was done to fix the OC not working at all seems to have end up with it flickering instead

I really do not think that LL should release this tomorrow, even if this bug can be fixed overnight. It's one thing to delay an awesome new feature like OC just to get something less important (IMO) like vertex shaders right, but to rush the whole thing out with continued driver issues is not the way. Release should be at least a week after the preview is considered to be 'stable', just to ensure that as many bugs are fixed as possible.

Not to mention the only feature I want from this release seems to be broken again with this bug

I understand your concern. Here's why occlusion zones flicker in Morris (aka "The Abomination":

The occlusion culling algorithm works as thus:

1) Bin up all the objects into an octree
2) Read back occlusion queries from last frame
3) Frustum cull, marking all objects inside the frustum that are not occluded as visible
4) Render opaque objects marked visible
5) Issue occlusion queries

A few days ago, we caught a bug where occlusion nodes would expand to encompass a moving object during step 1 and if the node was occluded the previous frame, it would mark the object that just moved into it as occluded, even if the object was visible, causing it to disappear for a frame.

In other words, it would make attachments flicker randomly.

To fix this, occlusion nodes that change by more than 0.25m have their previous occlusion query discarded and assume that they are visible. This prevents the unacceptable case of not drawing something that you can see, but occasionally incurs the performance hit of drawing something you can't see.

However, since the octree is just that (a tree), child nodes thrashing around won't cause a parent node to lose its occlusion status unless the things that are thrashing around are larger than the things not thrashing around, like if you're standing inside a small room in the middle of a field of flexis.

And you good folks gave us The Abomination that is Morris. It's a great test case. Good work!

So that's where we are. If you want to see for yourself what the octree is doing, turn on the octree debug display (Debug->Render->Info Displays->Octree).

To be clear, I love your occlusion box (spent a lot of time in there tweaking occlusion), and the flickering bugs me, too, but it's no show stopper. I'm going to work on at least minimizing the flicker, but not for this release.

I'm still noticing some odd behaviour in places though, like if you try a box in Gibson (184, 236, 23), the cyberpunk city, an awesome example of an urban setting, you can see that it's randomly putting things 'back' that I shouldn't be able to see. If you look around then you can see that everything BUT the items that I can see are there, is this correct? As when I look around you see everything that isn't visible (isn't in the angle of view) but it then rapidly disappears, which is strange, surely it should already be culled?

Also some things that aren't being culled there. I placed a box, hopefully it'll still be at that location (this doesn't constitute literring I hope, as I understand the preview grid is like a clone of several main-grid sims?).

I'll also make the OC box buyable for L$0 from it's Morris location. There are two parts, the box itself, and an invisible 'lid' (with the visitor counter on it), the lid is required unless you want to look up and have the sky culled as well.

Though it does appear to perform much better in Gibson than in Morris, which has put my fears at bay for now

Things being visible for the first few frames they come into view is a side effect of the hardware driven nature of occlusion queries. Occlusion queries only work on things that are in the field of view, as they are based on the depth buffer. They work by putting the card into a state where it counts the number of samples that get drawn to the screen, rendering an object, and then reading back the count. So, if something is off screen, the occlusion query is meaningless and can't be trusted.

When you swing the camera around in Gibson (my favorite build ever, BTW), the occlusion culling has to rediscover the occluders, and it only checks a few (32) unknown nodes per frame. Since gibson is so huge and dense, the search takes a little longer.

What I do is look at the k-tris drawn counter in the stats bar and spin around using the keyboard in third person. If there are no spikes in the number of triangles drawn (or the framerate), things are working well.

Oh, and the terrain patches you see are visible because they're too big to put into the tree without doing damage. They're huge because they're cliffs.

Oh cheers, that's really helpful to have it explained! Thanks, and keep up the good work then, I guess I was just over-reacting when the problem really is just that Morris is horrible