This is really good tutorial! If you're going to be doing close up shots, the only modification I'll add is instead of treating the grid as a lens, to treat it as a sensor. Which means change the Z-vector in the "Combine XYZ Node" to -0.1 (or smaller) instead of -1 and adjust the grid size accordingly (I ended up using X=0.08m & Y=0.05). This would avoid the grid from intersecting with the plane in close up shots and cutting off those objects (since the plane intersection stops those point rays from reaching the raycast node).
amazing tutorial, im wondering, how can we optimise it even more as if there is an obstacle like a plane between camera and monkeys, it block the rays and so everything behind obstacle will no appears ?
Great tutorial, thanks! 👏 It can also be used for large terrains, like a boolean, but much faster in calculating! Just add a "delete geometry" and reverse the "is hit" output! 😉
Hey thanks, this helped me a lot. Really sped up my current project's viewport performance. I might have found a slightly cleaner nodesetup. I think rotating the camera location for the set position offset is just recreating the normal of the plane that was just rotated. So I just added a normal input node and scaled it negative something. (Drivers from FOV and sensorsize/-2 and some offset to position... it works fine here) Mag deinen Kanal sehr gern. Grüße h
Sir when we decimate anything in blender for example sphere and if it is already texture and then we decimate this then model texture become break can u solve this issue pls
whats the trick with only selecting/raycasting onto the surface that is visible to the camera. As this setup is right now, you will end up instancing onto geometry that maybe behind surfaces or inside other geometry.
Hi Chris! I have viewed this many many times by now. Really, really useful, thank you a lot! I was wondering tho if there was a way to implement some sort of occlusion culling for proper geometry (not instances) in geometry nodes. Do you know any way or workaround? Again, thank you a lot anyway! :)
I have a scene where instead of static objects, I'd like to cull a volume of slowly moving particles. I get them to move via tranlsating them along a random axis via the scene time. Unfortunately every time I move the camera, the particles jitter as the rays are being casted from moving particles. I haven't been able to think of a solution to this with both the camera and the instances moving due to where the raycast selects points in the node tree. Any thoughts?
Now that you can do that, is there any way to have a object always point towards the camera? Like a plane with an image on it. So as the camera moves the plane always points to the camera. Thanks a lot
So I have a question. What if we have a scene with multiple cameras and at some time in the animation we change the shot; switch to a different camera as the active one. Is there a way to make these geometry nodes-instead of only to this specific camera-to automatically concur to any camera that is the active one at any given point in the animation? (As opposed to having to select which camera manually, which it seems isn’t even possible animate anyway.) Thank for for your wonderful tutorials my good sir!☺️
Although I can not think of an automated GN setup to do what you want, meaning changing the cameras by looking at the camera bindings in the animation timeline, there is a kind of a half manual way to switch cameras in GN nodes: Instead of exposing the camera object input into the modifier proprieties, you can build a switch based system inside the GN, that selects different cameras based on an integer number for example. Then you expose that number to the modifier proprieties and animate it to match your camera swapping. That is how I would do it. If anyone has a better method in mind, I would like to know about it.
Ok this is so cool! I'm currently fiddling around with UPBGE (basically a fork of current blender with old blender game engine functionality) and this is propably great to improve performance.
Thank you! The graswald3d, creator of G Scatter should use the length clamp on his addon, is a very good one but has false positives in the camera clamping
It was a great Tutorial! I do have a question, Is there a way to make it low poly when the distant of your instances far from camera as similar function as adaptive subdivision ?
I am thinking of a smart LOD system to implement in the version 2 of my currently "work in progres" project: The stellar system. What I plan to do is a material/geometry swap based on the percentage of the camera screen occupied by an object, in my case a planet, black hole or star. What I think it will work is bringing the render scene size (the culling plane size) into GN and compare that with the bounding box of the object and then, based on the screen percentage occupied decide on the material/geometry with the proper amount of details. I would be curious about what other people think, if they have a better solution.
There are no dedicated nodes for camera data in GN for now. But you can use drivers to get most if not all of the camera data and the scene size. Just right click on the value that you need and select "Copy as New Driver", then use an value node in GN, right click on the input field and select "Paste Driver". Apart from python, I do not think there is a way to acces this data inside of Geometry Nodes. Hope this helps you 😀
Great Tut! What if on the edges istead of just disappear, the instance objects get the scale reduced out of the camera view then disappear? I guess this way the light changing and bounces will be smooth and harder to notice in cycles final render.
Hey, Great tutorial! It helped me a lot, but I have a problem. In the shader editor, I had random values on color ramps so my objects would have randomized colors. However, when I applied "culling," the colors of my object started to change every frame. What can I do about that?
Hi, with the geometry nodes setup from the tutorial this should work since we distribute points and only instance to the points inside the field of view. That way, all of the points are always there and always have the same object id and will produce the same random value in the shader. See ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-0-XrdknEA4A.html
This is great! I just combined this with we:teach's WINDY GRASS tutorial and now I have a highly optimized wheat field that blows in the wind. It only took my moderate understanding of Geo Nodes to combine them together and it's awesome!
It's funny. I did the same kind of setup last year with Blender 2.9 to manage vegetation and foliage in a very large scale scene. I was a little disappointed when the field based on geometry nodes arrived but now I know how to readapt it, thank you. 😁👍 Now if you implement automatic orientation on instantiated planes towards the camera in a proxy system with a camera far vanish cut-off you get the same sprite system that saved my life last year.
Thank you so much. I have been looking for this for a while. I almost got it to work, but the rotations where always off. I just did not understand the ray source being on the right... still does not make sense, but now it works!
Thank you for the great tutorial! I noticed that the rays also shoot out from the back of the camera in addition to the front. Any fix for that? still trying to wrap my heads around all these nodes. Lol
If we can parent cam to selected 3 vertices to noise camera so is it possible to make your autofocus setup from AN? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-xaHjIA4Eo_g.html
