Hello.
I would like to transfer this structure onto this Brep. What would be a viable approach? The characteristics of this structure that I want to achieve are the “brick-like” layout and the structural direction, which can match (not real, but hypothetical) UVs. The attached Brep is not the one I’m working on, but just an example.
I already have something in mind, but first I’d like to challenge my assumptions with some fresh ideas.
This is the intended use of Sporph, but that expects a single Surface, not a Brep with multiple surfaces. Your example brep can be rebuilt as a single surface though. The second issue is the rather extreme distortion that would be caused by the unequal lengths of the two U boundaries.
To make a more representative source surface for Sporph, I generate a trapezium using the surface edge lengths, then stretch it in X before generating a Voronoi pattern. When un-stretched, this creates the “flat” cell shapes, which can then be Sporphed onto the original surface.
If you want to create lots of sub-surfaces on the source surface, you should use Surface Split instead of Region Intersection, but this will cause a big dip in performance.
If you want a more “linear” pattern of cells, you could do something more structured than Pop Geo to make the points for the Voronoi. Maybe creating Iso Curves on the trapezium and dividing them by random lengths? Lots of options.
How can the ideas be ‘fresh’ if we don’t know your assumptions?
Cool intention and fun problem—shouldn’t you first share what you have in mind, though?
So then the ‘plant cells’ aspect is irrelevant as long as you get a brick-like pattern?
Word—but is the actual brep also made of two open surfaces, one trimmed and one untrimmed, with inconsistent UV directions?
*In the meantime, you might want to consider tweening the short and long edges of your brep with your interior edge to simulate ‘isocurve-like’ or ‘offset-on-surface-like’ curves on your brep as “U” curves: brick-like pattern on brep_U-lines.gh (16.2 KB)
Then you could attempt something like what both @Tom_Newsom and I tried doing here to build your “V” lines and complete the brick-like appearance. What about the distorted plant cell effect?
Just a thought for now. To continue, I’d personally like some fresh clarifications to the questions above
@Tom_Newsom Thank you for your insight on Sporph. The idea of using the trapezium as the source is brilliant, sometimes I struggle to unwrap a precise surface (and it’s not always worth it).
Regarding the pattern, though I don’t want to achieve something too similar to a Voronoi layout, where the short vertical segments are not aligned with the Vs. That’s what I really like about the Plant Cells structure: it’s irregular but at the same time ordered (that’s why I called them “bricks” @René_Corella )
Word—but is the actual brep also made of two open surfaces, one trimmed and one untrimmed, with inconsistent UV directions?
@René_Corella This is exactly what always happen to me when I need to place a pattern on something.
My idea is similar to yours. By creating a Surface from a Brep, defining the UVs in the first step.
Second: creating a regular grid
Third: modify it (probably through random culling or random displacement of the intersection points). Then reconnect all this adjusted points with an irregular grid.
Ah, so that’s where “something more structured than Pop Geo” comes in. Here’s a method that sets up voronoi cells along lines, to ensure V-oriented joints.
This looks complicated, but most of the spaghetti is generating all the random numbers for row spacing, cell width per row, cell width variation etc. As before, a non-uniform scaling gives you the flattened shape. Some combinations of input parameters cause the joints to wander away from the V direction so take care.
You could get even further into the weeds by introducing some waviness into the U curves. Instead of using Iso Curve, you’d make them from scratch: Point grid + more random numbers → nudge V coords → interpolated splines, then use the same cell distribution method.
The really neat thing would be generating the bifurcating/recombining nature of cell rows in your source image. That’s a bit rich for my tastes right now
Dangling thoughts: You could also add a Fillet component for a more blob-like cell, but I don’t know how you’d go about making them tessellate properly. Feels like a hard problem with lots of horrible corner (hah) cases. The method would be something like:
Find all non-overlapping straight-line segments and purge them (relatively simple)
For each cell, find arc segments from adjacent cells (with matching end points to the segment we just deleted) and copy them into this cell (fiendishly complicated, especially at junctions that are closer than the fillet diameter)
Oh, and I think there must be a better way of stretching/squashing/cell-counting that actually preserves V direction. Currently, the “short sides” are aligned with a world axis, but they should actually follow the true V lines:
I see what you’re doing. I like (and prefer) the isocurve approach. Tom’s approach is genius, don’t get me wrong, though I want to challenge relying on voronoi myself, because, well you know:
I’m thinking your system can evolve into (1) splitting all lines of your ‘brick/cell’ network, and it seems you’re already moving in that direction (unless I’m misinterpreting it):
and then (2) ‘distort’ the network with Kangaroo’s squiggling capabilities (this will require discretizing your lines + anchoring verts you don’t want to squigglify).
I’m tempted to try it just for fun if I find a time window soon, but in the meantime I suggest (and also invoke @Volker_Rakow) varying the isocurve count, which isn’t immediately doable with the component itself, but Mr. Rakow has broken that paradigm here:
Sad to say, but I… wouldn’t rely on my user object. I remember trying to use it and it was broken. I planned on fixing it, but it never got around to it. I should probably delete the thread.
My script is built off of @Tom_Newsom’s voronoi studies, just with a different way of controlling the ‘vertical’ and ‘horizontal’ variation with the point cloud input for the voronoi pattern.
It could use some work to look better as there are some cases that don’t look like natural cells, but I do like it so far
I can’t plug the original brep into my script as is, but this method should work with any single quad surface. I suppose it’s technically possible to work with 3D voronois for more complex surfaces, which would be more akin to how real cells work, but it’ll be substantially harder.
My script also breaks the cells as closed curves, and I couldn’t be bothered to rebuild them
@René_Corella I wasn’t aware of that Voronoi warning
In my attempt to mimic nature, I think a random Voronoi works better when applied at a microscale. On the other hand, when the structure operates at a macro scale, it’s much better to define some “rules” (alignments, symmetries, etc.).
Speaking of symmetries, that would be the next challenge:
f anyone has an idea on how to symmetrize the pattern along these isocurves, I’d be very grateful
It seems straightforward at first, but the goal is to preserve a slight randomness both in the mirrored areas and in the proximity of the isocurves.
Thank you both for the suggestions. That result is exactly what I wanted to achieve—ultimately, the pattern on the right is sufficient for my purposes.
If you want to mirror the pattern along these isocurves, I believe the simplest way of doing it is to generate a point cloud or voronoi pattern in a quadrant (R in the case) and then mirror it into the other quadrants. Although this will mean that your cells will be extremely warped along your surface.
I thought I had a promising data-wrangling of my own but looking into it got prohibitively expensive at the moment and I predict it won’t warrant a general solution anyway given the nature of the problem and how specific the task is (as Tom pointed out in his surface reconstruction).
Maybe, depends on the end goal I guess, or how macro is macro—anyway, I wanted to respect your surface reconstruction + isocurve efforts to build the brick-like network as clean as possible:
Of course I ate my words and gave in to the {unsucessful} voronois (one 3D one 2D → sporph)—a terrible idea because I am lazy and didn’t even make my own source surface and just rolled the dice with the one Tom and Nick used knowing it wouldn’t work:
I thought of a couple of things but I am chaperoning myself now.
Aborting mission, but here’s the file just for s@ts and giggles (no voronois, just brick linework): Plant Cells.gh (60.1 KB)
Unfortunately it hasn’t been easy to come back and test ideas (I did), especially that earlier kangaroo mention,
That was actually (kind of) the start of the same kangaroo idea while fighting the voronoi quickie—I got to an interesting point with some slowness but maybe promise:
But points to the same insight(s) about the ‘symmetry’ control you want, or the more high-level cell setup so the simulation is ‘slower’ where cells are smaller/more tightly packed vs more stretched out regions. Lots to think about and improve.
Right now it’s a total mess, can definitely be done better and needs lots of tlc but here it is: Plant Cells_K.gh (41.8 KB)
You’ll need some patience! Oh, and topologizer*: Topologizer.gha (19 KB)
*For defining the network. An alternative to needing the component would be to provide a pattern of connected closed cells (maybe hexagons or a dual mesh), as opposed to the brick-like linkage. Many thoughts, time used up again.
!
)
—jokes aside:
but looking into it got prohibitively expensive at the moment and I predict it won’t warrant a general solution anyway given the nature of the problem and how specific the task is (as Tom pointed out in his surface reconstruction).
