# Compute on all points in geometry nodes

I try (for a while now) to make a gravitation simulation with geometry nodes. The computation is not complex, and I get something that is almost OK.

The problem is that it seems that it's not possible to make a computation from the entire points. We only can get the "nearest" point position.

So, the simulation works only partially, the gravitation is applied for all points with its neighbor, but it should be computed with all the others points.

I provide the example blend file.

(Using Blender 3.6.8)

Let $$N$$ be the number of bodies. Gravity acceleration for body $$i$$ due to bodies $$j$$ is a function of $$\forall i, 1 \le i \le N, \ \vec{a_i} = \sum_{j \neq i}^N \frac{\vec{M_i M_j}}{\|\vec{M_i M_j}\|^3} \simeq \sum_{j}^N \frac{\vec{M_i M_j}}{\|\vec{M_i M_j}\|^3 + \varepsilon}$$ where $$M_k$$ is the position of body $$k$$ and $$\varepsilon$$ a small positive not zero value.
As a conclusion, two loops over $$i$$ and $$j$$ are required.

The following approach is using a Simulation Zone for the $$i$$ loop, and an Attribute Statistic node for the $$j$$ loop. From Blender 4, a Repeat Zone should be preferred over the Simulation Zone.

The following approach is using a Cartesian grid to mimic the $$\left[\vec{M_i M_j}\right]_{N \times N}$$ matrix. The doublet $$(i,j)$$ is encoded in the grid points index $$n$$ as $$n=i+j \times N$$. Furthermore, $$i$$ specifies those points ID used by the Accumulate Field node, which is then computing the summation over $$j$$ for each $$i$$. The double-loop over $$(i,j)$$ is performed through the Set Position node.

Resources:

• Damned, I just found approximately the same solution using a repeat zone inside the simulation getting the domain count and sampling index. Thanks a lot for your answer, I'll take a look on your method to see if it's not more optimal. Feb 27 at 13:14
• The Attribute Statistic node should be optimized compared to a Repeat Zone. An Accumulate Field could also be tested as it is dedicated to summation; but it is producing extra data not required in this case. Feb 27 at 13:20
• I don't know how this node works ;), I will check the documentation. Just one note: you don't need to sample index for the current point, the "position" attribute is the current one. At least, on my setup, it works. Thanks again for your advices, I'll check the attribute statistic. Feb 27 at 13:25
• The second solution based on a Cartesian grid is most likely redundant with Markus von Broady's proposal from a mathematical point of view. But as the grid could be permanent outside the simulation zone, the creation/deletion time of the point cloud could be saved. Unless Blender is caching in memory every iteration... Feb 27 at 18:28
• As I'm working with a points cloud, I need to iterate over the points IDs, so at this time, a repeat zone is (I guess) mandatory. I'm currently testing Accumulate Field node to understand what is the usage. Feb 27 at 23:15

(if you're using this as a template for your gravity sim, notice I don't use a gravitational constant)

Repeat Zones are a bit slow, not sure if the Stef's answer would be slower than mine, worth to check… Meanwhile here's an answer using the "quadratic geometry explosion" (just made that term up) pattern, that I also recently used here. And, like there, I'm optimizing distance checks by applying negative $$-100 \%$$ scale, so that the point I compare to is at origin, and position vector length equals distance to that point. Not sure if this is actually a useful optimization here, though. I also capture radius on the parent-point so it transfers to a spawned instance, and upon realizing instances transfers to the children-points. Now I can easily access the radius of a current point, and a parent point (captured). I use radii to store point masses (could use a separate attribute, but that would increase cache size)

The Attribute Statistic node returns a single value, but an Accumulate Field node also sums up values and can be separated by group. The positioning on index to sample nearest at that index could be optimized away as well as the last Capture Attribute node could be removed…

Notice this relies on the input geometry. I prepared two examples of input geometry for testing:

## Test #2: Unstable Constellation

This is why triple-star systems don't exist: there's no stabilizing mechanism that puts bodies back at equal distances when two of them get closer than the other due to some external chaos (here the chaos is just floating point datatype inaccuracy).

• Your approch works but the problem I mentionned uses a volume of points. I also (later) add different masses and radius to points. At this time, a repeat zone is the more "readable" method that allows me to computer gravitaion between each points. Anyway, I keep your answer to make some tests. At this time, I'm not sure hwo to understand how the "Accumulate field" works, I'm currently testing :) Feb 27 at 23:11
• @Markus von Broady: would you mind if I write an explanation of your brilliant (and dense as a neutron star...) approach ? It took me some time to "unwrap" it. I am planning a post like this: blender.stackexchange.com/a/310561/177431. Feb 28 at 9:02
• @StefLAncien I know very well what is obvious to me can be very hard to understand for others, but I stopped thoroughly explaining my node trees when I realized the walls of text likely repulse people from an answer rather than making it more attractive :D But if you want, feel free to make edits, I'm not defensive when it comes to my posts (I have a feeling this is not the case with many other users on BSE). Feb 28 at 10:41
• @StefLAncien or feel free to write a separate answer as well like you did in the linked post (have just read it). Just don't write "it's not an answer", as it is (and otherwise would be against the site's rules, though mods are lenient for high quality content) Feb 28 at 10:45