Last month we had a really inconvenient mistake with many machine parts because we missed adding some holes for metal pins, it caused a lot of rework, extra work time, and extra cost. I’d love to see this problem going away.
Having a way to visually spot these collisions would be great. Something like this on clipping planes:
BTW, making this video, I realized that in V8 we can now snap, and take dimensions from clipping intersections. Awesome! that was the other missing functionally we had in clipping planes. Thank you!
I posted this over a week ago and no responses. Are we in our team the only ones who see realtime collisions a very valuable feature?
If so, why is this? Most Rhino users do not do this kind of mechanical detailing/prototyping? Are all features based on the Architectural market these days?
I think this will help developers when writing a feature request.
For us, using this manual + Grasshopper dependent + brute-force approach won’t work, It works great for a handful of cubes, but I just tested it here in a real world file, One of my working file from this week, and this is what happens. It’s been over 10 minutes with the spinning blue ‘not responding’ state:
Hi Gustavo, thanks for trying out and the additional info. Of course this brute force approach is not ideal, I totally understand. How many objects were you feeding it? The practical max of this gh sample is about 100-150 objects I’d say. The amount of calculated clashes will grow exponentially.
Even on 200 objects that don’t intersect the clash calculation alone will take up 1.4 minutes here, as it is performed about 80k times. I’m pretty sure this can be done smarter. multi-clash2.gh (16.1 KB)
Best would be if you can share a file, or at least give me an idea about the amount of objects of each type and complexity in a typical scene you want to examine.
Do you use other software that enables you to do these checks? I can check in SW, but that’s only on a component level in assemblies.
In this case, I was feeding it 68 closed solid polysurfaces. This is a typical mid-development assembly we need to prototype as 3D printing and/or machining. And this does not include all internal components that we needs to design housing around. Ideally we want to also check interference and collision with those too.
I just tried it again with this version multi-clash2.gh and even with all hardware turned off (no screws with threads, no hea-press inserts with a lot of knurling details visible), all internal compnonets also turned off( not ideal since we do wat to check colisions with these sometimes) and only 34 closed solid polyfurfaces, this completely melts too. I let it run for 30 minutes and I ended up force-quitting. When you say it can handle 100-150 objects, are you talking about simple primitives?
We work on industrial design so our Rhino models are no more, but no less complex than your typical computer/houshold/industrial product you have laying around in your home/office/workshop.
I was able to do it in Siemens NX, but in our little company we don’t use that anymore ($$$!)
We need to see clearly:
when parts have a tolerance/gap for fitting weel (partculartly for 3D printed parts, or parts that will later have paint added on)
when parts are line-to-line for pressure fit components
when parts collide slightly for heat-presuure fit of inserts into plastic parts, or for screws to create threads into plastic parts, or parts that will be tapped/threaded later.
I’m sharing privately a video + working file with you guys so you can see what challenges we face on a regular basis.
I almost never use clipping planes to find collision but just wanted to chip in with my experiences with overlapping parts being missed in projects. Feel free to turn this into a new topic if this is getting too offtopic from Gistavo’s original request.
I mainly deal with cnc-constructions but often need to check collisions between parts to make sure things can be assembled. Here’s an example I recently worked on:
But it’s very tedious to select and go over every slot to make sure I didn’t miss anything. So my workaround has been to use the hidden command TestRandColor to give each object a different color and visually inspect overlapping parts as this creates a flickering effect on overlapping parts while orbiting, which makes it easier to spot
This multi clash grasshopper definition from @Gijs seems to work, which is great! Maybe a bit slow but seems to give me at least accurate results without having to rely on my own attention while inspecting. This took about 18 seconds for 21 parts on my computer.
It does however do the job which is the important thing, but I’d love to have this as a rhino command. Is everything available in RhinoCommon for me to make this into a command myself? @Gijs
@siemen I wonder if this version works any better, it should ignore objects that share a coincident face. It will not play well with coincident objects I think: multi-clash3.gh (8.7 KB)
Hi @siemen , just to make sure: in version 3 I added a slider to show (and calculate) only one clash result at a time. If your model allows, you can remove that part.
I went a bit off-topic with this clash stuff, expecting that this could solve @gustojunk 's issue, but since it doesn’t really, the original request remains of course to be able to see intersections better in clipped views. RH-72030
@siemen What I did is enable only mesh difference for one item at a time. If you want to always see all results, plug in the clean trees directly into an and b of the mesh difference.
