C# Delaunay solver syntax

Well friends,

I need some help ASAP :

this def creates a random collection of masts,cables et all ... then approximates a "membrane" with the simplest possible way (StarlingStar is the best) and then Kangaroo does the rest. A variety of mesh creations "methods" is provided

But the first 3 options are suitable for a no holes (cones) membrane: for adding cones I need to triangulate a user controlled amount of high (Z) points: i.e. get the n highest mast points and create closed polylines ... then define centers ... then define circles .. then patch circles and boundary ... then re-trim the patch result (it fails to trim inner loops) ... blah blah. All these are rather trivial except the cryptic (no documentation of any kind available) syntax for the Delaunay solver (for instance : what type of List is required?) :

I would greatly appreciate any help

best, Peter

Attachments:

Tens_from_random_polyline_v3.gh, 423 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on October 1, 2014 at 4:59am

PS: Plan B > where in that @%^%@ SDK is this Circle Fit thing?

because and since high points are few : (a) create the circle fit (b) sort pts along circle (c) do the triangulation within a simple while clause (and some ifs).

Permalink Reply by David Rutten on October 1, 2014 at 7:24am

We have sphere fit and plane fit. Do both, then intersect the sphere and the plane.

Permalink Reply by peter fotiadis on October 1, 2014 at 11:31am

Thanks, it worked (obviously my triangulation is "a bit" inferior to Delaunay's - but since the latter is still cryptic to me > stick to Plan B > not "perfect" placement of cones > nobody can tell the difference > why bother?).

I'll post here the finished definition (severely modified) soon.

Permalink Reply by peter fotiadis on October 4, 2014 at 12:29am

OK, I need help (for the last time):

Spend 2 hours more on that: it's "almost ready" except that !@$@% "cut holes" in the brep thing.

In plain English:

Patch (actually 2: see lines 251-278) is required when membrane cones are invited to the party (then mesh (via Starling is the best way) the brep and send data to Kangaroo : the easiest thing to do). But patch doesn't trim the inner Loops and ... well initially I thought to find this in SDK and do the job:

Well... I confess that I can't get the gist of the Brep.Trim (as explained in SDK).

Thus go to plan B: having already the closed breps (the "cones") as cutters ... attempt a Boolean difference

but this does that (this looks to me a bit paranoid, but some reason must exist):

What I want is this:

the code that mess things is (open the script inside definition attached):

BTW: where in SDK is that DeBrep thing?

BTW: Delaunay GH syntax is still cryptic to me (but this is not an issue anymore)

I would greatly appreciate any help on that final step (to greatness).

The full working definition soon (v5: with 90% of components replaced by C# stuff).

best, Peter

Attachments:

Tens_from_random_polyline_v4.gh, 453 KB

Permalink Reply by djordje on October 4, 2014 at 3:00am

Hi Peter,

Check the attached files for examples of Trim Solid and Deconstruct Brep (DeBrep). You are familiar with python, as far as I remember so it wouldn't be a problem.

Attachments:

deconstructBrep_trimSolid.gh, 7 KB
deconstructBrep_trimSolid.3dm, 130 KB

Permalink Reply by peter fotiadis on October 4, 2014 at 3:15am

Thanks my friend I'll give it a try

But in the mean time issue is resolved (blame shortage of cigars + double espresso(s)).

Future things to do : create a collection of demo C# things that explain all things (boolean, trim, split, cats, dogs, espressos, cigars you name it).

That said why the boolean difference did that weird thing it's beyond me.

The finished definition (only 100 lines of code more: a vast variety of checks if this could happen after that etc etc).

BTW: since you like mechanical things, I'll post here something that may you find interesting: MCAD CATIA stuff far and away from Rhino matters: how to design a real-life membrane ring (for classic and/or inverted cones).

Permalink Reply by djordje on October 4, 2014 at 4:03am

That said why the boolean difference did that weird thing it's beyond me.

It's not weird it's how boolean operations work. They are not really made for punching holes into surfaces.

You used a solid as a splitter, to split a surface. Boolean operations usually require the opposite order: using a surface as a splitter to cut a solid. Either that or having two(or more) solids. Check this article for further explanation.

Catia screenshots, sound nice.

Permalink Reply by peter fotiadis on October 4, 2014 at 4:23am

It's the espresso thing I guess.

BTW: where in SDK is the Trim Solid (Trim) thing? (see captured image above) : this trims a brepface with solids (closed Breps).

BTW: no screenshots: a translated Rhino file with all the nuts and bolts (but a 100K assembly in CATIA becomes a 10Mb++ thing in Rhino, thus some "simplification" is required).

Permalink Reply by Anders Holden Deleuran on October 4, 2014 at 4:37am

You can look it all up in the online RhinoCommon SDK documentation, maybe Brep.Trim is what you're looking for.

Permalink Reply by djordje on October 4, 2014 at 4:51am

Have you checked the first python component? Brep.Split method replicates the Grasshopper's Trim Solid (Trim) component. That's what you were asking for above.

Permalink Reply by peter fotiadis on October 4, 2014 at 6:51am

Well...since the "make hole(s)" issue is addressed earlier in the morning (after the double(*3) espressos) - see screenshot attached in my previous reply (split loop), I was busy fixing "some" faulty logic in the script body. Now it works OK. Feeding all the right data required to Kangaroo is entirely trivial.

Happens now : create some "filters" about if a given cone is a classic one (suspended from a triad of high points == make triads of cables etc etc) or an inverted one (pulled from the ground == do something about that, anyway). This means find some interactive way to alter the cones data tree on a per branch basis (a slider access branches > the offset is altered > cone "type" > ...).

Just checked the P thing : it's all clear now (DeBrep).

That said I work in a smoke build on some MCAD app that does the following : when you hoover over a tool ... the underlying method is exposed and ... you can find what is where in nanoseconds.

Anders: I've looked at the Brep.Trim before posting this ... but .. well I can't get the gist of it (anyway the split loop did the job).

... If the Cutter is closed, then a connected component of the Brep that does not intersect the cutter is kept if and only if it is contained in the inside of cutter....

Permalink Reply by peter fotiadis on October 4, 2014 at 7:05am

BTW:

Moral: when we are looking for some blonde (Saturday Night Fever + disco time etc etc) we actually mean a brunette.