Frustum Culling method for Objects in-world

[3x1t-5tyl3]

Is your feature request related to a problem? Please describe.

Another way to cull objects more aggressively.

Relevant issues

Not found any?

Describe the solution you'd like

FrustumCulling in a way that would allow me to disabled a hierarchy based on if someone's frustum is intersecting or not.

This would be another way of more aggressively turn stuff off/cull entire sections if they're not even in view.

Describe alternatives you've considered

Different culling alternatives. Though I don't know of many ontop of my head at this time.

Additional context

I want to specifically mention that I'm not sure how well this could work. Ideally this would something where the gpu talks to the CPU in order to turn CPU bound objects off dependign on what the GPU sees.

I'm unsure whether this is even possible (current or future).

I'm also not sure if the performance benefit is worth it. Something to definitely be considered anyhow though.

[Zyzyl]

Neos already does frustrum culling for rendering. Are you wanting a system which would e.g. specifically disable slots as well? If so, why specifically?

[3x1t-5tyl3]

I'm aware of rendering frustum culling. I was interesting in culling logix and objects (slots) with it as-well to disable functions or heavy components (such as cameras for example) or other things which aren't as easy.

Obviously I don't need to mention how an internal frustum culling would be better than doing my own math in logix as it's already beign computed and could (hopefully anyhow. i'm speculating heavily here) be used to cull objects/logix/ect as-well.

[shiftyscales]

Can you not just do this using collider user trackers tied to disabling those parts of the hierarchy when the user isn't inside of it @3x1t-5tyl3?

I'm still not really sure what you're specifically looking to accomplish by this- like- I get that you're wanting to be able to disable targetted slots with this- but what is that offering over other methods that are available now?

[shadowpanther]

I assume 3x1t is asking for a node/component that locally returns "is this spot being looked at" (does it fall inside the camera's frustum) or drives a value based on that. We have UserDistanceValueDriver for example that can answer "is this spot closer or farther than X meters".

ColliderUserTracker works better for the second one (as the distance could be replaced with a sphere trigger collider), but it doesn't care for user's camera/head rotation.

[3x1t-5tyl3]

Yes. ColliderUserTracker is good for "don't render if not inside" which works for worlds. But not objects or things on those objects, avatars ect.

Also "beink looked at" is not quite right. I meant if the user is seeing the object or not; I might as-well disable other functionality (not all the time mind you but more often than not) such as logix, components which might be heavy (such as cameras or similar).

Edit: As some objects might be more complex than a simple sphere so not all simple methods work for all occassions.

[Frooxius]

I don't think this would be a good approach for this. The user's frustum is by its nature very erratic as the user looks around, which would mean you'd be enabling and disabling chunks of hierarchy very rapidly, costing you way more performance than you'd save.

It gets a bit more complicated, because not everything you're not immediately seeing should be disabled either - things that are outside of your view can still affect things in your view. This can easily lead to more pathological behaviors, where some things don't re-enable or will start oscillating between disabled and enabled.

Usually the better approach for this is a bit fancier culling system, e.g. #175 and similar, rather than something directly user-facing like this. You want the systems to be aware and prepared for the culling, rather than forcefully turning them on and off and that requires a bit more involvement.