I’m new to more complex Grasshopper workflows and I’m trying to panelise a glass roof dome using curve intersections.
I have two sets of curves (grid/UV curves) intersecting on a dome surface, and I want to generate a planar quadrilateral panel at each cell (i.e., each region bounded by four neighbouring intersections). My main issue is sorting/organising the intersection points so I can consistently build each quad (correct point order and matching neighbours), without getting twisted panels or wrong connectivity.
What’s the recommended approach in Grasshopper to:
reliably sort intersection points (e.g., along U/V directions or per-curve)
identify the four corner points for each cell
construct planar quads suitable for glass panels (or a best-practice alternative if perfect planarity isn’t feasible)
Any tips/components/workflow suggestions would be appreciated—thanks!
below i have attached 2 images, which i tried in an alternative way , just for visualization reason .
It can get you your discrete square-ish panels, with easy access to the four corners. “Construct planar quads or best-fit alternative” is quite hard from there, though, good luck!
Just to add context: I rebuilt the elliptical dome to match the existing structure and I’m working with the existing glass tile dimensions. So the method I’m using is partly driven by that constraint: the dome is already rationalised to a single tile size across the surface, and I’m trying to keep the panelisation consistent with that module throughout.
If you think there’s a better way to organise the point/cell data (given it’s tied to a fixed tile dimension), I’m keen to hear it.
At the moment I’m working from the information we have: dome clearance, existing rafter locations, and a target glass panel module (based on the existing tile dimensions). The client’s request is to explore parametrically-generated patterns on the existing glass roof, so my first step has been to rebuild a usable base model from the available constraints and generate pattern studies on top of that.
Regarding planarisation vs. tile size: right now the pattern panels I’m generating are not fully coplanar—they’re being used for concept-stage studies to develop the visual logic and distribution. Once the preferred direction is agreed, the next step will be to rationalise it properly (and I’m aware that enforcing planarity may require local adjustment to panel geometry and potentially small variation from the nominal module, depending on tolerance and what’s acceptable).
For the edge condition: based on the limited site info we have, the perimeter panels are not quads in reality,.. they’re trimmed and become triangular/cut pieces, …so I’m not currently trying to force those into quads.
I’ve attached the existing structure reference and my current WIP/CD images for context. Since we’re still early/concept-stage and information is limited, I have a bit of room to test options before locking down a fabrication-ready strategy.
And not always a quickie, but I think you can cheat. Not sure it fits the ‘solution’ for you, but for something similar I remember trying MeshFromLines through python (yellow group below) + kangaroo (planarize), particularly Daniel Piker’s examples found in the forum, one of them adapted here (white group): el Dome.gh (89.4 KB)
There is a reason why many glass domes have a similar shape to the proposed. So if I’m saying something that was obvious to everyone anyway – sorry. There are some ways to generate quadrilateral planar surface instead of planarizing them afterwards, which has some benefits.
If you cut a section of a torus, you can extract planar surfaces from:
May be less important than you think. But maybe you have other experiences with planning/constructing gridshells. In my experience, we’ve always compared a few parameters including repetition. Of course, it makes sense to have some size families – this is often the case with translational surfaces, and there’s often symmetry in the projects. And the glass usually has to be cut to size anyway. But I’m by no means an expert in grid shells, and perhaps someone (you) has had completely different experiences with them.
I believe all these squares are the same size, but I’m not sure? The anomaly near the center (lengthwise) is because of how you created the “dome” using Rail Revolution, which has one edge of the surface there. Using a torus as @Baris suggests will make that go away.
Joseph_Oster, Baris and René Corella, - your suggestions really helped me rethink the workflow and move toward a better solution.
I was initially trying to find a quick workaround and ended up testing an alternative method that isn’t fully correct, but it’s been workable for now and I was able to get planar panels out of it. The downside is that I’m not achieving the full dome consistently with this approach.
I’m going to apply your ideas to improve and properly complete the process. I’ll attach the Grasshopper definition I made so you can see the method I used, any feedback on what I’m doing (and where it’s going wrong) would be really appreciated.
I wrote a different method using a torus section but found the my filtering method is broken! Still works for your original “dome”. I won’t post code until it works.
This version sets the number of cutting planes (X and Y) instead of using DivLength to set the size of the “squares” explicitly. SrfSplit works much more quickly using ‘torus’ vs. ‘original’.
I took the easy way and added dimensions (gold group) of the dome that should match the inputs of the original, as they do when using ‘original’. But ‘torus’ needs some adjustments of the poorly named ‘R1’ and ‘R2’ sliders so the domes are the same..
P.S. It was easier to change the ‘R1’ and ‘R2’ sliders of the original “dome” to match the values obtained by the torus but the two methods don’t result in the same domes. I think the torus method is better. But again, the scale of this dome surface us absurd! Millimeters?
