Hexagonal Tessellation on a Trimmed 3D Surface

hello!! I am trying to make a hexagonal tessellation on a trimmed 3D surface, but here is the problem. All hexagons must have the same size. (or almost the same(?))

I tried using Lunchbox, but it doesn't seem to work.

I am using attractors later on to define the radius of circles inside the hexagons, as you can see in the definition, so it would be good to control the size of the hexagons.

Attachments:

hex.3dm, 709 KB
hex-circles.gh, 68 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on January 28, 2016 at 12:28am

Several things were wrong on that modified C# of yours .. most notably:

(a) declaring variables INSIDE a loop and then attempting to access them elsewhere in the X method. (for instance you should do: public Point3d? PT; public double phi; public double k;)

(b) treating items and Lists with a certain "freedom" [ pt/pt1 is a nullable List OR an item? > answers to The Troll, District 9, North Pole]).

Nodes in real-life are all the same ... thus the solution is to vary the topology and not the node's R (or ... if possible the strut R). And the classic way to do that "automatically" is via recursion (where a method calls itself until some termination condition occurs).

Good news: Your progress is rather astonishing I must say.

Bad news: Since the clash detector C# IS NOT the ideal start-up thingy for a novice (even for a intermediate) ... I would suggest to attempt to write down an oversimplified code that TESTS your idea using a node (+ related connections) in isolation.

Permalink Reply by peter fotiadis on January 28, 2016 at 1:03am

Take for instance node 8 where the C# reports a clash issue on the 89-8-9 angle: what to modify? If you vary the strutR ... then yes the tan calculated could (maybe) pass the check ... but with a comedy truss on hand (that MAY fail in the structural analysis). If you vary the strutStart (a bit ridiculous: using a longer sleeve ??? ) ... same I'm afraid. If you start moving the node 8 around that could yield a truss with a hiccup on that particular location.

The solution is to vary the whole topology in an "uniform" way: the donor surface that is (U/V divisions included) until the C# stops moaning. The other solution is to forget surfaces and create a chaotic "graph" (as a truss) where ... "uniform" has no meaning ... thus you can modify any node and nobody could spot the difference.

NOTE: the clash detector is written that way ... in order to handle ANY graph imaginable (singularities included: connections that on the one side are hanging in thin air). And a "graph" is a "super set" of any truss ... well ... in some way, he he.

Appears easy ... but it's not. Funny thing: how things are instantly complicated when real-life is involved, he he.

Permalink Reply by dimitris skom on January 28, 2016 at 1:34am

a. well I didn't know that hehe

b. it should be one item but I don't know where I missed something :/

I thought of it too, what would it look like if the definition worked would it look like a hiccup or more uniform? it would look like a hiccup if the difference in the angles was bigger. because of the loops I am using it would probably stop at the same point for most of the points (theoritically). so I thoght to just see what happens after I make it work.

what if using the same surface, we took some points closer to the center and then rebuild the surface?

how would we make a chaotic graph? wouldn't it need the surface?

Permalink Reply by peter fotiadis on January 28, 2016 at 2:52am

Let's make a paranoid break: Graph (+ some chaos) as a truss > Good exercise for a C# beginner.

1. See attached using native components. But (a) we need pts inside the volume as well and not just "spread" on the skin (b) the proximity thingy ... well ... by what means can you yield "some" truss rigidity (triangulated pts the way that a ball pivot algo works > no no for trusses)?

2. Write down something that addresses the (a) and ... we'll see what can we do with (b).

3. Write down something that addresses the potential clash situations between struts (since all that is chaotic ... chances are that struts MAY clash as well: not the case in a "controlled" truss due to a classic U/V subdivision).

I hear you: but by attempting to address one thing we've created a nightmare were more things are in the pipeline > is this a bit insane eh?.

Indeed ... but the only way the hard way IS.

Attachments:

Graph_as_truss_V1.3dm, 1 MB
Graph_as_truss_V1.gh, 15 KB

Permalink Reply by dimitris skom on January 31, 2016 at 3:14am

so I finally made it work yesterday and fill the brep with points. but still I have to solve the clash situations. also check your mail because I need some further info about the sardines hehehe

Attachments:

Graph_as_truss_V2.gh, 17 KB

Permalink Reply by peter fotiadis on January 31, 2016 at 4:13am

Appears that there's an issue with your mail (101 LINQ examples floating in cyberspace plus some other stuff as well etc etc > failed 2 times to deliver).

Maybe do a proper hotmail account and forget gmail?

If it's OK there's time for sardines > Da Morgada sardines (what else?) > as instance definitions > the only way to do pro truss stuff (and any pro AEC stuff) > only for the brave (who signed the short paper option - sorry about that, blame Alzheimer).

Anyway get these as well .

Tasks for the brave:

1. Chaotic strut/strut clash check > I don't want to check each strut VS all the others > that's stuff for kids in kindergarten. By check I mean Curve to Curve closest Pts distance >= 2 * strutR + some tolerance (real-life).

2. What MAY be the right way? (hint: Use List Intersections > google that and get the gist of it). But what List VS what other? Answers to: The Lord, District 9, North Pole.

PS: you may don't understand it (yet) but you are a naturally born killer > that's why the Lord (The Merciless) recruited you > Lord expects very big things from you > in a year/decade/century (the sooner the better).

May the Force (the Pink option) be with us all.

Attachments:

Graph_as_truss_V1A.3dm, 2.4 MB
Graph_as_truss_V1A.gh, 126 KB

Permalink Reply by peter fotiadis on January 31, 2016 at 4:23am

BTW: No mail or yours arrived

BTW: the truss maker that I've mailed to you has the random option(s) as well (have you got the gist of it?) .

That way you can skip the popGeo AND prox thingy and deal with clash stuff/checks INSIDE the C# before delivering the goods (rather the most efficient way). I mean that ... well ... we use a surface but the result is so chaotic ... thus nobody can tell the difference. And the added bonus is that we check stuff in a very controlled manner since actually we deal with collections on a per U/V division basis.

This means that ANY clash check must be included to the truss maker as well.

Permalink Reply by dimitris skom on February 16, 2016 at 2:12pm

peter check your mail for what I have made so far.

1. I didn't use the Curve.ClosestPoints method because I didn't understand how it would help, so I did it the all time classic way

2. what I made works with your truss maker at the random option (and only with that for some reason :P )

3. the popGeo I created is really really slow without the class check inside it. so I don't think that it would be efficient to include it in the popGeo

ps. I don't know why you couldn't send me the mail because I received other mail. Here is my hotmail in case gmail doesn't work

dimitris_skom@hotmail.com

Permalink Reply by peter fotiadis on February 16, 2016 at 2:45pm

e_mail failed 4 times in a row.

Let's talk tomorrow about some freaky things.

For your efforts/dedication to find the Truth Out There insofar > this approved (by The Lord) cuppa is waiting for you.