[3.4 beta 5] Occluders are confusing and view occlusion doesn't seem to work

[Zireael07]

Godot version

3.4 beta 5

System information

Linux Manjaro, GLES 3, Intel Kaby Lake

Issue description

I decided to give the occluders a spin. I added two occluderspheres to each of buildings in my racer game, so that the occluders extend past the building by a metre or two.
I am seeing a very modest increase in fps (roughly from 30 to 35) but the vertices monitor still shows very large values even when I'm purposefully crashed into a building (so that it should occlude practically EVERYTHING except my car).
View occlusion in editor shows literally the same things and information in editor as when it's off.

HALP?

Steps to reproduce

? Instructions on how to use occluders unclear

Minimal reproduction project

Not a minimal project, but if I manage to get it somehow going while making sure it doesn't break the project I'll add a commit to my project's GitHub and link back to it.

[Calinou]

Using the 3D viewport's Perspective menu, use the Overdraw or Wireframe debug draw mode to see whether occlusion is actually hiding things. Remember that an object is only occluded if it's fully occluded by a single sphere.

#52347 will make geometry occluders more versatile by allowing arbitrary polygons to act as occluders, on top of adding baking.

I am seeing a very modest increase in fps (roughly from 30 to 35)

This is a 4.76 mspf reduction in rendering time, which is pretty large 🙂

Remember that FPS is not a good way to measure performance differences, since it's not linear. mspf (milliseconds per frame) are almost always a better measurement. This is why competent rendering engineers mention performance figures as mspf rather than FPS.

[lawnjelly]

I still have to do some docs for the occluder spheres. We probably need some screenshots / scene info / min reprod scene to give more info. It could be that being inside the occluder sphere is turning off the occlusion - they aren't really intended for you to be viewing from inside them.

Occluders only work at the level of object AABBs. If the AABBs of your objects are big in relation to the size of the occluder spheres, they are unlikely to be occluded.

Also bear in mind that occluder spheres aren't intended to eventually be used alone. They are a tool in the arsenal for occlusion culling that work in some situations (there will be other geometric occluders hopefully soon, e.g. baked meshes and antiportals). As such they are unlikely to give you huge increases in performance except in specific cases.

[Zireael07]

It's likely the "fully occluded by single sphere" requirement (which doesn't seem to be in the docs anywhere, neither in-editor docs nor web docs) - buildings are large, that's why I put two spheres each.

I saw the PR that adds baking, but I think it's overcomplicating things a little. A boxshape similar to the physics box shape would serve in most situations, after all.

[lawnjelly]

It's likely the "fully occluded by single sphere" requirement (which doesn't seem to be in the docs anywhere, neither in-editor docs nor web docs) - buildings are large, that's why I put two spheres each.

I'm actually thinking of trying an SDF ray marching metaballs type approach to see if it can help deal with the problem of overlap. Or rather it should work, it's just a case of finding how expensive it is. Just haven't got round to it yet (a lot of things in progress!).

I saw the PR that adds baking, but I think it's overcomplicating things a little. A boxshape similar to the physics box shape would serve in most situations, after all.

We should be able to add some other simple occluder shapes. The reason for the baked occluder meshes (which is pretty time consuming to develop) is that a lot of vocal users want a system where they don't have to do anything manually (even if not as effective as a manual system). In retrospect I should have probably added some more primitives first for 3.4 rather than worked on the meshes, but I didn't know in advance how time consuming it was going to be, sorry about that! 😀

[Zireael07]

I tried looking at the scene in wireframe and overdraw, and stuff doesn't seem to be disappearing even when I position the camera so that e.g. the next road is behind a single building.

Can at least the box shape get added for 3.4, that way I'll know if it's me setting things up badly or something legitimately not working?

[lawnjelly]

Is the game "free drive battle"? I did try it out a few months ago.

Roads by their nature are pretty difficult to occlusion cull, because they tend to have long segments, thus the AABB is large, and if any part is visible, the whole will be drawn. An additional factor for sphere culling that I forgot to mention earlier is that the occlusion test doesn't actually currently work with AABBs, it constructs a bounding sphere from the AABB on the fly (centre to further point is the radius), thus long thin objects (such as roads) will be particularly difficult to cull.

Having a look at one of the modular components, this long straight road for example is never going to be culled:

The thing to remember about geometric occluders, is that it relies on the occluders being large compared to the objects being culled. Geometric occluders in many cases do not merge. This is a major limitation compared to raster occlusion, and why it is best used as an additional method along with rooms & portals. You can use geometric occluders on their own of course, but the potential is limited.

For this game given the low poly counts, I would first of all be realistic about the gains you will get from occlusion, even best case it may not be hugely dramatic. That said if you are planning on adding a bunch more details (say loads of procedural props for instance) it will start to help a lot .. and what tends to happen is that when you have occlusion working you alter your design to take advantage of it - you can have far more elaborate models etc because you know less of them will be on screen at a time.

Given you are making a procedural game, I would recommend to use rooms & portals (rather than spheres), and build your modular sections to be a room or series of rooms, with pre-placed portals. For the section I screenshotted above, you could maybe split it into 3 rooms, a central room for the road, then a row of sky scrapers in each of the side rooms. Several parallel portals could cover the passageways between the skyscrapers, and the entry and exit of the road.

This takes a bit of effort to set up and get the best arrangement, but once you have done it, it should work great. You could for example just try it out on one simple modular section to start with to get the hang of it, and see how the occlusion works. Another alternative is to wait for raster occlusion in 4.x, but there may also be caveats with that approach.

OccluderShapeMeshes may help here to some extent too, but not to the extent of rooms & portals. With portals, if you can't see say in between a gap in the sky scrapers, it will cull out a huge section of the map with no more work done. This means you could have huge maps if you wanted.

[Zireael07]

Yep, that's the project! But each of the buildings is a separate mesh currently (they aren't merged to the road) and those should be culled.

Currently working on a rooms and portals setup, but just to reiterate, it seems very confusing to use occluders (at least the 3.x version).

[Calinou]

@Zireael07 Did you figure out how to use occluders in 3.5.2 in the end? Quad-based occluders were added in 3.5 and should be more suitable to your use cases.

To get better occlusion coverage, you can make quads or spheres partially overlap each other.

[Zireael07]

No, as the racer game moved to 4.0 and the other 3.x project was left broken by an attempt to move to 4.x too :(

[Calinou]

Alright, closing then.

[Zireael07]

Yeah, I expect quad based occluders would be the solution (are they going to be available in 4.x?)