What you see is a sphere made of four identical curved patches. It’s basically a tetrahedron inflated to a sphere.

How would one best make such a patch in Grasshopper?

I am looking for the least amount of steps. In the end I want to make my own Grasshopper component using C#. If there is a way to just specify curvature and the trim using a set of floating point numbers, that would be fine.

That would be great! As I wrote in my initial post:

In the end I want to make my own Grasshopper component using C#.

So if I could simply create the NURBS patch using constant numbers, that could be the simplest solution. Then the patch can be copied three times and transformed to create the full sphere.

Imagine a tetrahedron, octahedron or icosahedron or any similar thingy used in Domes and the likes. A mesh in fact. This means that the connectivity of everything is in our hands (that’s true for Breps as well but since meshes are way faster … why bother?).

Foreach edge (MeshTopologyEdge in fact) do the projection on the engulfing sphere or the ccx or way better the arc (or the short path using the vertices: that’s quite slow). Sample the Curves in a List … meaning that you have a MeshTopologyEdges enumeration. Pay great attention to tol matters and the likes.

Then … is elementary my dear Watson … since a FE connectivity (Faces to TopologyEdges) tells us what to get. I hear you: what about a dodecahedron? (pentagons). Well … that could be seriously slow (patch).

The general case: spread random points (“even” or not) on a sphere, do the Mesh using a proper Ball Pivot algo and then … may the Force be with you.

Update:

While bad things happen in the practice I found a couple of minutes for a “basic” set-up: As it is … er … hmm … is quite prone to tol failures - see the messages (I must figure out an other way [as Plan B]). When ready I’ll post it here.

Looking more closely, I noticed a subtle error. The sphere was not quite centered in the tetrahedron, confirmed by comparing their surface areas. Three were the same, the fourth was smaller. Fixed here:

Note: used 3 Platonic Meshes as tests (tetra, octa and ico). If you input a non Platonic thingy the C# aborts (as a HashSet (of type double) registers more than one TopologyEdge Length). Modify the logic accodringly if you need this to work on spherical Dome types of meshes … or implement a BallPivot and do anything.

Update:

Added a result option and another Platonic mesh: a dodecahedron (i.e. 12 pentagons) “expanded” to 60 faces (this means that is not a Platonic mesh anymore) as we do - sometimes - in Domes (and an option to by-pass the equal edges rule):

Simply may appear but in fact (for big N of spherical parts, that is) is waaaaay slower than the split/trim/whatever Method. Explanations are complex: some day I’ll post an example (but you still must define either a Platonic collection of points or some other).

In the mean time get this as well (see incide C#: the Brep Trim (against a solid - or not - cutter) Method that supposedly should yield the fastest results … yields bananas (maybe a R bug, maybe Karma) so Plan B is used). As a challenge for sharpening your C# skills … well … you can use the Method used in the previous examples (i.e. get the arcs, sampled/join them according the BrepEdge connectivity on a per BrepFace basis (R provides Methods for that - see SDK) … blah, blah).

Used 2 GH things for that since mine are strictly internal (most notably the faced dome part).

Other than that … in real-life (I’m in the AEC market sector) we very rarely use spherical pieces in domes and the likes: they are very expensive to make (bend sheet metal in 2 directions etc etc) - and for Class 1 domes with high frequency nobody could spot the difference VS planar parts (almost nobody in fact).

For instance this is a Class 1 Icosahedron Dome with frequency 10: 1765 pieces that IF you want them spherical … prepare to spend some zillions.

This is the only way you should solve such problems for primitives. Hardcode them.
If you already have a modelled part all you need to do is to load controlpoints and the knotvector and create NurbsSurfaces out of it . Then you scale it to radius of 1 (if this is not already the case) and then apply a transformation matrix to place it and define its scale. This is the most efficent and simple way. Even more faster is to transform the points first and then create the surface of course.

Your Transform should be composed of a Scale- and ChangeBasis Transform Matrix.