boolean ball collisions

Replies to This Discussion

Permalink Reply by Pieter Segeren on October 19, 2015 at 5:38pm

Sounds like voi* to me...

Attachments:

• BBCVoi_PSG.gh, 47 KB

Permalink Reply by kipodi on October 20, 2015 at 7:46am

thank you. unfortunately I'm trying something more complex where the balls don't lay on the same plane and a projection won't work.. all booleans fail , perhapsthe model is too big

Permalink Reply by Joseph Oster on October 20, 2015 at 8:22am

This is a really beautiful solution!  I did wonder, though, about the assumption that the spheres are cut by a plane - which apparently does limit its application.

The 'Deconstruct Arc (DArc)' is one of those non-intuitive leaps in GH that one just has to learn.  Turns out that you can get the same result by connecting these cut spheres to various geometry 'Params' and using 'Area | Centroid' to get the points:

Thanks Pieter.

P.S.  'Cull Duplicates (CullPt)' doesn't seem to be necessary?

Permalink Reply by Nik Willmore on October 20, 2015 at 6:33pm

No, you are very much wrong. Technically, it should and will fail since Booleans in Rhino/Grasshopper are not done in "human thought space" but in very pedantic "computer math space" where the program merely automates finding clear intersections between pairs of objects and then splits the objects along those intersection *curves*, deletes the trims, then joins the remains, and cycles on. But within the confusing Rhino Settings tolerance value, wherever surfaces actually just sort of come closely together, there *is* *no* clear intersection curve. So it bugs out and stops working EVERY time you try more than a dozen or two spheres.

Some software can do this by switching to volumetric pixels (voxels). $9K-$30K Geomagic Freeform is an example of this. It also fails sometimes, often due to memory issues, as you can imagine since it needs to fill all inner space of each sphere definition with 3D pixels.

Materialize Magics for $16K can often handle such Booleans well. It will take a seeming lifetime to figure out such often pirate software kludges though.

One thing you can try though is to simply drape a mesh or NURBS plane onto the top of your spheres.

There's a well known *reason* your Booleans are failing. Nobody here has yet even hinted at it:

The main reason is that Rhino/Grasshopper developers don't care about the human element. The math exists to make this work very fast, every time. It just has to join things *right*, incorporating human knowledge of kissing surfaces, instead of acting stupidly, like some pocket calculator. But that would involve hacks that make 99% of complex Booleans work instead of 10%, and we can't have that since it will be SLOWER for the other 1% that just happen to have no nearly kissing or really kissing surfaces.

You could also use the new Cocoon plugin to do a surface *around* your structures, with a given radius of extension beyond the spheres, then offset that surface back the same radius. That is 100% robust, but won't offer quite as sharp of intersections, more rounded, like most everybody wants anyway.

You can *test* Boolean failures, by running a Grasshopper intersection command, to see the intersection curves, and zoom in to see how badly many of them are, all knotted, or twisted, or even with gaps, often with gaps.

It's a math problem nobody at McNeel wants to solve, sorry.

Just write a check for $25K and spend six months taking notes, like I did, and you can merge your simple spheres finally.

Permalink Reply by kipodi on October 21, 2015 at 4:13am

thank you for your answer. I am not too aware of the boolean logic but indeed I had a feeling that it wasn't too "smart" and does it in an itterative way for each element. 

I think there should be some logical formula if all spheres shame the same radius.. 

because you don't really have to calculate a differrent mass for each one and its a "uniform geometry . maybe there is some relationship between the center of two sphereand andtheir intersaction curve ( which is always a perfect arch in any case.. just the location and length vary.

I didn't get your last remark about the 25k. Who shall one send the check to? :)

p.s: what do you think the best software for this would be out of what you mentioned?

Permalink Reply by peter fotiadis on October 21, 2015 at 5:10am

Er... I think that there's a certain confusion about what a surface modeller (Rhino) actually is and what a solid modeler is.

Shown 145 solid balls - not surfaces (tested up to 1000) united almost in real-time (for the 145, that is ... 1000 require around 3 seconds) in Microstation/Generative Components (using the best solid engine known to man: the very same that the notorious Siemens NX has [better than CATIA's]).

PS: send me ... the balls and I'll unite them for you either with Microstation or CATIA or NX.

Permalink Reply by peter fotiadis on October 21, 2015 at 5:24am

PS: this is a scientific project (as usual) : I'm trying to analyze Daffy Duck DNA and make some clones (1021,23 molecules shown are composing the thing).

Permalink Reply by kipodi on October 21, 2015 at 7:05am

Thank you that's very informative and good news. So if I want to the trim this newly creates solid ( ball bunch) with a surface, then its a task for surface modeling? I'm sorry I wasn't aware of the difference. I am actually trying to archive an optimization bro cess with it in grasshopper but I guess the iterations are impossible as I have to import he solid each time.. Or maybe there is a solid modeler plugin for rhino ( sorry if my questions are not so oriffesional in this)

Permalink Reply by peter fotiadis on October 21, 2015 at 9:17am

No .. no ... (solid plug-in in a surface modeller ???) you got it wrongly: make a search (Google solid/surface modelling blah, blah).

Besides there's no secret that Rhino is relatively slow (to VERY slow) with regard "solid" ops whist is fast when surfaces are involved.

Anyway you can experience all these claims of mine first hand: just go there and download Microstation for a trial-test:

http://pages.info.bentley.com/ProductDownload/?CEID=CEE_WEBTAG_APRIL11

Out of curiosity: post here your def (PRIOR any "solid" operation) and I'll translate it in Generative Components (equivalent of GH for Microstation) just to test the case from a different perspective.

Permalink Reply by kipodi on October 21, 2015 at 10:07am

OK Ill do that asp. So you're saying there is no way to "import" the logic of a solid mod elder just for the boolean operation? I want to test the outcome with Galapagos for optimization so its needs to be created in rhino. I thought when you model with solids and not meshes it behaves as a solid in solid programs..

Permalink Reply by peter fotiadis on October 21, 2015 at 10:26am

Well ... any given CAD app is based on some engine. Some are surface modelers some solid.

I'll give you an example: in Rhino when you arrive into some "polysurface" (a collection of "stitched" surfaces that engulf - or not - some topology) ... well this is the end of the path (in most of cases). In solid modelling this is just the beginning.

Google for instance: Siemens NX to experience first hand what I'm talking about - or watch the demos related with the out of this world solid "modification" capabilities AND speed.

Of course this is utterly unfair for Rhino since it's not designed to beat NX or CATIA and in any case it works within a totally different market segment - not to mention a "certain" price gap.

Having worked with pretty much everything out there many years I would say that Rhino is a very good surface modeler at a very reasonable price.

Permalink Reply by kipodi on October 21, 2015 at 4:17am

oh, got the one about the 25 k :). is there no free solution from some math guys at some in a uni lab? :)

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page