@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 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.

@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.

@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.