Getting a shape to be automatically positioned to be inside the donut

Yes exactly, z position should be preserved on both and donut should move to the part.

Therefore using the volume cmp to define the centroid on both of them and then connecting then using their centroid they get out of alignment which is wrong

as long as the center of the reach area (donut) is on the final calculated surface (green) the donut will contain the 3D printed part:

you can chose how many sections to calculate with this slider:

this calculates 30 sections, and compute minkowsky for each of them

we need to be able to contain the Part for each section, so we need to strict the area along X,Y:
this nice piece of garbage here does a sort of “mass intersection” of all the computed minkowski areas, in such a way you end up with the smallest common to all: clean final result

clean result: as long as the center of the donut falls in the green surface, the Part is contained

the definition uses Clipper2 (package manager) and Anemone (if mass intersection exists, Anemone can be avoided)

minkowskiable.gh (309.1 KB)
[edit: data was not internalized because of gin tonics]

1 Like

Ok.

I tweaked the initial approach, but it’s not super elegant and probably not what you want still - could be improved.

  • donuts move to the parts keeping their height
  • parts also keep their height
  • the collisions take effect

Note:
Now, because I’m still moving centroid to centroid (but this time keeping the heights), the parts that are more compact (as opposed to the C-shaped ones) don’t respond to the collision ‘automatically’, or not how I wanted ( :rofl: ), so I added a ‘grab’ component to drag them and force them to be positioned inside (restraining their Z translation) - once you do this and compare the volumes of initial and resulting shapes, they match:


collideinside_multiple.gh (500.3 KB)

I’m sure you can choose a different way to move the donuts to the parts, but I was lazy and just went centroid to centroid :slight_smile:

I use rigid points because it’s slightly faster than rigid body collisions, but those work as well. Feel free to play with it, nonetheless I’d follow @inno’s lead, he’s the expert!

:sweat_smile:

Still the parts move and thats not what im looking for :sweat_smile:, id rarher grab the :doughnut:.

1 Like


I don’t seem to have this component

type Packagemanager in Rhino, then type Clipper2 in the search box, then install

btw, here is the modded GH file that can handle all your example shapes
the resulting surfaces are where the center of the Donut-robot can exist in order for the donut to entirely contain the given part

you will notice that for some shapes you have more than one area of course


minkowskiable_Re.gh (308.5 KB)

which also means that if you place the robot on intersecting resulting surfaces, you can print both shapes with one single placement :+1:

two birds with one robot

always follow drunk people :+1:

1 Like

Doesnt seem to work for me

Adding new part even a smaller one just completely breaks it and the part goes outside the donut in the midle which is where the robot is.

can you please post your file that contains that particular part?
because I have tested it with like 60 different random parts and worked for all of them :rofl: it would be interesting to see what is not working and why

from the previews of your images, you are looking at the wrong things :slight_smile:

turn ALL previews off for the file -as it was saved- the only thing of interest should be this surface, which is the area inside which you can place (XY) the center of your donut

any point on that area is good

UPDATE: Refined in various ways.

  • Expects Rhino file with hidden ‘donut’ and ‘parts’ layers.
  • Customized ‘Tree/List Viewer’ tool shows the chosen solution in yellow.



donut_collision_2024Feb7a.gh (50.6 KB)
placeholder parts.3dm (632.9 KB)

2 Likes

:joy: :joy::joy: Oops - that’s true, total lapsus. I have a donut for a brain.

this works for single parts, as well as multiple parts:

minkowskiable_multiple_parts.gh (339.6 KB)

3 Likes

How did you get a three minute video in 12.3 MB? I have OBS Studio for screen capture and Pinnacle Studio 26 for video editing but a 23 second video is 12.5 MB :exclamation: :question:

Must be my output format in Pinnacle Studio?

I tried looking at your GH file, installed Clipper 2 (had the old Clipper) but don’t understand it.

I used this random googled mp4 compressor on the fly :slight_smile: this one: MP4 Compressor - Reduce Video File Size - VEED.IO after uploading a video, there’s a tiny button with advanced settings that allows for changing the bitrate with a slider, and gives you the forecasted final video size when you move the slider itself, very handy, so you can play with that in order to stay under 20 MB

you can consider the minkowski sum of 2 shapes A and B as the region union of any possible position of B that slides over A: no rotation allowed, only translation

this way, the final weird shape that you get is something like the sum of the superpositions of B around A
which also means it identifies all the positions in a plane where you can place B and “reach” into A

(here the hatched area is the minkowsky sum of B around A)

A is the part to be printed, B is where we place the donut

we slide the donut around the part, in such a way to find each possible position where the donut center can be placed in order to be able to still reach A

that operation is repeated over several planar and XY parallel sections of both the donuts and the part to be printed, in such a way we have a serie of different superpositions B can exist, in order to still be able to reach A

when you section the donut, you get a big circle and a smaller one: I first compute the big mink-sum of the big circle, then remove the min-sum of the small circle around the very same shape, for each section-plane

because we need to be sure we can print all the Part (top, bottom and all the intermediate sections), at the very end of the definition the various superpositions at different heights are “mass intersected” using the Anemone thing, which just reduces the possible “placement area” more and more… what remains at the end is the common projected area to all the superpositions at each Z height, which means an area inside of which you can place the projection of the center of the donut (Z is untouched) and will allow the computed parts to be contained: wherever you put the center of the donut, if it falls inside the calculated surface (if that surface exists) then it will contain the Part/s

1 Like

Thanks, will check it out (and your GH file) after a trip to the coffee shop and watching the ocean waves at the jetty. This is a 720p version that is ~7.4 MB:

[…removed…]

A little fuzzy. :frowning:

WOW! I tried the veed.io compressor at the “Medium” setting; it reduced a 12.5 MB file to less than 1/16th size and looks great! Amazing :exclamation: Thank you.

I’ve tried but still fail to understand your Minkowski work. Really incredible that Hermann Minkowski (1864–1909, age 44) lived so long ago, well before computers, and yet came up with this stuff!

2 Likes

had to wait for 20 hours to reply but I’m back

Thank you all for the great help :slightly_smiling_face:. Basically, all solutions are great but I have to say @inno is the expert of experts so his approach and solution were exactly what I was looking for and far less strenuous for my weak laptop, but I’m also going to use and tweak the other solutions as well @Joseph_Oster and @René_Corella thank you. I’ll notify you guys when I finish the project hopefully I do.

“You’re all ACES :1st_place_medal:to me”

Thank you and take care.

lol man… I’m expert of 2 things: gin tonics and poofing headhunters in the temple .___.

1 Like

Lol…just so happens that my favourite drink is gin tonics too, means im heading towards the right path!

2 Likes