Grouping colliding objects

does this mean that if they’re on top of each other you want to consider them colliding? …because they aren’t (when you use collision many/many) but if you use one/many they do collide but it’s wrong

by the way, this should have been your original post :stuck_out_tongue:

No worries. I have just found a way.

Group Colliding Objects.gh (9.0 KB)

Still it is a shitty and clumsy way though. I’d rather do it with the collide component from start to finish.

Hi David this method group curves by collision.

Based on both approaches, this works with curves insides curves and with vertical and horizontal lines but the problem is collision curves with breps…

Group Colliding Objects_ev.gh (45.6 KB)

1 Like

My “solution” doesn’t have this issue. Yet it would be nice if there is a more clever way…

maybe this one


collidingtrick.gh (245.8 KB)

didn’t group in colors (maybe you do that :slight_smile: ) - added some other test geometries

Well … the numero uno thingy in Ccx hard clustering is the type of object:

You can get results relatively fast (case: objects as meshes) or slower than any stationary Harley Davidson (case: SAME objects as breps). Spot the hideous Elapsed time required for the latter [imagine going from simple test boxes to complex nurbs objects > see you next week/month/year].

~100 times slower:

Anyway … if you want a 100% code (C#) based solution on that matter, drop a word.

1 Like

@PeterFotiadis thanks for the brief (and always crude) insight! While attempting to help the OP I did come across your ‘closest two pairs’ code from an old thread, thinking it’d be of use for finding the closest 2 points between objects that weren’t but looked like ‘colliding’ (case: one box on top of the other sharing a corner). Kept it with gh components only with a far-from-elegant solution :grin:

Anyway do share (if you want) your 100% C# solution, I am sure @davidsmavrov among others (myself included) will find it quite didactic (as the ’closest pairs’ was for me).

crude? why? when? where? And what do you mean by “if I want”? (otherwise why offering to post the thing?).

Anyway get the def (some sensitive Clustering rules are removed, but the proximity and intersections are available). Given the opportunity see the Methods used for Proximity (mini Loops on closest pairs on Breps and/or Meshes).

Clusters_CCX_On_MeshesOrBreps_V1.gh (130.0 KB)

How to play:

  1. The first C# does the cheating part (because it provides very simple objects in order to help the 2nd to achieve some decent Elapsed times [case meshes]).

  2. The second C# does the clustering … but you can input your stuff as well (be the Force with you - the dark option). Before doing it have a brief idea with regard the Elapsed times. In general and if you have nurbs type of breps and they are quite a few I would strongly advise to convert them first to meshes and then walk the walk.

haha my apology ‘crude’ as in succinct :wink:

and thanks! playing now

image

Other than that … well… the Proximity rule (in a K-Means way) is NOT working with some rational way for the demo things made by the first C#. In fact … is not rational for any “normal” collection to be honest (even The Thing pictured finds it paranoid). The rule is written for some specific truss cases and … well … stay on the Intersection rule for the moment.

One thing I find very true. It becomes a lot faster if you mesh any breps you work with. Otherwise is indeed a bloody nightmare. If they are a few… it is ok. But if they are many…

My simple trick will work for a reasonable amount of geometry. But indeed if you want to do something with a lot of data it is not a good idea.

Well … there’s an approximation on that matter:

Do a K-Means clustering (using the BoundingBox Centers OR the average obj-to-obj prox distance [ with the Methods used in V1]). Or “pre-process” the ccx event query per pair using BoundingBoxes (their collision MAY or MAY NOT yield an obj-to-obj collision). Obviously some // stuff (provited that there’s cores around) is a must.

For 1K objects … a non // K-Means against the Centers does the clustering in approx 10ms. On the other hand computing the prox distances (~1M Method calls meaning at least 6-8M calculations) requires 500++ ms (or waaaaay more if the objects are nurbs breps).

For the record I’ll replace that Proximity rule with a classic Centers K-Means rule in the next trad update.

BTW: Trying to cheat a “bit” (non // Centers K-Means) : time grows (Tests using an entry level I7 mobo) almost 7 times … kinda a Windows update (big fanfare, no reason to do it).

Good news: obviously for K-Means using Meshes or Breps is more or less the same (if we forget the BoundingBox part of the story).

2 Likes

Hi David.

I downloaded your ghfile. And I got a question.

why do you use “scale” ?
I don’t understand the meaning of this, because factor input number is nothing. pls tell me. thank you.
image

1 Like

The factor input is not nothing. It is very tinny bit larger. I think 1.01. It is a tollerance thing. It is not perfect, but it works :smiley:

1 Like