@Jerry Perkins (mx1001) haha, glad you're enjoying it!

@Yuriy Lisytsky Thanks, I'm glad to hear! Have you tried comparing your file to the result setup in the description? If that doesn't help you can use an image sharing service and paste the link here, so I could take a look.

@Simon Thommes , Thanks, I just remade everything from scratch and it works now. I have got a bit better understanding of the setup.

Found it! Somehow bumped the "instance" selection on the Delete Geometry node.

@Dar Toften Great you found the issue. Accidentally changing options or values when navigating the node-tree interface is something that can happen and is difficult to identify. Something I do a lot, which helps with this is to hide options and inputs which I know I don't need to change, so they disappear from the interface.

Hiding inputs is on CTRL+H and hiding options is in the context menu of the node, I bound it to ALT+H myself.

@Sironious Make sure to study and understand the theory part of every chapter if you struggle with the practical example. I'm explaining everything in there.

@Najette Chouchane Can you try comparing your result with the file download to see if there is a difference? Otherwise I'd need a bit more information.

@Simon Thommes  I found the problem! I compared the 2 files and found that I made a mistake. I didn't attach one of the nodes to the join geometry node. Thank you!! It's all fixed now.

@Najette Chouchane Ah, that's great to hear!

@Crisp Ness The normal is not special in terms of how geometry nodes deal with it. It's just derived data on the face domain. The set position node operates on the point domain, so that face data is interpolated to the vertices. This is similar, but not exactly the same as the vertex normals. Currently there is no way yet to read or write to the custom normals used for rendering, that are on the face corner. But this will be added in the future, it is planned for 4.0 afaik.

@Simon Thommes Thank you for your clear answer, so far from the future. Apart from it being the answer to the specific question, there is extra value in it. It shows me how I can reason about GN and what concepts to consider.

@Ingmar Franz Hi, thank you for the update! It looks though that the viewer node doesn't work in my setting. I connected the Points output from the Distribute Points on faces node to the Target input of the Geometry Proximity node (as shown at 09:00). Then I connected the distance output of the Geometry Proximity node to the Value input of the Viewer node. And then geometry of the whole setting I connected to the Geometry input of the Viewer node. I can't see any results in the viewport. I've checked all the methods of viewport shading and I've also checked if there are any checkboxes in the Overlays settings that would allow me to turn on/off the displaying of the viewer node results, but I didn't find anything related.  At this point, I can't figure out what am I doing wrong, so any help is appreciated.

@Anna Panova I couldn't get the viewer node to work either. I noticed that if I passed the position attribute to it, like he does at 8:35, my rocks also have some position colors, in addition to the ground plane. I gave up and just followed the instructions in the video and it worked for me.

@Nickolai Belakovski @Anna Panova It's a bit hard to say what the issue is like this.

Can you confirm that the viewer works in general for you, by just connecting the position? Also make sure every setting is the same as in the video. For example the geometry proxity node needs to be set to points to work properly here. And keep in mind that instances are not real meshes. So if you have instanced geometry the viewer cannot consider the transformation of the instance but just the original mesh.

@Simon Thommes When I connect the position attribute, I get a 4-color panel that looks like yours in 8:35, but with colors on the rocks as well. Oddly, the order in which I connect the position attribute and the geometry changes what the output looks like. I've put screenshots and details about the order here: https://imgur.com/a/0vdF3iL

@Simon Thommes I think I see one reason I get different output based on the order. When I ctrl+shift on the "join geometry" node, the second input on the viewer node is a float field (white in color), but when I ctrl+shift on the position the second input is a vector field (purple)

@Nickolai Belakovski Yes, the reason it's black and white is that a vector is connected to a float socket. That shouldn't happen with ctrl+shift+click. If it does, that's a bug.   the reason that the rocks get colors that are not consistent with the ground is that they are instances. The actual geomtry you are inspecting the position of is without any transforms at the origin. And then the rocks are instanced, moved and rotated into place. If you Realize Instances before the viewer the position will be consistent, but then you are not benefiting from the fact that the rocks are instanced anymore.

@Ingmar Franz Field inputs that don't have a slider exposed usually fall back to a default field input, just the same way that texture nodes don't need to have the vector input connected. When you hover over the field socket you can see what field is used. Here it's the position attribute.

This position relates to the geometry you want to evaluate the proximity on, not the target geometry. So usually you don't need to connect anything to get the proximity of points to a target geometry. But you can essentially override the position that is used to sample the proximity without actually moving the points. And if, for example, you plug in just a single vector, you get the proximity of that virtual point at the position that vector represents to the target geometry, for all points.

@Simon Thommes Thanks a lot! Now, it's clear what this "Source Position" input socket does with a single vector connected to it. Is there an important use case where you need for every point of the source geometry the same distance value derived from a single point's position relative to the target geometry?

@Ingmar Franz I don't have an exact use-case, but that single point could for example be an empty that you can move in 3D space. Sou you could use the proximity of that empty to a target geometry on all points.

@Yevtushenko Oleksandr The reason is most likely the randomization of the scale of the rocks. Because this system is not actually detecting mesh intersections, but only removing points in a certain radius, as soon as a rock has a higher radius that will lead to an intersection. The randomization of the rocks, as I have it in the file means, that some rocks will be slightly scaled up and thus still intersect in some cases. When you change the randomization maximum to 1, that should disappear.

@Simon Thommes Maybe, the instances of the small and medium size rocks should be realized ("Realize Instances" node) so that we can use the vertices of these rocks for measuring the distances. This could perhaps further reduce the probability of intersections.

@Ingmar Franz That does work, but it is also a lot more expensive to calculate. Especially because it depends on the complexity of the rock mesh.

@Simon Thommes Aha ! Sounds perfectly reasonable.

So, the scaling is done AFTER the distances are measured and instances removed, and this might create new small intersections after scaling (In my blend file I have a bigger scale range, that's why it happens more often). The rotation node can also interfere with proximity calculations if rocks aren't perfectly round. And of course, if vertices on a large rock are not close enough to the closest faces on medium/small rock, then they still can intersect.

Thank you for the answer ! That clarifies things to me.