Cull one colliding object, not both

I have a semi-organized / semi-randomized cluster of objects (they happen to be meshes). They roughly follow a guide curve. Since each object will eventually be fabricated, they can't intersect each other.

I'm using the "Collision Many | Many" component to cull those that intersect, but when I use the output of this component with a "Cull Pattern" component, it removes all the objects that intersect each other. I'd like to remove the fewest possible so none intersect anymore.

Any thoughts?

Secondly, I'd like to do the same for any object whose centroid intersects an object above. The objects will be hung, so the hanging wire cannot pass through any other objects.

Replies to This Discussion

Permalink Reply by Riccardo Majewski on January 29, 2015 at 7:27am

You could count each time an index is called, and dispatch objects by number of collision:

ex: cull objects with more than 2 collision

Maybe this is a way....

Can you attach your files?

Permalink Reply by Damon on January 29, 2015 at 2:46pm

I'll try to attach files shortly (I can't use my originals for confidentiality reasons).

Culling objects with more than 2 collisions won't get rid of all the collisions, only a select few. Many only have one collision... I just want to get rid of one of the offenders. Right now, if two objects collide, I cull them both. I only need to cull one or the other.

Does that make sense? (I'll try to upload a "generic" version of my problem shortly.)

Permalink Reply by nikos tzar on January 30, 2015 at 5:24am

Hi Damon,

This is my attempt, using anemone plugin (I can't imagine a way to achieve this without a loop plugin...):

This definitions removes the geometry with the most collisions first, so that it culls the minimum possible number of objects (hopefully..)

You can check if it works with your geometry and let me know.

Attachments:

cull-one-colliding-object.gh, 32 KB

Permalink Reply by Riccardo Majewski on January 30, 2015 at 7:45am

Cool and short method Nikos!

But removing first the object with most collision is not always the best solution:

(removing the circle with 5 collision is not good, if we want to save the highest number of objects)

Anyway this is an interesting challenge ...

Maybe a graphical feedback is not necessary to solve the problem here.

Once you have an index for every pair of object in every collision it should be possible to build an algorithm that works completely in booleans/maths...

We don't care how much the object collide, but just if yes or not, boolean..

I think an iterative method is not necessary.... just... really hard math XP

Where the grade of the equation is the number of objects, or something else crazy like this....

maybe I'm just saying random things...

/backtotheden

Permalink Reply by nikos tzar on January 30, 2015 at 8:21am

Riccardo, I am afraid you are right,

I didn't give this much thought, it just seemed reasonable at first.

I can't get into the dark/mathematical side of this since I have forgotten most of what I once knew...

What I am thinking now is a possible Galapagos approach:

something like: isolate intersecting objects and start culling randomly until you have none intersecting. Then evaluate the solutions by number of objects left...

Permalink Reply by Riccardo Majewski on January 30, 2015 at 8:49am

I can't do math too... I just suppose....

(And i do that too often! Everytime and everywhere... maybe here, maybe there.. lol )

I agree with you with the Galapagos part.

With random attempts a good enough solution could come out fast.

I just think its better to work with the indexes generated by Collision component, instead having to run the collision component at every iteration of Galapagos.

I don't know how, but it should be faster....

Permalink Reply by Riccardo Majewski on January 30, 2015 at 9:22am

mmm ... what about this? a rule....

Example:

colliding 26 objects, the letters of the alphabet...

IF "T" collide ONLY with "G" there's NO reason to not delete "G"

-IF "G" collide with other many letters > delete "G"

-IF "G" collide again ONLY with "T", just delete "G" anyway!

just ONE of the 2 must be deleted!

they are colliding!

(so much emphasis!)

so....

instead starting from the top, finding most colliding objects, we could start from the botton... with least colliding ones....

(we could iterate this? mmmm....)

at least this "starting rule" is 100% safe... (it is?)

this is what i were thinking... rules... XD

it works in 2d/3d/4d etc... no graphical feedback required...

need to find more rules!

Permalink Reply by nikos tzar on January 30, 2015 at 10:11am

Yes, clearing out the easy ones (objects colliding just with each other) first could help. but then what?... I am looking at your image over & over, trying to extract a rule but I just can't!

I gave it a try with Galapagos with no luck:

In the above case there is certainly a solution with 20 objects (bottom left corner I created your shape) but galapagos can't find it even with 1 million possible seed values on the [random reduce] component :(

I guess that was to be expected since there is no kind of continuity on the results when using random seed values....

Anyway, in hope of someone providing a better solution, I give up for now!

ps. here is my file with both definitions in case you want to take a look at it:

Attachments:

cull-one-colliding-object-2.gh, 227 KB

Permalink Reply by Riccardo Majewski on January 30, 2015 at 11:34am

It's hard to separate logic from graphics;

I'm sure that, once collisions are calculated, the problem can be solved perfectly by a "blind" program....

Ok, let's expand the first rule.

A "group": a subset of objects where EVERY object collide to all the others.

We can say that in every "group" only one object can "survive" , an the others must be deleted!

Groups "communicate" between each other, so, we can say:

"In every "group" the only object that survive, is the one with less collison count"

(This rule was already present in my first rule, but...it where hidden!)

Starting from smallest groups and then step by step to biggest.

Iterative then :P

This is some sort of "game of life" again, but with indexes and number of collisions....

Permalink Reply by Damon on February 6, 2015 at 2:49pm

Guys, this is an awesome discussion. I'm still following (or at least trying to). This would have very a practical application for me.

Lately I've been thinking about it a different way: instead of creating a distribution, then removing overlaps, could I create a distribution that has no overlaps? That is, could I place the objects in a way so that each placement is aware of the other objects around it? I never started with this option because it seemed to immediately require looping. I try to avoid those solutions if possible.

If you have any further thoughts, I welcome them. This is still an open and ongoing problem for me.

Permalink Reply by nikos tzar on February 7, 2015 at 2:54pm

Hello Damon,

since you never uploaded any files we had to keep this discussion strictly to the point (remove minimum number of objects in order to have no collisions). We have no clue as to where those objects are coming from, just that some of them are colliding. If you are ok with uploading a file we can maybe think of ways to avoid collisions in the first place (using a loop plugin, as you suggested, or even using something like kangaroo's springs or box collide or...)

RSS