Occlusion flickering

Development Rendering
1

I have a large level composed from many small modules (250x250x250 units per module). When I’m quickly moving across the level, I see a lot of flickering, especially when I go around corners.

It is the same problem as the one described here:

Basically, flickering occurse because occlusion query lags 1 frame behind actual rendering.

Is there another mechanism for occlusion? My level is static, so I would’ve been fine with traditional precomputed pvs/object tree.

Also, “bounds scale” ( https://answers.unrealengine.com/questions/121635/pillars-flickering-after-level-creation-tutorial.html ) is specified per-actor, not per mesh, and adjusting few hundred meshes in the level doesn’t sound like a good idea to me am I supposed to hunt them one by one if I forget a few?).

It could be possible to remodel level as entire room as single mesh, however, wouldn’t that cause performance loss, especially if there are dynamic lights involved? Usually adding dynamic lights requires complete redraw of entire mesh, meaning that extra lights on big mesh will use fill rate quickly.

P.S. Enabling r.HZBOcclusion made zero difference.

2

Using many meshes over larger pieces can actually be more performance prohibitive. This is because you now have many more draw calls per scene view than if you were to use large meshes. At some point you can definitely over use modular design.

With HZB Occlusion make sure that you’re using a 1 to enable and 0 to disable after the command r.HZBOcclusion otherwise it will not be set. You didn’t specify directly if you had done this so just assuming you have not on this part possibly.

The thing with HZB Occlusion is that it will take the approximation of a meshes size rather than the bounds box to determine when something should be culled or not. This can help in a lot of cases, but if you’re turning the camera fast or a lot of meshes are being unoccluded at the same time you can see this visual pop-in.

You can also make sure to use the command (in-editor only) for r.visualizeOccludedPrimitives 1 This will show a green box for any mesh that is occluded. The green box will be the Bounds Scale representation for the mesh.

I wouldn’t recommend adjusting all your meshes to increase their bounds. That can be a costly thing to do. So instead if you have an enclosed area Try placing a large occluder mesh behind that wall to block any light from coming through where the mesh is coming into view. This is especially ideal for any darkly lit areas where you have a bright scene outside (ie. cave, dark hallway). Only adjust the bounds scale where absolutely needed and use smaller than whole values (ie. 1.15, 1.21, etc). You certainly don’t want these rendered any longer than they are needed.

Lastly, condensing some of the meshes so that they are larger pieces is a better solution. Break the level up into manageable pieces that can be re-assembled. breaking up a long wall into multiple smaller pieces just means more draw calls compared to a single long wall that would be a single draw call.

I hope this helps.

3

I’m aware that many meshes can result in CPU bottleneck, however, how does engine handle static meshes that are affected by large number of point lights? As I said, usually extra point light results in extra draw call per light and those could kill fps with fillrate overuse.
Does UE4 split static meshes in parts for purposes of dynamic lights or something like that (I somehow doubt that this is the case)?

Also, unity engine, for example, had limit on number of point lights that could affect one object, and once you go over the limit, it was dropping them (extra lights were either turned into vertex lights or spherical harmonics, not sure which).

I have not encountered mentions of similar limits in UE4 documentation and I have not dug through rendering portion of the code yet.

I tried that, HZB seems to cause a bit less flicker, but it is still very noticeable. My geometry is fairly simple too -basically wall plates and floor plates.

Tried that too, but while I do see that meshes are nicely hidden, it doesn’t seem to be assisting me with “1 frame lag” occlusion issue.

So, enclosed area is the only solution right now? o_O

What about PVS (potentially visible surface) trees, protals, aabb/octtrees and other ways of hidden surface removal? I’m sure in version 2 and maybe 3 they should’ve existed, because it was fairly standard practice back when. Was support for those dropped? Is there any plan to add them back?

I mean, I understand reasons for using “1 frame lag occlusion”, but this kind of method is bound to produce popups, so it generally makes sense to make some backup solution.

Also, is there a general guideline on mesh size for modular level design and number of dynamic lights?

Because current situation is a bit weird. Engine is geared towards modular level construction BUT occlusion culling algorithm is not 100% accurate and can produce artifacts I experienced.

4

If you have simple geometry you probably don’t even benefit from occlusion culling much. What is your bottleneck without any occlusion culling? CPU or GPU?

5

The level has several thousand static meshes in it, so I’d guess it is both.

Anyway with occlusion enabled, there’s no bottleneck, and no performance issues. The whole thing is running smoothly at very high framerate and the only issue is flickering.

And frankly, I’m only interested in fixing flickering, not recreating the level.

6

Occlusion culling is just an optimization. If it does cause problems just turn it off. Simple as that. Without actually measuring benefits of something you can’t even know is it helping or hurting.

7

Ahem. few thousands meshes. About 6 thousands, to be precise.

There’s noticeable framerate drop when occlusion is disabled. So turning it off is a bad idea.

Besides, I do not want to turn it off.

8

So next you should test precomputed visibility. I would suggest you to make visibility cells size to match with your modules.

9

Nope. Doesn’t work.

FLickering is still visible while camera is moving inside precomputed visibility cells. Apparently when hardware occlusion queries are available, engine uses them instead of precomputed visibility data, even when there’s precomputed visibility data. Also, precomputed cells are pretty much 2 dimensional - grid of boxes with height, and height has to be specified through ini file.

Also, by default precomputed visibility is disabled.

Would be nice if UE4 team integrated something like into the engine.

10

There are some set of config flags where you can disable HZB occlusion and use precomputed visibility. I have tested and it did work.
Yeah is best.

11

So, precomputed is only used when HZB is off? o_O I’ll try again.

–edit–
disabling hzbo with r.HZBOcclusion 0 did not fix the issue. I still see flickering while moving camera through precomputed volume…

Haven’t found anything that would work in the way you describe in *.ini files. There are some settings for data compression in precomputed visibility.

Also, disabling occlusion from project settings seems to be disabling precomputed visibility as well and the whole level is redrawn. I don’t see flickering in thsi case, but drawing all of that every frame looks like major waste of resources to me.

I might be missing something. Do you remember where that setting was?

12

I give up on this issue, and if it will keep causing serious problems I’ll either go with “cage mesh” suggestion or just roll out my own occlusion culling system. Unsubscribing.