Re-scaling imported random sized spheres to benchmark diameters

Hi all, I need your help with the following please!

I have a mesh model with approx 1500 spheres of varying, inaccurate size, in 3D space.

Firstly I had to align the spheres to a set of perpendicular lines, as the spheres will be hung from cables in reality.

Now I have to standardize the size of these mesh spheres, to 30,50,75,100mm dia, whichever value is the closest for each sphere. I also need to output these spheres in separate layers for quants and and labeling for doc and fabrication.

Definition below, I am stuck, any help much appreciated.

best

Gio

Attachments:

170315_Spheres.3dm, 1.2 MB
170315_Spheres.gh, 39 KB

Replies to This Discussion

Permalink Reply by Giovanni Veronesi on March 16, 2017 at 12:57am

I managed to achieve what I need, but I have a feeling it's not the proper way. Any suggestions on how to improve the definition please?

best

Attachments:

170316_Spheres Standardizer.gh, 40 KB

Permalink Reply by Joseph Oster on March 16, 2017 at 3:57am

Your 'Crv' and 'Mesh' params are not connected to the Rhino file? I see only 141 spheres, not 1500? I ignored your method of determining mesh sphere radius based on distance from volume center to 'MeshCP'.

Attachments:

170316_SpheresStandardizer_2017Mar16a.gh, 23 KB

Permalink Reply by Hyungsoo Kim on March 16, 2017 at 2:29am

Hi.

Take a look at the attachment. You do not even have to calculate the radius of the spheres.

You can use "Volume" values directly. Best.

Attachments:

170316_SpheresStandardizer_re.gh, 963 KB

Permalink Reply by Hyungsoo Kim on March 16, 2017 at 4:54am

Forgot to sort per hanger wires...

Attachments:

170316_SpheresStandardizer_reV2.gh, 931 KB

Permalink Reply by Joseph Oster on March 16, 2017 at 3:44pm

I "borrowed" your code to "sort per hanger wires", white group, and applied it to my algorithm, then sorted the spheres on each wire by 'Z'. Note that I included 'Volume' as the 'B' input to 'Sort' so I can apply your color gradient code (not shown but in GH file, off screen) after the Z sort:
170316_SpheresStandardizer_2017Mar16b.gh

The fact that sphere 'Volume' is required a second time, after 'Pull' to wires, reminds me of a similar issue we dealt with last week:
http://www.grasshopper3d.com/forum/topics/trimming-points-pulled-fr...

Seems to me that 'Pull Point' has a serious defect that requires extraordinary effort and/or kludgy code to remedy. If you don't graft the curves, 'Pull' returns each point pulled to it's nearest curve - exactly what you want, except without knowing which curve puled it?

In this code (above), you are using 'Pull D (Distance)', 'Smaller' with an arbitrary value as 'B' and 'Cull' to associate the closest curve with each point. In the other thread, I ended up creating brep cylinders around the curves to get the correct result. Ridiculous!!

I've spent a lot of time trying and utterly failing to find a truly proper solution. Is there one? (see "AHA!!!!" below!)

Searching the forum, I quickly found a couple old posts referring to the same problem:

pull point (bug?) May 27, 2009
http://www.grasshopper3d.com/forum/topics/pull-point-bug

Small request April 18, 2013
http://www.grasshopper3d.com/forum/topics/small-request

=========================

AHA!!!! I had given up and was about to post the above when I finally solved it. Created a cluster called 'PullT' that does the job, sorting by 'D (Distance)'. Here's the cluster:

And here's how it's used: 170316_SpheresStandardizer_2017Mar16c.gh

Notice that 'PullT' emits a cull pattern ('Pc') that can be used on related data to structure it into the same tree pattern - 'Volume (V)' in this case, so it's only used once. Could do the same with the original mesh spheres if there was reason to do so.