About performance and occlusion culling

[Lo Zeno]

I know I am about to do a risky thing, by starting a discussion from a point that was raised in a terrible thread that has just been closed, but I feel like it's worth the risk.
This sentence by Moon Wizard deserves a follow-up

* There is no magic solution to determine whether to calculate tokens/blockers/lights when they are "visible", since you can only determine if they are visible by calculating them.

Please @Moon Wizard hear me out:
I don't know if you were just oversimplifying in your response to Weissrolf, and technically you are correct (which is the best kind of correct, I know), but after a good chunk of time spent on the last beta I need to ask:
Is FGU using any kind of occlusion culling at all? Because from the way the software performs and the sentence quoted above, it surely feels like it doesn't. It always feels like it's really calculating every single light, blocker and token at every frame, instead of using strategies to "cull" away cells of the map that do not need rendering. That impression comes from the fact that if on the map the characters are in a room, and the NPCs in another (hence invisible to the characters), and the GM moves one of the NPCs in that room along the wall, all the PC clients slow down as if they were to re-render the scene.

Now, as I said you are technically correct that there is no magic solution to avoid calculating whether a game object in Unity is visible or not, but there are tricks, and Unity does support Frustum Culling through the Umbra library (https://docs.unity3d.com/Manual/OcclusionCulling.html). I haven't done much in Unity in a long time after I changed job from game development, but you definitely can use the area made visible by the LOS as a set of cameras, and use those as the frustum to determine what's in view and what not.
As Unity's documentation says:

Occlusion culling works best in Scenes where small, well-defined areas are clearly separated from one another by solid GameObjects. A common example is rooms connected by corridors.

Which is, incidentally, the most common scenario in a RPG map.
This is exactly the kind of algorithm that would determine what would need to be rendered as "visible" and what shouldn't (obviously it needs work, fine tuning and so on), so if FGU isn't already making use of it, I would like to ask: what is stopping it from being implemented? Is there some issue that makes it less than ideal to be used?

[Moon Wizard]

I don't know the exact implementation that @cpinder is using in culling out data that doesn't need to be processed; but I do know that he has explained to me that the way the blockers are placed does have a greater impact on performance than the number of points, which seems to point to culling and other optimization work being done.

However, instead of delving into minute details about specific cases that are difficult to explain to an end user, I just used the concept that more data = more work. In most standard RPG scenarios, we're dealing with towns, castles, dungeons, etc., which do not exhibit the worst case scenarios (or only in small doses).

As you have seen in other threads, delving into the details does not actually accomplish anything except to spin a bunch of developer time trying to explain instead of working on the product; which is why we ask for specific test cases from actual games that are not performing.

Regards,
JPG

[Weissrolf]

MOD: post deleted at user request.