# Proximity colors between instances of a same pack

I'm trying to do a little effect where instances (any kind) on points would change their color based on the proximity of another instance.

Thanks to some tutorials and questions here, I've successfully made a proximity color change between two objects. I tried to apply the same to instances, using a kind of "for each" logic. Not really working, how should I be doing this ?

Thank you !

----- EDIT :

Here is a picture edited : As an instance become close to another one, or many other ones, they both change their color to A. While the lonely ones gets B. In this way, while the whole thing is animated, colors will changes as the instances get closer (gradient like) till the "collision color"

Nowadays, there's an Index of Nearest that returns the index of the nearest element in the context domain, not including 'self', which saves a lot of the duplication and wrangling that was once needed.

The position of that element can be evaluated, and the distance from 'self' derived.

In this example the minimum to maximum distances are normalized, 0-1, as an attribute on instances, to be named in the modifier UI, and used in a shader:

The instances closer to others are coloured towards red, and more isolated instances, towards blue:

Something like this? The stripes are of the color of the nearest ball:

# Simulation

After OP's clarification: You can of course store the distance to the other ball just like you store the color of the other ball. Problem is, what if suddenly another ball wins the competition of being the closest ball? Then color switches suddenly. You could use a simulation to avoid sudden color change like so:

• The left 50% Mix node mixes self color with nearest color, otherwise ball A would turn into B's color, and vice-versa, effectively resulting with touching balls still having different colors...
• The right Mix node is a standard smoothing technique in geonodes. It takes current value, target value, and mixes between them, having a high/low factor (depending on the order of inputs, here a high factor) to give much more weight to current color, so that it takes many frames to mix with the target color.
• The Map Range node connected to the above is controlling the factor, changing it from very high (very slow), if the balls are far apart, to medium if they sit at the same position (it would be extremely fast, but balls never sit at the same position, so practically it's just 'rather fast').
• The rest controls the movement of the balls, keep in mind it's just a placeholder and you can probably create better movement by maintaning velocities and reflecting (Vector Math: Reflect, using the position difference as reflection normal) them upon collisions for nice bounciness (or for elastic bounciness just do what I already do but with accelerations instead of direct position changes).

Also you can improve on the color changing logic by returning to the original color whenever you're far enough from the nearest ball…

# Old way

old way is not necessarily a bad way - depending on what kind of effect you're going for, you could simply set the color of the balls to the noise texture:

• Hello @MarkusvonBroady ! Thank you for the help. It's not exactly what I meant, but, there are a few nodes here and logic that may help me progress further. I updated my answer to precise more what I'm trying to achieve. Commented Jun 12 at 6:35
• Not sure whether I should delete my answer as surplus to yours.. depends on interpretation of OP, so will leave it to Zazou... Commented Jun 12 at 10:40
• @RobinBetts turns out I misunderstood, still, I'm not a fan of deleting answers when they don't clearly state the same thing. Commented Jun 12 at 12:30