[GeometryNode] New Frustum Culling Node
I made a little mockup of what I consider an important node in the current implementation of geometry node, the frustum culling node. In order to increase speed, it is important to avoid geometry or texture overflow.
Having the ability to directly access distance from the camera, or from viewport point of view, seem rather important.
In this mockup, I didn't add distance from viewport as it could be another node, but I think it's important to have those nodes.
Currently, the only workaround would be to get camera position and rotation, and with driver to get field of view, do some math in geometry node, and then lock camera to viewport to get the same in the viewport (really hard and destructive workflow)
I'm looking at creating a custom node to support the COPC tiled pointcloud format , but I need the camera or viewport-camera location, frustum and distance in order to draw only what is needed.
I am also really waiting about the new caching system of geo-node that would allow to not compute the node-tree every time, that would allow to add/remove only part of geometry (or point cloud) without having lot of IO lag induced by the computing of every other node.
I often work with datasets that can't be drawn all at once (even with 24gb of vram) like photogrammetry scan of large sites.
Furthermore, i'm aware that the cycle's engine when creating BVH sort of already does optimization concerning occlusion and frustum culling. Eevee does not have this.
8 Comments
You suggest too high level option. Need just combine this things:
This camera info node would be really handy, but it also should be viewport-camera (the virtual one you use to view your scene).
You can always just snap a camera to your viewport. Implicit access to it would be redundant...
Yes but this is a hack, it's like if you want to have 3D in 2D viewport, you can always make dot product and matrice transform... Or you could implement a proper solution that can be used everywhere after.
Still very needed two years later, most of all with more and more GeoNodes capabilities!
I agree with this - I've made the nView add-ons which make implementations to help with this, and have posted experimental geometry node groups for this issue on BlenderArtists . Although plugging in info manually or with drivers is currently possible, it certainly could be a lot easier. I hope the linked code change someone mentioned goes in; a geometry output with the frustum box alone would be perfect, especially since that box could be more easily manipulated or connected to other nodes like boolean.
Thanks for this add-on, I don't have the skills/time to implement that, do you think it would be possible to make proper implementation in vanilla geometry node, I think a lot of people could use this everytime, and it should be a default, juste like the extrude node that was possible back before it exist with a hack, but nobody used this hack. Now some people do simulation in geo-nodes using a hack, but they are working on implementing that, so it is propper solution supported and nicely designed.
I mean, the branch modormoder had at least some of the code