I am currently developing an experimental script inspired by the PixPort Lagos project by SA lab. My goal is to generate similar modular, labyrinth-like volumes using an algorithmic approach.
Issue:
I have completed a first iteration, but I’ve run into some challenges during the discretization and curve-sorting stage. As seen in my “rough attempt” (attached below), the geometry is currently “clumping” together into a dense, unorganized mass. I am struggling to implement a clean logic for filtering these curves to keep only the primary, long-reaching paths while maintaining a readable structure:
Generate a vector field based on the site/input geometry.
Extract streamlines from the field.
Discretize and filter the curves.
Convert the resulting lines into modular architectural volumes.
Questions:
Filtration & Collision: What is the best principle for sorting and filtering these curves to ensure the final modules don’t conflict with one another? Should I be looking into proximity-based checks or specific culling patterns?
Field Optimization: How can I refine the initial vector field to achieve a more uniform and parallel distribution of streamlines, avoiding “knots” or overly dense clusters around attractors?
I have attached my script and would be incredibly grateful for any advice, corrections, or alternative workflow suggestions you might have.
watching the video, I believe it is a voxel-based strategy similar to the techniques introduced and explored by Gilles Retsin, Manuel Gimenez-Garcia, Daniel Widrig and others at the Bartlett, circa 2015-2016 (linke this one, for instance: Bartlett Students Develop New Method for 3D Printing Concrete | ArchDaily). There was a bunch of projects based on dicretizing trajectories into voxelized space.
The key giveaway in the video is the brief sequence around 0:18 (don’t be fooled by the morph effect, it’s just for show):
. discretize a box volume into voxels
. split each voxel into 2 “halves”, for example along the X axis, so you have a Y-up and a Y-down half
. for each half, get the volume centroid and get the closest curve’s tangent from that
. if the closest curve is outside the voxel, do nothing, otherwise:
. approximate the tangent vector to a _ | / or \ segment (vertical, horizontal or diagonal)
. join all the resulting segments inside each voxel into 2-segments polylines
. fillet the resulting polylines’ sharp corners
. extrude them to form the volumes
Now, some of the above steps might not be 100% correct for the case, but they are just to give you a start with the logic.
Hello
I didn’t read the whole thread, I made some components in Nautilus to clean polylines
One to cut every “angle of turn” and one to suppress overlap (beware of distance between curves if too low the component can be very slow, better to kill the process)
Hi, I don’t have the time to check .gh files at the moment, but I fished something off of my 2017 archive. The project I was studying is the Bartlett RC4 Voxatile: https://www.behance.net/gallery/52165009/RC4-Voxatile
Back then I cooked up a gh definition that does something very similar, just straight from the field vectors sampled at the voxels’ centre (but you can easily adapt it to work by sampling curves tangent vectors):
discrete_test_01.gh (63.7 KB)
The logic is explained step-by-step in the definition (I misremembered a couple of them when I first posted straight form my bad memory…).
I ended up using it to print customized gift wrapping paper
Thank you everyone for the valuable insights and resources! Special thanks to @ale2x72 and @laurent_delrieu for their suggestions! I’ll need some time now to explore and test these approaches within workflow.
I embed a chaotic 3D vortex into a dense mesh volume, and then slice the volume into horizontal cross-sections. A regular 2D mesh is generated within each of these cross-sections. Finally, the script locates the centres of these cells and re-reads the directions of the original vector field within them, in order to pass them to our “PCB logic” for routing.
This method effectively solves the problem of chaotic jumps along the Z-axis, as it forces the entire geometry into rigid 2D planes (layers). However, because the original lines merge into a single continuous mass, we lose the elegance of individual continuous strands, and the result appears more massive rather than light and woven.
My script generates a vortex field (which is constant) and then divides the smooth curves into points, rounds their coordinates, and uses a combination of Shift List and Weave nodes to attempt to construct a stepped X-Y-Z path between them. This is a classic mathematical method for creating rigid 90-degree (Manhattan) geometry, but when applied to a dense vortex field, it produces ‘tangled sticks’, as the algorithm constantly and chaotically jumps up and down along the Z-axis, breaking the flatness of the lines, and is fundamentally incapable of constructing elegant 45-degree diagonals
How about looping through each of field line and using it as a guide. Then draw a polyline that can only move in 45 left/right and up/down by following it, while avoiding intersections and going too far from guide curve.
Wow, this is truly impressive, thank you so much @Edr
Visually and logically, this approach perfectly captures exactly what I was trying to achieve. The underlying mechanism you’ve implemented is excellent: looping through each field line to use it as a guide, and then forcing the new polyline to step only at 45° and 90° angles while actively avoiding intersections and maintaining a maximum deviation limit. This is precisely the assembly logic I was looking for.
Unfortunately, I am not yet very proficient in C#, but your solution has truly inspired and motivated me to dive deeper into coding within Grasshopper. I will do my best to deconstruct the code structure (even if I have to enlist the help of AI assistants like Cursor or Claude to break it down line by line!). If I manage to fully grasp the logic, I also plan to study the linked tutorial and try to rebuild an alternative version using standard nodes—provided I can figure out the right implementation.
Thanks again for the inspiration and for such an elegant solution!
If it wouldn’t be too much trouble, could you provide another version of the C# script where all lines are strictly horizontal and bend only within the XY plane, similar to the reference I provided?
eh, it is vibe coded so no congratulations needed . But the tutorial I linked previously should help to rebuild script in GH with anemone also there are many Flocking and Boids examples that could be used if moving forward in this direction. Only vector directions should be snapped to 45 degree angles and collisions solved
Not sure but maybe this could also help generating aproximate curves:
AI may mislead when using native GH components.
So I imagine a starter could be boids moving at discrete angles. But then modify them to move on vector field.
) link, please share it with me for the future 
