Tetrahedral sphere

anim3

tetrahedral_sphere.3dm (91.6 KB)

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.

Are you looking to do this with NURBS or meshes?

The patch should be a single NURBS surface, just as in my example which I modelled in Rhino.

If I could somehow grab the parameters of that patch and plug them into Grasshopper, that would be perfect.

If you are familiar with C# I could provide a demo on that matter.

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.

Well … no:

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.


tetrahedral_sphere_2020Jan20a.gh (13.2 KB) DEPRECATED due to error - see below.

1 Like

tHANKS [quote=“Joseph_Oster, post:8, topic:95047”]

tetrahedral_sphere_2020Jan20a.gh (13.2 KB)
[/quote]

Thank you, this is very nice! Lot’s to learn.

Also thanks to @PeterFotiadis for the thoughts!

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:


tetrahedral_sphere_2020Jan20b.gh (14.2 KB)

And notice the four surface pieces of this sphere (radius = 1) all have the same area: ~Pi.

3 Likes

And some actions as well:

Dome_SphericalParts_V1.gh (128.8 KB)

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):

Dome_SphericalParts_V1A.gh (126.1 KB)

So the only thing remaining with regard Platonic stuff is the poor old cube.

1 Like

Wow, that’s quite sophisticated, thank you!

Thank you!

Not at all … but the general case could be (most notably having the Ball Pivot part in mind).

And this … gets a Spherical mesh vertices check …

Dome_SphericalParts_V1B.gh (135.7 KB)

… in order to work with any spherical “dome like” valid and manifold mesh :


1 Like

Thanks! Still I’m wondering whethere there is a way to simply hard code the coordinates/parameters of the surface patch, or to load it from a file.

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).

Dome_FacetDomeSphericalParts_V1.gh (126.1 KB)

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.

Obviously you can spend more: (a distorted dome that yields far-far more distinct pieces)

That said this is quite interesting:

geo_spheres_indexing_34AK.pdf (874.2 KB)

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.

Tom (BTW: what’s up? are you still after a proper slightly crashed Ducati? - if so call day/night).

You mean Morph (Splop to be exact) I guess (Get a thing [face as GeometryBase], get the Plane do the Splop on the Sphere, be a happy bunny).

I’ll post a demo test as soon as I can find some suitable (for testing Elapsed times etc etc).

This is the fastest way to do - almost - spherical parts given triads of points (may or may not be “exact” spherical points).

The U,V part is like Godzilla: for few N of triangles/triads … bigger is better.

Dome_SphericalParts_GodzillaWay_V2A.gh (129.1 KB)