My guess is that in the future you’ll be able to use any generic attribute to control the skin thickness. For now though, I haven’t seen it exposed.
@BD3D I’ve also built a node group for camera field-of-view clipping.
I’ve used multiple Transform nodes to transform the whole scene to prepare for clipping, which I’m guessing collapses to a single matrix applied to each point. From a performance perspective it works well - even for camera fly mode where recalculation is done for each frame.
You can download for free, and I’m happy for other people to build on this work.
Download link
YouTube node group details
Aha nice work!
note that it’s not working when we look down ? 
prolly because you are working in two dimensions? (i had the same problem except with this method)
TBH I believe that it’s best to wait for a way to remove points inside mesh volume and use a nodetree that automatically create a frustrum mesh like this set-up (run script to sync inputs with camera)
I believe that @victorlouis did speak about an upcoming solution to detect if points are inside a mesh volume on the blenderchat
It looks really cool but again, I think this kind of thing would be better implemented as a feature at a much lower level. For the viewport/eevee when moving to vk using compute shaders would spare the per-frame CPU->GPU back and forwards and be easy pickings for moving to mesh shaders in the future and occlusion culling. Cycles could just do it under the hood as well. The user should not have to concern themselves with setting up culling manually inside of the node system, performance should be available by default.
Note that it can’t be done on a shader level (in eevee/cycles), it must be an optimization that work both on rendering and when working in the viewport solid state.
1 Like
That is why I recommended doing it in the viewport first and foremost. Shader not as in material but as in gpu program. The viewport in workbench and eevee would both benefit from the compute/mesh shader optimization for culling. The CPU would never have to be involved or aware of any culling until you prepared the scene to be uploaded to a render engine like cycles, making it painless to tightly cull millions upon millions of instances in realtime every frame (even with occlusion culling) with next to no performance impact. This is the preferred way of doing it in newer game engines.
4 Likes
Hi all,
I hope this is the right place to offer feedback - I just googled it. I LOVE geometry nodes, I won’t pretend to understand half of it, but what I’ve done so far has been amazing. A minor bit of feedback:
It’s REALLY easy to accidentally create a new object in the object collection you are creating instances of. If you then try to add the same geometry nodes to that object, it crashes the application, as imagine it’s thrown into an endless loop.
So some sort of restriction for this might be in order for buffoons like me.
3 Likes
The point of culling early in nodes(or on the cpu) instead of just for the viewport is you will save all the geometry node / simulation cost downstream. It would be pointless to generate a million instances and wait to the very last second, during viewport draw, to remove them. Better to cull the number down as early as possible before they’re passed to more, expensive, nodes down the line etc. Perhaps that could also be done async on the GPU but you need real data to pass back and forth to the GPU in between nodes then.
Beyond that, a simple forward cone cull like the above isn’t really viable. You’ll want to extend the cone a little outside the camera frustum to ensure that objects just outside the edges still cast shadows correctly into view (important for animations) and extend the cone backwards behind the camera so that reflective objects in view can reflect what’s behind you. It almost needs to be shaped like an hour glass to a certain point.
3 Likes
I’m not sure how much cost would be saved by making a not frame dependent process frame dependent. Set dressing is often just generating a point cloud of instances once and never touching it, hence it is a one time cost which can be stored more efficiency in vram if it isn’t frequently updated. If you have a simulation running on those points chances are you have to update those points regardless. Yes a simple frustrum cull is often not enough however, when it comes to taking into account shadows, large objects, etc, and the renderer should be able to handle that with more insight as well with it’s own information. Users should NOT be the ones dealing with this kind of issue from scratch and focus on creating a scene.
At this point I’m only clipping on the left and right. I guess because it covers “typical” use cases - however if looking up/down, or rolling the camera then there will be lots of excess/unclipped objects. (I was also too lazy to do top/bottom clipping.)
In the screenshot you presented, it looks like 80% of the objects we’re clipped anyway, though additional clipping would have got to the high 90s.
This expected result is what you should be getting now in the latest master since this was implemented.
2 Likes
Yep! Already tested! Thanks a lot! Huge thanks for this feature, no sarcasm!
Hope the Radius attribute will be implemented someday in the near future to use Geometry nodes with the Skin modifier on top of it! That’ll be a bomb!
Could you please report this as a bug? With a sample file (before the explosion happens, or just disconnected from the output).
2 Likes
Sure, I’ll have a go.
2 Likes
Recently I had a chance to play around with Instant Terra version 2.0 which brings a cool feature to animate any parameter in the node graph.
Geometry nodes modifier takes heightmaps exported from Instant Terra and displaces a grid mesh(1024x1024) as well as scatters trees based on terrain’s topology(altitude,slopes,curvature…)
12 Likes
I think you’re conflating 2 different issues here. One is viewport performance and it could be controlled automatically. For example user sets maximum number of polygons that his machine can handle and Blender tries to limit the number of instances that are shown on screen by all the GN modifiers that are active.
But when it comes to final rendering in Cycles, user should have full control of how and where the points are placed. As you said, there could be many issues with shadows or reflections, that no automatic system could take into account.
Hopefully the information I’m sharing is accurate here, I’ve made a tutorial on Attributes in readiness for the 2.92 drop. If anyone finds any inaccuracies, let me know and I’ll address.
10 Likes
Is it possible to scatter points inside object volume randomly?
Not yet 
(I already asked the quesitons a few weeks ago )
Yes I know BD3D, but I was hoping that for this few weeks it was implemented, because it’s like very crucial for anything that is related to create procedural models, and in my opinion it is more important then many other features. It is just like the most basic and at the same time crucial feature that is necessarily for anything to be build on top of it.
1 Like
It seems like a complex task to do well. You can follow the task here: https://developer.blender.org/T85898
1 Like
Erindale THX so much! I didn’t seen this before. I am so excited, that this is considered seriously 
1 Like