Geometry node and viewport culling?

Hello

It seems that geometry node is doing some viewport optimization with the instances

sdfsdfds

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

Cheers

That looks more like a bug or a drawing artifact to me honestly. I’m not aware of any culling that would do that.

1 Like

would you like me to report it as a bug?
Render don’t seem impacted

Yeah, if you don’t mind, I think it’s a good idea to report this and see what happens. Thanks!

Here we go
https://developer.blender.org/T91606

artifact in the given example .blend

If i encounter a stronger example I’ll update the task

Looks more like a z-fighting issue to me. What are your near and far plane settings for that view?

It looks like it is a known drawing issue when using large clipping
I was absolutely not aware of this issue

Brecht:
Please see here, the clipping distances in this file are beyond the z-buffer precision of GPUs.
3D Viewport — Blender Manual

1 Like

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.

1 Like

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.

1 Like

All this can be done already with the camera info node

Let’s try to stay low level to fit as many usage as possible, nodegroups could be done for culling usage

Yes, I agree, it could be named Frustum only.

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.

Does blender need optimization solution? YES Absolutely. Is geometry node the right place to implement these solution? I seriously doubt that.

Most softwares have global settings, that culls any far away instances in the 3D scene for example. See that’s the right approach, that most softwares I know seems to follow (Houdini for ex)

Is needed ? Yes but not in GN (Not really efficient, like a real culling), directly in the CORE ! For the viewport and render with custom distance and a custom value fading the geometry.

This isn’t the place for feature requests, not the first time we warn about this @Stimes

1 Like