Variation of space inbetween brick following a concentric motion

Hello Everybody !

I am currently trying to learn how to properly use GrassHopper and am pretty new to this software. I currently find myself in a dead end as I don’t know yet all the tools.

I am trying to create the following wall :

with a little twist, changing the spacing inbetween the brick according to a circular motion with my Attractors as the center.
The result I am trying to get is the following : When the point is on the highest point (according to the Z plan) the spacing is bigger and when I am at the lower point, the spacing is tighter.

At the moment this is what I got so far :

![GH 3|690x294]
(upload://uAGOUjDbl9maIdqB3yAcwc5KuIX.jpeg)

And I dont know how to manage to change the spacing in a “non uniforme” way and most important, around the Attractor points.

The point would be to make the “waving” obvious at night thanks to the inside light piercing though the bricks.

If anyone come up with anything I am really eager to hear about it !

Thanks a lot !

Project try 3.3dm (79.6 KB) Project Try 3.gh (19.8 KB)

One a bit abstract (thus solely indicative) way is as in the def attached. However you should mastermind a variety of size restrictions (most notably prior the scale) in order to avoid the obvious.

Remap_BricksSize_EntryLevel_V1.gh (24.6 KB)

1 Like

Thanks a lot for you quick reply which helps me alot !
However I notice playing with the different numbers that it does make the size of the bricks changes as well (instead of only the gap in between them). Would it be anyway to avoid it ?

And I also notice that I can’t move the first attractor anymore :pensive: The one from which the "wave’ effect starts.

Indeed as it is it changes the size … while the right thing sould be changing the N of bricks (assuming that a “standard” brick module is used).

I’ll fix the whole approach soon (that could be very easy via C# code mind … but you are after a native components solution [unless you speak C#]).

But even so this is more complex than it appears on first sight since you should avoid clash events - via trigonometry - between the bricks due to the non linear arrangement(s). Plus the structural integrity of the whole solution is more or less questionable. Plus … in real life the gaps should be “quite big” (for noticing them) meaning more structural issues.

Given the opportunity (JUST FOR FUN: this is not suitable for a novice by any means).

Imagine arranging shapes (blocks in this case for simplicity) along a Curve while taking care of any clash issue (meaning that you can do it in real-life). Imagine restricting the position(s) by a value that indicates how far the box can move “along” the Y Axis (the long Box size as shown) . Now … if that value varies (giving a greater level of freedom) … the whole package varies (in terms of N of blocks and their relative positions) as it “auto-adjusts” to the new rule … and this is what you get:

Obviously for that type of stuff … var gaps have no meaning

So … in a way … er … is the packaging that makes the aesthetics and not the aesthetics that make the packaging (LOL). For instance in this fuzzy arrangement not a single clash issue is found:


So … if one day later you decide to learn C# …just drop a word.

All of this is pretty cool, thanks a lot for all the explainations ! So there is so many different factors that it makes it almost impossible to realize this wall. Or then the curve should be really really minimal.

Though according to what you said it would be way easier and easily realisable if the wall was flat and only the gaps would gradually changes to create that “waving illusion” kind of. Like the highest part of the wave = wider gap and lowest point = smaller gaps.

Really interesting and for the #C I have such a long way to go with only basics already… But I will remember it and won’t hesitate to message you !

Is it quite possible (but not using the current approach).

If this is some sort of installation and you want to be a big spender … well … the top dog solution could be cold bended double U section primary mini rails and linear U rails in brick “slots” (top/bottom sides) and mini fixing parafernalia that secure the final position per brick in the rail and to the upper/lower brick … and way more dollars for WIFI servo motors that could move the bricks (after a computer tells them what to do) … and other freaky similar stuff.

1 Like

I see, I have such a long way to go damn. In so many domains ahah

Thanks again for your time !!

Really nice of you and incredibly fast to reply.

There’s only 2 “domains” to pick: either using solely code (the pro way) or not (good luck).

The attached it can been done via native components … but the next step (for a real-life solution) it can’t. Use it just as a rough indication of a quite complex problem.

Curve_PlaceBoxes_EntryLevel_V1A.gh (128.2 KB)

In the mean time and if you after “similar” things I would strongly suggest to get fully the gist of Kangaroo2 (the most important GH add-on by a huge margin). When you are ready notify for a K2 driven “relaxation” of Boxes in Curves with all real-life rules present.