It seems that geometry node is doing some viewport optimization with the instances
could users have few controls over this ?
also, why the zebra pattern? couldn’t it cull random points?
This effect did not happen with “real” instanced object
so i suspect this is linked with the geonode code?
perhaps implementing such culling algorithm (with user controls) on an instances level might be beneficial for all
Blender as need just an implementation of Mesh shader (meshlet) for the culling in general, i swear i’m waiting too hard for this implementation for speed the soft and the render and other features like LODS etc…
I have made a proposal for a culling geometry node that would allow viewport camera control. This would allow to not use the camera to view hack and could be used for other implementation such as meshlet, or mesh / point cloud (from local storage or remote). This would be a must-have as currently blender is only usable for stylised movies or modeling small scenes, but when you need to use photogrammetry, you hit the 100M poly or 150M point limit really fast, even with 256gb of ram.
I think the node should be just called “Frustum”. I’d ditch the culling part since it would not be useful only for the purpose of removing geometry outside the viewport. You just get a boolean attribute of whether given geometry is inside the frustum or not, and it’s up to you what you do with it. If it was truly a Frustum Culling node, then it would probably be a geometry data operation node (with the green input and output), not just attribute node.
Second. I can imagine it working for either active camera or custom selected camera, but not for viewport. Otherwise, imagine you have let’s say 9 viewports total open in let’s say 6 workspaces. Each open viewport has different point of view. This would imply that either the geometry node tree has to be updated the viewport amount of times, in this case 9x, instead of once.
Or, it would have to mean that the geometry nodes tree has to be refreshed every time user switches to a different viewport. If multiple viewports are opened in the same workspace, switching the active viewport (editor) takes as little as hovering mouse a mouse over it, so imagine you have a heavier node tree that takes couple seconds of update and your Blender freezes any time you move your mouse cursor from one viewport to another.
Then, the obvious, but stupid idea becomes to start thinking about some selective, manual updating solution, which would be unique just for this node, and then this whole idea starts going down the drain. So I’d suggest just removing the idea this will ever work with the viewport, and just focus on camera only, to save yourself from the scrutiny your idea would inevitably come under.
But no, it should absolutely be compatible with the viewport, otherwise, we won’t ever have any optimization in blender, nobody uses the camera to viewport hack other than for controlling this camera, this shouldn’t be a hack behavior. About the case where you have 9+ different viewport, the frustum only uses the last active viewport and that’s it, no 9 additional culling.
In unreal, I don’t have any issue navigating 3 or 4 different viewports, some being orthographic, some having larger resolution that what’s displayed on the 4k monitor, but it doesn’t lag, even with scenes having a billion triangles, and a thousand of 8k texture, as the engine is optimized and doesn’t display all at once.
If blender stick to hacky behavior, that only cull grass, and only from an object like a camera, and only if there are less than 100million points as each frame the culling need to be reprocessed entirely on cpu, it won’t ever compete with other renderers.