Hello i was wondering how can i model this in grasshopper i tried using lunchbox with random splits but it is not really optimum so any idea how to do this ?
test1.gh (11.1 KB)
Hello i was wondering how can i model this in grasshopper i tried using lunchbox with random splits but it is not really optimum so any idea how to do this ?
test1.gh (11.1 KB)
Here is a thing that randomly combines smaller triangles into non-overlapping larger triangles. Might be adaptable to the more complex grid of triangles in your image.
Looking at the image it seems this is more of a diagonally and horizontally-contoured shape, with contours crossing each other, then ‘randomly’ pick overlaps, some end up as triangles and some as diamonds. Sorry if I stated the obvious.
Yes it is very complicated maybe there is a cull pattern or something but i cant figure it out
Thank you! i will check it out
I need to step away from the keyboard, this thing has gotten carried away…
I started with the intention of creating “random” diagonals and horizontal fragments with the intention of applying yesterday’s version ‘25a’ to the result. At some point I realized that wasn’t needed because it was already looking similar to your image. There are reduce sliders (blue groups) that randomly reduce diagonals, horizontal lines, triangles and horizontal line segments.
The orange group (bottom left) supplies prime numbers as seeds. A little crazy!
Wow that is amazing i need to learn to think like you.
Thank you !!!
With so much randomness it’s probably difficult to see any difference but I made some small changes, including some group titles and slider names.
The main one is how the horizontal segments are generated. Random Reduce is a peculiar component as it requires a ‘Number of items to remove’. So now you set a ‘HSegs’ slider to determine how many segments the horizontal lines will be shattered to, then a cull pattern is used to choose every other one.
One more detail. The white group “holed surface (wide lines)” adds some width to the lines:
It probably makes the model a little slower, less responsive to slider changes, so some temporary disabling - or a Data Dam - might be helpful.
I see a tiny flaw in the bottom right corner…
Idle hands…
I found a way to make the “holed surface (wide lines)” group faster by eliminating Srf CP.
But it was still slow moving sliders to change the pattern so I added a Data Dam. (red group)
But then realized they interfered with each other so added a Value List and Stream Filter (teal group) to switch between the two modes.
Then I tackled the mystery of why the ‘Count’ slider (second cyan group) caused changes when there were more than enough planes to create diagonals spanning the rectangle. Reason? I was randomly reducing planes that didn’t intersect the rectangle! Complicated to explain but fixed it. Would be nice to avoid the ‘Count’ slider and manual setting completely. The ‘Brep | Plane (Sec)’ component generates an error (good!) when ‘Count’ is sufficiently high.
Fixed the “tiny flaw” mentioned in previous post (yellow group) by culling very small curves.
Changed the way horizontal line segments are culled, making it random.
Three more things…
These issues are common to many GH models so I was aware of them, but set them aside for expediency.
Orientation
The “base curve” for this model is a rectangle in the XZ plane. Several vectors are implied in that decision: horizontal (X), vertical (Z) and the Y axis for rotation. To handle other orientations the base plane must be generalized using Deconstruct Plane, though it can be more complicated than swapping vectors. The base plane must be rotated correctly to preserve curve directions. Deconstructing XYZ point coordinates can be problematic so using Curve CP ‘D’ (Distance) can be more flexible.
Manual settings for dependent geometry
To get the diagonal lines in this model I initially used two arrays of planes intersecting the rectangular surface. The problem was that the number of planes required to fully span the rectangle was not easily computed so a slider was used. It also was slow. Both issues were addressed by using Contour instead.
Branches of geometry (avoid Flatten!)
Conventional wisdom says to avoid ‘Flatten’ for consistent data tree operations but it gets more complicated than that. PShift (Shift Paths) and Trim Tree work well but can require ‘Simplify’ on their inputs. And they can fail badly when data trees have only one level of branching, as explained in this thread:
That cluster might be written better because it can fail to get the expected result unless a second pShift is connected, as shown here:
There can be other factors that make it difficult to handle branches of geometry, including making a relatively simple model more complex. In this case, the code could be modified to accept a grafted list of rectangles representing faces of a building. The “base plane” for each branch would have to be determined from the rectangles. And the many sliders and seed values (11?) that determine randomness would have to be shared by all rectangles or supplied somehow for each branch.
For these reasons, I’ll save that job for another day and post code that addresses only the first two issues mentioned.
I’ve been studying the earlier scripts and now i will study those too, thank you for all effort it is really helpful
Of the five versions that are similar, the last one is the best! If you run out of time, study only the last one. It often takes me multiple versions to really understand issues and perfect a solution. I’ve always enjoyed that aspect of software - it’s “soft” so easily changed.
Hello,
what is the advantage in using prime numbers as seed instead of any other integer?
I have no idea if there is any advantage at all. Nothing but a whim.
Normally I use integer sliders from 0 to 300 for seed values, which is a huge range of combinations when there are six seeds plus reduce factors as in this case. It is an experiment to reduce possibilities. Each of them could be replaced by 0 to 300 integer sliders.