Geodesic Math in OpenScad – Part 1 (of some)Posted: August 8, 2011
A few years back, I stumbled across Zome Tools as I wanted something that my daughter and I could use as a construction kit. It was very fun to create various structures, particularly the large ones that we could sit inside. This got me started down the path of learning more about geometry in various structures, and I eventually stumbled across geodesics. Wanting to learn more, I purchased this book: Geodesic Math And How to Use It. At first, reading the book was slow going. It’s amazing how much of your basic high school and college math you can’t remember if you have not been using it. After reading through the book, I eventually wrote a simple Excel spreadsheet to do the calculations necessary to figure out the strut lengths for a dome of a given radius. Then I discovered this online dome strut calculator by Desert Domes. With that calculator, it became less interesting to figure out the math on my own, and I thus left the subject for several years.
Roll forward about 7 years, and I have wandered into the area of 3D modeling and rapid prototyping. After constructing various forms, mainly tetrahedrons, I get the idea to revisit dome construction again. I prototyped a couple of plastic parts to make dome construction fairly straight forward. They can be found on Thingiverse: Vinyl Tubing Connector, which turned out to be a rediscovery of an already known design from the 70s; Ball Holder, which was an improvement/reduction on the Yazzo Disc Joint.
I’ve experimented with quite a few other designs in this category as well. The general theme here is to create a joint that will allow the easy fabrication of polyhedra utilizing simple things such as wood dowels and glue. There are a great many ways to go about it, some using more or less plastic than others. One thing that remains though is the math behind calculating strut lengths. So, I found that Geodesic Math book amongst my things, and started to read through it again. Since I am using tools such as OpenScad and Lua to do 3D modeling, I needed to recreate what the Desert Domes calculator was doing for me. I need the ability to generate strut lengths based on a chosen geometry.
Recently, I created a set of routines in OpenScad which allow me to do various calculations for Geodesic tesselation (turning things into triangles). I posted the basic routines on Thingiverse under the thing: Geodesic Maths for OpenScad.
It starts innocently enough with some spherical coordinate routines. Spherical coordinates are handy when you’re dealing with round things. Like with the earth, there is a longitude, a latitude, and then a radius.
In the case of the Geodesic Maths routines:
Longitude – An angle calculated around the ‘north’ pole. This is similar to a longitudinal calculation on the earth. Stand at the ‘top’ of the sphere, and as you rotate around in a single direction, you mark out longitudinal angles from 0 to 360.
Latitude – This is an angle coming down from the ‘north pole’ to the ‘south pole’. This is different than calculations of latitude for Earth. So, ‘0’ latitude is at the north pole. The ‘equator’ would be at 90 degrees, and the ‘south pole’ would be at 180 degrees.
Radius – The longitude and latitude are enough to point you in a direction to look when you’re standing at the center of a sphere, but they’re not sufficient to tell you exactly how far out to go. The radius tells you how far out. If you’re dealing with a unit sphere (radius 1), then the math gets very easy. You can always scale out to whatever distances you like, but the base calculations are done on a unit sphere.
So, the first thing the new routines in the library deal with are spherical coordinates. OpenScad does not have classic ‘C’ like structures, it only has arrays. But what is a structure other than an array of memory with some values stuck in them? The first thing I do is create a function that will return me an instance of a spherical coordinate:
sph(long, lat, radius)
This will return an array that looks like this: [long, lat, radius]
These values can be accessed in code like this:
sc = sph(0, 45, 1);
lon = sc;
lat = sc;
rad = sc;
This is very simple. Nothing too exciting. But, it is the basis of a mess of other routines which assume this very simple structure is in place. Of course you can create the data structure yourself without bothering with the ‘sph()’ function. No problem, as long as you remember which order the values are in. The function will also assume a default radius of ‘1’, so you could create the same coordinates by simply using: sph(0,45)
As soon as you create spherical coordinates, you’ll probably want to be able to convert between those and cartesian coordinates (x,y,z). There are two routines that help you go one way or the other.
The first one will take the spherical coordinates you have and turn them into a 3D coordinate that is useful in an x,y,z based system. For example, if we take our spherical (0,45, 1), and turn it into cartesian coordinates, we have: [0.7071, 0, 0.7071]
And similarly, if you start with cartesian: [1, 1, 1], you end up with spherical: [45, 54.7356, 1.732]
That’s useful to have, and later on it will be handy to be able to go between the two worlds. You will utilize spherical coordinates because they’re handy as far as the geodesic math is concerned, but OpenScad does not know how to deal with spherical coordinates natively, so you’ll need to convert to cartesian if you actually want to display anything.
Lastly, the reason we even want to bother with spherical coordinates in the first place is because we want to be able to calculate strut lengths. Well, the ‘struts’ are essentially just the length between two points located on the surface of a sphere. So, it would be nice if we could calculate this length easily. With spherical coordinates is fairly easy to express. You just need to figure out the spherical coordinates of your two points of interested, and subtract one from the other. The result will be a number that is the distance between the two points. This is not the linear distance walked on the surface of the sphere. Rather it is the shortest distance between the two points. This is the ‘chordal’ distance between the two points. If you were talking about the Earth, for example, the distance from New York to Los Angeles, while driving on the surface, would be one thing. But if you had a tunnel boring machine, which could go directly from NY to LA, it would be a shorter distance, and be underground the whole way.
The sph_dist(c1, c2) routine takes two spherical coordinates and caldulates the distance between them. So
sp1 = sph(0,0,1);
sp2 = sph(0, 45,1);
sp3 = sph(0, 90, 1);
sp4 = sph(0, 180, 1);
d1 = sph_dist(sp1, sp2);
d2 = sph_dist(sp2, sp3);
d3 = sph_dist(sp1, sp3);
d1 == 0.765
d2 == 0.765
The distances d1 and d2 are the same because d1 represents 45 degrees from the north pole down, and distance d2 is also 45 degrees, starting from 45 going to 90.
d3 == 2
Because d3 represents the chord going from the north pole to the south pole, it is essentially the diameter of the sphere, who’s radius == 1.
The best thing to do with these things is experiment. Play with different spherical coordinates. Turn them into cartesian, and back, you can easily plot them in OpenScad by simply placing a sphere at the center once you convert to cartesian.
This is only the very beginning of the geodesic math. As it turns out, you can actually use the spherical calculations here to calculate distances on an ellipse as well. The radius does not have to be equal on all the coordinates you feed into the distance calculation. Later we’ll see how this might be useful, but for now, simply doing spherical coordinates in OpenScad is a good enough start.
Next installment, I’ll take a look at how you actually use this rudimentary information to do something useful in the context of creating a geodesic model.