Struggling with collide function (Ignore A and Ignore B)

Hi everyone,

I’m currently working on a Grasshopper script and I’m running into trouble with the Collide function. I have two sets of circles:

  • Circles (outer set)
  • Inner Circles (inner set)

I want collisions only between the inner circles and the outer circles.
That means:

  • Ignore collisions between the outer circles themselves
  • Ignore collisions between the inner circles themselves
  • Only detect collisions between inner and outer circles

I’ve attached my file. In it, you can grow the inner circles and see that they currently collide with each other and push each other away, which is not what I want. Ideally, the inner circles should be allowed to overlap, and only push the outer circles away.

Does anyone know how to set this up correctly or work around the limitations of the Collide component?

Thanks in advance for your help!

Overlapping inner circles test.gh (203.8 KB)

1 Like

Good question, I would also like to know the answer

1 Like

Have you tried the CurveCollide component instead? It has two inputs, Curves for the stuff that collides and gets moved, and PassiveCurves for the stuff that collides but stays still. This little proof of concept works:

Before:

After:

Pushing Circles.3dm (42.2 KB)

1 Like

I do not have the “Round to factor” component from a plugin…
Anyway, for 900 objects you request translate into 202050 exceptions or “ignore pair” for the collider goal… overkill, not worth it, and the huge list is making the whole kangaroo simulation so slow that is barely useable…



Overlapping inner circles test.gh (204.5 KB)

4 Likes

Hi @Tom_Newsom,

Thanks for the suggestion!

Unfortunately, I don’t think that approach will quite work for my case. I need the inner circles to behave in two specific ways:

  • They should remain passive in relation to other inner circles.
  • At the same time, they need to be active toward outer circles.

I’m also working with lines rather than closed curves, since I need the circles to be flexible and adapt dynamically. If I’m not mistaken, the CurveCollide component only works with closed curves, which might be a limitation here.

Appreciate your input though—happy to hear any other ideas you might have!

Hey @maje90,

Thanks for your reply!
I stumbled upon the same problem by using ignoreA and ignoreB.

Do you know another way to do this?

@DanielPiker do you have any idea?

Thanks a lot in advance!!

To have 2 sets of spheres, where they collide with members of the opposite set but not the same one, I don’t think there’s an efficient way to do it without a bit of custom goal scripting.
This example is similar, though would need some adapting:

Seeing your file and the images in this thread, I’m not convinced this is actually what you need though, it may be that something curve based is much better, but it’s impossible to say without a bit more context. What is it you actually want to do?

1 Like

Thanks for your reply!

What I’m ultimately trying to create is a simulation where inner curves can overlap with each other in the center area when the system is scaled up or “blown up” — like in the examples below:

Like this:


So let’s say I begin with the initial overlaps as in the script I shared. When the system is scaled up, I want the result to look like the images.

I’ve just realized this isn’t possible with my original setup, since the inner curves still collide with the other outer curves in the middle, which stops them from overlapping properly in the middle.

To fix this, I’m actually fine with some overlap already being present in the initial/starting state (see the test below):
Overlapping inner circles test (v2).gh (207.8 KB)

In this example, the solution @maje90 offered works well at first — but once I scale the system, the simulation becomes nearly unusable. Also, if I pull the outer circles away from the center in the beginning (which is the case in my scaled up version), the initial overlap disappears, which brings me back to the original layout of my first script.

Thanks again for the insights!

You re-explained your kangaroo rules by text… personally I still have no idea what are you trying to do.
If you can describe the real-life final output of what this “thing” is, would greatly help everything here…
Objects that are free to intersect but also collide in some other ways… are totally abstract here.

What is this thing?