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 4, 2014 at 12:13pm

Update:

Here's the corrected V4 version.

v5 (lot's of changes) is currently like Windows Vista (not a System nor is operating).

Note: My extra stupid triangulation "method" sucks.

Attachments:

Tens_from_random_polyline_v4a.gh, 465 KB

Permalink Reply by peter fotiadis on October 5, 2014 at 3:50am

Whilst "mighty" v5 is not working (only 23,56 bugs remaining unresolved), here's version v4b (Kangaroo connected: avoid that thing if you are not 100% familiar with what it does, it's very easy to use it provided that you know how to use it, he he).

Note: prior switching from mesh (via StarlingStar) to brep+holes (via C#) - each one has his own K Engine - stop/kill the Kangaroo animation control mini Dialog otherwise ... you'll have "some" troubles.

djodje:

This thing used (see script in v4b) IS NOT the same as the P thing that you posted (the one that takes 3 arguments where the splitter is a curve).

for David:

Irrelevant with the thread, but a 100% repro case related with the GH inability to internalize data:

This brep is a human figure internalized (but every time when the def is stored and reopened GH reports it as "Null").

So import the man-and-dog.3dm, reference the man (or the doberman), save definition and reopen it.

I'm not sure if Image sampler can store (in file) a thing or two as well:

v5 "soon" (lot's of new stuff and 4.56 divisions by zero) , best, Peter

Attachments:

man-and-dog.3dm, 117 KB
Tens_from_random_polyline_v4b.gh, 620 KB

Permalink Reply by djordje on October 5, 2014 at 5:46am

Peter:

The Brep.Split method you now use in v4b is the same Brep.Split method I used in first python component, at deconstructBrep_trimSolid.gh file.

In python, one could call a method, with the first argument being object itself.So instead of:

brep = Rhino.Geometry.Brep.Split(brep, item, tol)[0]

I could have written:

brep = brep.Split(item, tol)[0]

It's the same thing.

Also the "item" of "splitters" is not a curve, but a brep, check the deconstructBrep_trimSolid.gh file once again.

Cheers.

Permalink Reply by peter fotiadis on October 5, 2014 at 10:18am

Well...I publicly apologize for being more stupid than any intelligent man can tolerate.

And here's the main issue here: the random creation of masts et all within this rectangle boundary masquerades the fact that my triangulation (star like) "method" is out of question.

This means that when "free" form " long shapes" are used for random population ... well there's a big problem for defining these cone suspension "triangles".

Even if I could get the gist of the GH Delaunay syntax ... there's some other approach required here.

Open def and assume that these points shown are the "high points" from where the cones would be suspended - any idea welcome.

Again accept my apologies.

Attachments:

Tens_from_random_polyline_v4b_the triangulation_puzzle.gh, 24 KB

Permalink Reply by djordje on October 5, 2014 at 11:09am

There's no RhinoCommon Delauney method. I am not sure what the Grasshopper solver you found does, but my guess is that Delauney grasshopper component builds a mesh using some custom code David wrote, with usage of available RhinoCommon methods.

This won't help you solving the Delauney issue for your C# component though, but may just give you an insight into some possible features for future projects. Ghpython (version 0.6.0.3>) allows node-in-code feature: calling grasshopper components as functions. Meaning, your Delauney mesh function could be called like so:

import ghpythonlib.components as ghc

delmesh = ghc.DelaunayMesh(pts)

Attachments:

ghc_delaunaymesh.gh, 11 KB

Permalink Reply by peter fotiadis on October 5, 2014 at 11:45am

Hmm I say ... interesting.

In the mean time see this (kill a bazooka in just 123,56 easy steps)

more soon(?)

PS: the usual stuff added:

Attachments:

Tens_from_random_polyline_v4b_the triangulation_puzzle2.gh, 30 KB

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

...Catia screenshots, sound nice...

Well djordie ... a promise is a promise (made with Generative Components instead with Catia):

Import stp files into Rhino: Unfortunately the MCAD type of assembly/component structures (who owns what) used are impossible to be converted into Rhino nested blocks - some STEP214 issue I guess (thus these stp files are a bit useless).

Attachments:

244_UAE_ThematicParkV3-TechPreviewR6_STEP.zip, 1.4 MB
244_UAE_ThematicParkV3-TechPreviewR6-000.pdf, 1.6 MB

Permalink Reply by djordje on October 23, 2014 at 3:01am

Thank you.
Which application do you use for the structural analysis of the modeled connections?

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

Well...these are components for a real-life big composition

This means that the designer (yours truly) needs a "strategic partner" since here we are talking about tensile membrane stuff.

In the world of tensiles ... the Birdair/Taiyo Kogyo combo is like the 3 big German luxury saloon car makers combined (I mean that in 99.99% of cases you'll end up buying a S Class or an ugly 7 series or that 8 quattro).

So ... in a nutshell: It's a ping-pong thing: you design the "outline", Birdair calculates the membrane related forces, you test custom components (MSC Nastran, STAAD, RAM etc), you get feedback from someone capable to do these in real-life (like Donges GmbH), you argue about the cost (hideous, as usual), you replace bespoke custom cast things with commercially available ugly bits ... etc etc etc.

The big issue is that the whole design is supposedly a thing carried over under "some" BIM umbrella ... therefore the master composer must be either Revit (no thanks) or AllPlan (ditto) or AECOSim (yes please).

But these archaic things they don't understand an iota from MCAD stuff (most notably the assembly/component discipline or advanced feature driven nested components). But all things considered Microstation + Generative Components + AECOSim + Bentley structural analysis verticals define the most complete solution that you can use.

Moral: Chaotic chaos, what else?

PS: I'll post the full (quite complex) GH definition soon - among other stuff: using the real-life items shown imported as blocks to Rhino and "mapped" in space (PlaneToPlane) via GH/C#.

Permalink Reply by djordje on October 23, 2014 at 7:21am

So which application will you personally use to do a structural analysis of the upper connection parts?

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

This:

http://www.plm.automation.siemens.com/en_us/products/nx/for-simulat...

Keep in mind that designing stuff that remotely "looks" like AEC (all these could belong to some weird engine, you know, he he) IS NOT like designing plain vanilla AEC things.

Therefore features/calculation methods/capabilities as found in MCAD apps (considered off topic by many in our trade) are mandatory for certain types of designs.

Anyway and if we forget FEA stuff, currently I have 3 C# goals:

(1) master the art of controlling the placement of existed blocks in GH defined topology(done),

(2) master the art of baking blocks(done) and

(3) master the art of baking heavily nested blocks that NX/Catia can understand (progress is slow).