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 7, 2016 at 11:54am

Hmm ... same size means (a) Kangaroo1/2 (b) no guarantee that the same would be same (rather "same" in 99.99% of cases).

I have several defs that do that type of stuff (in general: "relaxing" shapes on surfaces) but I'm at home right now and here there's nothing similar around.

Permalink Reply by peter fotiadis on January 7, 2016 at 12:17pm

OK found some draft (meaning more primitive than a T-Rex) on that matter:

But ...

1. Since this is a draft (how it survived at some home workstation is a miracle) IT DOESN'T work on trimmed surfaces (need more code) AND in closed ones (see warnings).

2. The real stuff that I have in practice use solely C# code (even for Kangaroo2) and I have a strong feeling that this is not what you want (if you don't speak the language). It does that because GH is just a part (~10%) of the whole AEC arsenal (that is managed via C#) ... so everything must "fit" within the "general" production pipeline (code from some app "goes" to another with the fewer possible changes blah, blah).

So ... this attached could serve as an indicative guideline about the relaxation that Daniel does with his wonder thingy (Kangaroo, that is).

Attachments:

Relax_Hexagons_V1.gh, 172 KB

Permalink Reply by dimitris skom on January 7, 2016 at 12:54pm

I have this deformation. Is there a way to avoid it?

Permalink Reply by peter fotiadis on January 7, 2016 at 1:01pm

Yes ... just post the test surface of yours (BTW: are you familiar with Kangaroo ?)

Permalink Reply by dimitris skom on January 7, 2016 at 1:43pm

Unfortunately I am not familiar with Kangaroo neither with coding.. :/

Attachments:

hex.3dm, 875 KB

Permalink Reply by peter fotiadis on January 7, 2016 at 11:56pm

This is indeed unfortunate: without Kangaroo is rather impossible to "relax" anything. The code part (not critical in your case "as-it-is" but maybe at later design stages [if they exist]) is my way to "integrate" things as explained above.

I'll post Kangaroo "settings" for your surface soon.

PS: If this is some AEC type of "envelope" (meaning some rel-life skin out of glass or other panels/modules) your main problem is planarization.

PS: since we live in the same city phone me.

Permalink Reply by peter fotiadis on January 8, 2016 at 1:45am

BTW: this brep of yours is the totally wrong thing to work when attempting to use apps the likes of Lunchbox that work on the underlying surface (in plain English: the BrepFace "MINUS" the trimming info). This means that the U/V "grid" could yield too many subdivisions when topology is not suitable:

What means "too many" ? ... for instance spot this "corner" where hexagons are squeezed like sardines in a can: what exactly Daniel could do with a similar situation? Topologically speaking It's a classic rabbit hole where garbage in > garbage out so to speak.

Additionally the "shifting" in the "main" area doesn't help things at all not to mention that has very little real-life meaning IF this is some AEC type of envelope that would being "approximated" via hexagons (or other).

The solution? Well ... in order to get some (i.e a relaxation towards "same" modules, that is) you must give some > try to design a more "cooperative" surface especially IF Kangaroo type of physics engine is involved.

Permalink Reply by Joanna on January 8, 2016 at 2:39am

the Galapagos is not the solution?

look at this, please : http://www.grasshopper3d.com/forum/topics/creating-points-on-a-surf...

I try to create a script looking for a situation where the length of the elements are most similar to each other.

Permalink Reply by dimitris skom on January 8, 2016 at 3:53am

hi joanna, it doesn't change anything even with galapagos because the problem is the surface I am using

It's what Peter said I have to create a more cooperate surface.

@peter I made the surface without using kangaroo by lofting some curves. Is there a way to make it smoother with kangaroo?

Permalink Reply by peter fotiadis on January 8, 2016 at 4:19am

OK ... imagine some "loop" that checks what Daniel can do (on the fly) and then IF even Daniel can't do anything more ("more" equality VS deviation from the donor "shape") ... then variations on the surface/brep are attempted.

A rather complex loop achievable via K2 (that is open sourced) and obviously via code.

Plan B: Try Evolute Tools pro (a bit salty, mind) ... but this is not parametric in the true sense of the world. Anyway ... spend some time on that famous YAS Hotel video.

Permalink Reply by peter fotiadis on January 8, 2016 at 4:54am

BTW: Get this as well (don't ask how these hexagons are made [via C# code if you need to know that detects the trimming info etc etc], hence the "static" in the def name). Spot the classic policy to "maintain" a non triangular shape. That said this is "close" to your case (make the things with respect the trim info).

Fire up K1 and ... wow ... hexagons are "almost" equal: but ... the 1M question is: what was the price?

From inequality (but following the brep):

To "equality" (but kissing good-buy to brep):

BTW: I hate hexagons, he he.

Moral: give some in order to get some.

Attachments:

Relax_Hexagons_V1A-Static.gh, 223 KB

Permalink Reply by peter fotiadis on January 8, 2016 at 3:56am

Galapagos is a very good thing but relaxing things whilst respecting other things (the "underlying" surface/mesh/cat/dog/you name it not to mention the anchoring "trivial" matter) is Daniel's territory.

That said ... well ... most people believe that Daniel can address anything (and he can IF the constrains are proper AND if the problem has a solution: see Dimitri's brep VS the hexagons: unsolvable by any means at least using Lunchbox for finding the hexagons, that is).

To make a very long story sort (constrains vs constrains vs Karma) forget hexagons for the moment and stick to humble triangles as this very simple demo (using the "palatable" K1 instead of the K2) case does.

Spend some time and vary the values (on purpose the case is over-constrained): you can go from this ("equal" size relaxing):

to that (anti gravity + "feeble/weak" values in some constrains):

So ... indeed the problem appears on first sight a Galapagos type of "fitness" value(s) equilibrium (addressable directly via C# code and Kangaroo2) ... but what K values? what K constrains? towards what goal?

Spot the dilemma in this simple case: if you "equalize" too much then you deviate from the guide surface(slow)/mesh(fast). So ... what is actually the goal here? Something with equal edges that severely deviates from the architectural concept ... or the other thing?

All that before planarization comes to the party (obviously not the case with triangles).

Load Rhino file first.

Attachments: