How to make this grid form around the circle?

Hi guys,

Iv been working on this script over the weekend (with plenty of help from you fine folk).
I think its just about there but i have one last thing i would like to change but im not sure how to go about it.

Currently the script creates a grid from a point, finds the centre of the grid and creates a circle from that point. But I would like it to work the other way around so i can adjust the grid cell size and circle radius without having to change the X & Y extent of the grid. As well as, have to adjust the origin point of the grid.

I want to be able to pick a point as the centre of the circle. Define its radius, and then create a grid with the same centre point as the circle. So then it will automatically fit around the circle and grow / shrink to the needed size.

I’m hoping this makes sense the way i have explained it. Below is a small section of the current script where the circle is created from the centre of the grid. This works, but requires more fiddling to get it correct than i would like.

Diagram Script (159.9 KB)

If you decide to open the grasshopper file, the internalised points might be a million miles away because they are based on the map of the UK.

Thanks in advance guys.

You mean like this?
Diagram Script (157.8 KB)

1 Like

I noticed you were working on it separately too all the way to the bottom of the canvas so I applied the same to that - I might have dragged it to the top:
Diagram Script (160.4 KB)

1 Like

I’d do something like this, bounding box is pretty fast, the circle curve is not needed, you can delete it if you want (I think point in curve is slower than Distance from center for the culling pattern)

in your definition it would look like this, with the advantage that Distances are already calculated, so after a cull pattern they can be plugged directly into the Data Binning:

Diagram Script V3 (1) (161.9 KB)

1 Like

lol true why did I even do that :rofl:

1 Like

on a side note, the colors you are seeing in the bars are not right…

this is what it looks like if the outputs of the list item are not flattened (shouldn’t be flattened in this case)

this might not look like what you desire, but this is what this definition is producing when wired correctly (I think you have posted about this on the other thread, I’m going to read it :smiley: )

[edit] sorry for this, I have continued the conversation about this particular thing in the other Thread to not mix things up: How can i clean up / simplify this grasshopper script? - #4 by inno


aahhh this is perfect! thankyou very much. I don’t suppose you could give me a quick explanation of that second expression you have used there could you please? Is that 2 equations within one expression component? i haven’t seen this before but reading it, it looks like that’s how you are able to find the centre of the grid/circle and then move the grid to that point?

thanks agan

you are exactly right

x slider you can interpret as the radius of the circle
y slider il the size of the edge of a single square cell

A takes two times x (2 * radius = diameter of the circle) and divides it by y (length of the side of a single cell) then rounds that number to closest bigger integer
this way you get the number of squares that are needed to fill the entire side of the bounding box of the circle with squared cells

as the only geometrical reference we have to create this whole array of cells is the center of the hypotetical circle, point C while the array of cells is created using the bottom left corner as reference, we move the circle center to the bottom left corner through B which just creates a vector of amplitude x = y = “minus_half_total_grid_size”

so actually the Move component just moves the point C from the center of the circle to the bottom left corner P using vector B

after that, you measure the distance between:

  • the center of each cell (using bounding box that I guess is faster than Area)
  • the center of the circle: if that distance is smaller than the radius of the circle, then your box is contained… and the Cull Pattern takes care of that

now that I think about it after a fresh sleep, I believe instead of capping the extrusions to make meshes out of those, using the extrusions to create a mesh box directly will trim some more time:

with the slider S you decide how many “levels” your bars will have, in the case shown in the picture as a ratio of their height

but maybe you want to show something like 20 steps for each bar (in case you can remove the Divide component and just plug a slider indicating how many divisions along Z each bar should have) and will look like this:

the point of this is still the same as in the other topic: the less divisions, the less color distributions, the more “in between” colors are lost as there are no points to be sampled :slight_smile: so your final choice :slight_smile:

in this particular case, you gradient has 5 colors equally distributed along the 0-1 domain, so if you have 5 vertical divisions on you mesh it looks like you are good to go, because those are equally distributed and color -I guess- is already linearly interpolated between closest vertexes…

but when your data will -maybe- become more complex and the gradients will vary, maybe you want to increase also those?

you can show/hide mesh edges with CTRL+M while focus is on the GH window :+1:

I’m on a laptop from a few years ago, but with the mesh change I can play with this definition “almost in real time”… meaning it doesn’t lock the Gh screen for seconds, but it reacts to the data sliders pretty instantly

another stupid thig I just realized :slight_smile:
using point to number to read just the Z values of the points will trim another bit:

updated file: Diagram Script V3 (1) (163.6 KB)

not real time, but pretty fast!

1 Like

oh wow, sorry mate. I hadn’t seen this reply pop up.

Just logged in to ask another question to see this!

looks pretty spot on actually, shame i missed it. But thankyou anyway!

1 Like