{"id":25872854,"url":"https://github.com/hcschuetz/octasphere","last_synced_at":"2025-03-02T08:28:53.223Z","repository":{"id":213753715,"uuid":"734809250","full_name":"hcschuetz/octasphere","owner":"hcschuetz","description":"On the geometry of octaspheres","archived":false,"fork":false,"pushed_at":"2024-05-16T16:16:50.000Z","size":18784,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2024-05-16T17:33:58.418Z","etag":null,"topics":["geometry","octasphere","sphere","texture-generation","texture-mapping"],"latest_commit_sha":null,"homepage":"https://hcschuetz.github.io/octasphere/presentation/dist/","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/hcschuetz.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-12-22T17:20:09.000Z","updated_at":"2024-05-16T16:16:53.000Z","dependencies_parsed_at":"2023-12-22T21:24:19.525Z","dependency_job_id":"087c3a14-dfd7-4ad3-b997-4e471459800f","html_url":"https://github.com/hcschuetz/octasphere","commit_stats":null,"previous_names":["hcschuetz/octasphere"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hcschuetz%2Foctasphere","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hcschuetz%2Foctasphere/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hcschuetz%2Foctasphere/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hcschuetz%2Foctasphere/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/hcschuetz","download_url":"https://codeload.github.com/hcschuetz/octasphere/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":241481408,"owners_count":19969829,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["geometry","octasphere","sphere","texture-generation","texture-mapping"],"created_at":"2025-03-02T08:28:52.200Z","updated_at":"2025-03-02T08:28:53.156Z","avatar_url":"https://github.com/hcschuetz.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"Sub-Projects\n------------\n\nSub-projects in this repository:\n- A presentation on octasphere triangulations\n  ([source](./presentation/),\n  [slides](https://hcschuetz.github.io/octasphere/presentation/dist/))\n- The \"lab\" project for experimenting with the triangulations\n  ([source](./lab/), [web app](https://hcschuetz.github.io/octasphere/lab/dist/))\n\n(Two former sub-projects that were not specifically about octaspheres\nbut rather about sphere texturing have been moved to\n[their own repository](https://github.com/hcschuetz/sphere-texturing).)\n\nNow for an explanation what this octasphere stuff is all about:\n\n\nTriangulations of the Octasphere\n================================\n\nSphere Triangulation\n--------------------\n\nIn computer graphics triangle meshes for spheres\nare frequently constructed as longitude/latitude grids\nwith added diagonals in each of the resulting quadrangles.\nSee for example\n[here](https://threejs.org/docs/#api/en/geometries/SphereGeometry).\n\nThis approach has the advantage that it is easy to understand,\nbut it also has its disadvantages coming from the fact that the meridians\nare much denser near the poles than near the equator:\n- Textures are strongly distorted.\n- Processing power is wasted for the many small triangles near the poles.\n- Degenerate triangles around the poles can cause problems\n  for geometric algorithms.\n\nAn alternative approach is to take a polyhedron (usually a regular one),\nsubdivide its faces into triangles, and then project the mesh to the sphere.\n\nA popular choice is to start with a regular icosahedron,\nwhich has various advantages:\n- Each face is a regular triangle, which is easy to subdivide regularly\n  into smaller triangles.\n- A regular icosahedron already comes quite close to its circumscribed sphere\n  (at least when compared to the other Platonic solids).\n  Therefore a straight-forward central projection\n  leads to a relatively small distortion.\n- The vertices of an icosahedron have a degree of 5 and are thus close to the\n  degree 6 of the auxiliary vertices introduced by the sub-triangulation.\n  This is helpful for some geometric algorithms.\n\nSpheres triangulated this way are sometimes called \"icospheres\".\n\nSphere triangulations based on a cube are also popular because the square\nfaces of a cube are easy to work with.\n\n\nThe Octasphere\n--------------\n\nAnother possible choice is the \"octasphere\", a sphere triangulation based on\na regular octahedron, which has these advantages:\n- As with the icosahedron, the faces are already triangles,\n  making a subdivision easy.\n- If we only map one of the octahedron faces to the circumscribing sphere,\n  we get an eighth of that sphere.\n  These eighths of spheres are useful\n  because they occur as the corners of rounded boxes.\n\nAn \"octasphere\" is created like this:\n- Start with a regular octahedron.\n- Subdivide the 8 triangular faces into smaller triangles.\n- Somehow map the vertices introduced by this sub-triangulation\n  from the faces to a sphere.\n\nWe will discuss various such mappings and their properties.\n\nIn the demo and in the following considerations\nwe deal with only one of the faces\nand the corresponding spherical triangle covering an eighth of the sphere.\nThe other faces are to be treated in an analogous way.\n\nFor simplicity we also assume\nthat the sphere is the unit sphere around the origin and\nthat our octahedron face has vertices at positions `ex = (1, 0, 0)`,\n`ey = (0, 1, 0)`, and `ez = (0, 0, 1)`.\nWe generate triangulations of the corresponding eighth of the sphere.\n\nAssume we want to subdivide each edge in `n` segments.\nThen each vertex `(x, y, z)` of the triangulation has these properties:\n- `x`, `y`, `z` are nonnegative integral multiples of `1/n`.\n- `x + y + z = 1`.\n\nThe sub-triangulation of a face has various symmetries corresponding to\nthe permutations of the three corners of the face or, equivalently,\nof the coordinate axes.\nSome of these symmetries are shown in the demo.\nThe mappings from the face to the sphere discussed below\npreserve more or less of these symmetries.\n\nWe can procedurally create the vertices like this:\n```js\nfor (let j = 0; j \u003c= n; j++) {\n  for (let k = 0; k \u003c= n - j; k++) {\n    let i = n - j - k;\n    const x = i/n;\n    const y = j/n;\n    const z = k/n;\n    const position = (x, y, z);\n    emitVertex(position);\n  }\n}\n```\nDue to the symmetries the loops can also be organized in various other ways.\n\nUsing the unit  vectors\n```js\nconst ex = (1, 0, 0);\nconst ey = (0, 1, 0);\nconst ez = (0, 0, 1);\n```\nand the [`lerp` function](https://en.wikipedia.org/wiki/Linear_interpolation)\nfor linear interpolation we can also define `position` equivalently like this:\n```js\n    const position = lerp(lerp(ex, ey, y), lerp(ez, ey, y), z/(1-y));\n```\nor like this:\n```js\n    const position = lerp(lerp(ex, ez, z/(1-y)), ey, y);\n```\n\nWhy would one do this?\nProbably one wouldn't since the simple expression `(x, y, z)`\nis more readable and more efficient.\n\nI have just introduced these `lerp`-based expressions for comparison\nwith similar expressions below.\n\n\nGeodesic Polyhedron\n-------------------\n\nThe simplest mapping from the face to the sphere is a central projection.\nThat is, we just normalize the position vector of each vertex on the face,\ngiving a point on the sphere.\nSo we can calculate `position` as\n```js\n    const position = normalize((x, y, z));\n```\nor, equivalently, as\n```js\n    const position = normalize(lerp(lerp(ex, ey, y), lerp(ez, ey, y), z/(1-y)));\n```\nor, equivalently, as\n```js\n    const position = normalize(lerp(lerp(ex, ez, z/(1-y)), ey, y));\n```\nwhere `normalize(...)` returns a unit vector in the direction of its argument\nvector.\n\nProperties:\n- The vertices on a straight line on the face are mapped to vertices\n  on a geodesic of the sphere.  (Hence the name.)\n- All the symmetries corresponding to axis permutations are kept.\n- Triangles near the center of the face are mapped to large triangles\n  on the sphere whereas triangles near the 3 corners of the face are mapped\n  to smaller triangles on the sphere.\n- Also the segments along the face's edges are mapped non-uniformly:\n  Segments near the center of an edge become longer on the sphere than\n  segments near the ends of the edge.\n\nWe often want a more uniform mapping.\nIn particular we want the edge segments to be mapped uniformly\nso that in a rounded box the edge segments of the rounded corners\nfit with the equispaced edge segments of the quarter cylinders\nimplementing the edges of the rounded box.\n\nSee [this Wikipedia article](https://en.wikipedia.org/wiki/Geodesic_polyhedron)\nfor more on geodesic polyhedra.\n\n\nEquispaced Geodesics\n--------------------\n\nInstead of applying a linear interpolation followed by normalization\nwe can use\n[spherical linear interpolation](https://en.wikipedia.org/wiki/Slerp)\nto define the vertices on the sphere in a way similar to one of the formulas\nabove:\n```js\n    const position = slerp(slerp(ex, ey, y), slerp(ez, ey, y), z/(1-y));\n```\nHere the expressions `slerp(ex, ey, y)` and `slerp(ez, ey, y)` for\n`y = 0, 1/n, 2/n, ..., 1` generate equispaced vertices along the arcs\nfrom `ex` to `ey` and from `ez` to `ey`.\n(We will consider `ey` as a \"pole\" of the sphere and accordingly\ncall the two adjacent arcs the \"meridians\".\nThe third arc from `ex` to `ez` will be called the \"equator\".)\n\nThe outer `slerp` connects pairs of corresponding vertices on the two meridians\nwith geodesics and puts equispaced vertices on these geodesics.\nIn particular the vertices `ex` and `ez` are connected in this way along the\nequator.\n\nProperties:\n- All three arcs delimiting our eighth of the sphere\n  (the two meridians and the equator) are divided into\n  `n` segments of equal size.\n- The symmetry between the `x` axis and the `z` axis is kept, but\n  the other symmetries, especially the `±120°` rotations of the triangle,\n  are broken.  That is, vertices inside the spherical triangle\n  are generally not mapped to vertices by such rotations.\n  (But vertices on the arcs delimiting our spherical\n  triangle *are* mapped to vertices by the `±120°` rotations.)\n- Intuitively, the vertices inside the spherical triangle are \"too close to\n  the pole `ey`\".\n  For example, the face center `(1/3, 1/3, 1/3)` is not mapped to the center\n  `(sqrt(1/3), sqrt(1/3), sqrt(1/3)) ~ (0.577, 0.577, 0.577)`\n  of the spherical triangle, but to\n  `~ (0.548, 0.632, 0.548)`, which is closer to the \"pole\" `ey`.\n\nSee [this blog post](https://prideout.net/blog/octasphere/)\nand [this tutorial](https://catlikecoding.com/unity/tutorials/procedural-meshes/geodesic-octasphere/) for more on\nusing equispaced geodesic octaspheres.\n\n\nParallels\n---------\n\nWe can also use spherical linear interpolation in a way similar to the other\n\"`lerp`\" formula above:\n```js\n    const position = slerp(slerp(ex, ez, z/(1-y)), ey, y);\n```\nThe vertices for a given value of `y` are mapped to \"parallels\" of the equator,\nthat is, to lines of constant latitude.\nNotice, however, that this is not the usual longitude/latitude construction of\na sphere, where all parallels are divided into the same number of segments.\nIn our current construction parallels closer to the equator are divided in more\nsegments and parallels closer to the pole are divided in fewer segments.\n\nProperties:\n- All three arcs delimiting our eighth of the sphere\n  (the two meridians and the equator) are divided into\n  `n` segments of equal size.\n- The symmetry between the `x` axis and the `z` axis is kept, but\n  the other symmetries, especially the `±120`° rotations of the triangle,\n  are broken.  That is, vertices inside the spherical triangle\n  are generally not mapped to vertices by such rotations.\n  (But vertices on the arcs delimiting our spherical\n  triangle *are* mapped to vertices by the `±120°` rotations.)\n- Intuitively, the vertices inside the spherical triangle are \"too close to\n  the equator\".\n  For example, the face center `(1/3, 1/3, 1/3)` is not mapped to the center\n  `(sqrt(1/3), sqrt(1/3), sqrt(1/3)) ~ (0.577, 0.577, 0.577)`\n  of the spherical triangle, but to\n  `~ (0.612, 1/2, 0.612)`, which is closer to the equator.\n\nSo the current construction breaks the same symmetries as the equispaced\ngeodesics above, but \"in the opposite direction\".\n\n\nSine-Based Mapping\n------------------\n\nWhile the two preceding constructions provide equispaced vertices along\nthe edges of the spherical triangle, their placement of inner vertices\nfeels unbalanced.  Mathematically this is reflected by the broken symmetries.\n\nWe now construct a mapping which\n- provides equispaced vertices along the edges of the spherical triangle and\n- places the vertices in a symmetric way.\n\nLet us consider one edge of our octahedron face and the corresponding edge\nof the spherical triangle, say the ones connecting `ex` and `ey`.\nWe want to map a uniform motion along the octahedron edge to a uniform\nmotion along the meridian.\nLet the motion be from `ex` to `ey` driven by the parameter `t` ranging from\n`0` to `1`.\n\nThe motion along the edge is given by the expression\n```js\n  (x, y, z) = (1 - t, t, 0)\n```\n\nThe uniform motion along the meridian is given by the expression\n```js\n  (X, Y, Z) = (cos(t * 90°), sin(t * 90°), 0)\n```\n\nThe coordinates `(X, Y, Z)` of the point on the meridian can be rewritten\nusing the coordinates `(x, y, z)` of the point on the octahedron edge:\n```js\n  X = cos(t * 90°) = sin(90° - t * 90°) = sin((1 - t) * 90°) = sin(x * 90°);\n  Y = sin(t * 90°) = sin(y * 90°);\n  Z = 0 = sin(0°) = sin(0 * 90°) = sin(z * 90°);\n```\nTaking this together, the meridian point has a very symmetric representation:\n```js\n  (X, Y, Z) = (sin(x * 90°), sin(y * 90°), sin(z * 90°))\n```\nThe same expression can be derived for the other meridian and the equator.\n\nNow there is no need to use the same expression\nfor the inner vertices of the face,\nbut it feels natural to do so.\nUnfortunately this expression does not map inner vertices to the sphere\nbut to points inside the sphere.\nFor example the face center `(1/3, 1/3, 1/3)` is mapped to\n`(sin(1/3 * 90°), sin(1/3 * 90°), sin(1/3 * 90°)) = (sin(30°), sin(30°), sin(30°)) = (1/2, 1/2, 1/2)`, which has a Euclidean norm of `sqrt(3)/2 \u003c 1`.\n\nAs a \"hack\" we can simply apply a normalization as a second step after\nthe sine-based expression from above:\n```js\n  normalize((sin(x * 90°), sin(y * 90°), sin(z * 90°)))\n```\nThis normalization does not affect the vertices on the edges because they\nare already normalized.  So the equispacing along the edges is not broken.\n\nProperties:\n- All three arcs delimiting our eighth of the sphere\n  (the two meridians and the equator) are divided into\n  `n` segments of equal size.\n- The symmetries from the octahedron face and the geodesic polyhedron\n  are kept.\n- The face center `(1/3, 1/3, 1/3)` is now mapped to the center\n  `(sqrt(1/3), sqrt(1/3), sqrt(1/3)) ~ (0.577, 0.577, 0.577)`\n  of the spherical triangle.\n- Still, intuitively, the vertices on the sphere appear a bit too close\n  to the edges, making the sub-triangles close to the center too large\n  and the sub-triangles near the corners too small.\n  Nevertheless the placement is far more uniform than\n  with the geodesic-polyhedron approach described above.\n\nFinally notice that we only need sine values for the `n+1` angles\n`0°`, `1/n * 90°`, `2/n * 90°`, ..., `90°`.\nWe can pre-compute and tabulate these values so that no transcendental functions\nneed to be applied in the rest of the calculation.\n\n\nSpherical Barycentric Coordinates\n---------------------------------\n\nWe will now construct a mapping that is\n- equispaced along the edges,\n- symmetric with respect to all permutations of the three axes,\n- therefore also mapping the face center to the center of the spherical\n  triangle,\n- and intuitively even more uniform than the \"sine-based mapping\"\n  described above.\n\nAs a first step we will generalize the concept of\n[barycentric coordinates](https://en.wikipedia.org/wiki/Barycentric_coordinate_system)\nfrom the plane triangle constituting our octahedron face\nto our spherical triangle.\n(Note that various concepts of \"spherical barycentric coordinates\"\nhave already been introduced earlier in the literature.\nHow are those concepts related to the one introduced here?\nAnd could we use those concepts as well?)\n\nA point `(X, Y, Z)` in our spherical triangle can be identified by the three\nangles between the point and each of the three coordinate planes:\n```js\n(ξ, υ, ζ) = (asin(X), asin(Y), asin(Z))\n```\nAs we have only two degrees of freedom on the sphere, giving three angles\nis actually redundant.\nThis is analogous to the usual flat barycentric coordinates.\nNotice, however, that in contrast to the flat case,\nthe sum of the three angles is not constant.\n\nWe normalize the triplet of angles so that their sum becomes `1`:\n```js\n(x, y, z) = (ξ / s, υ / s, ζ / s)   where   s = ξ + υ + ζ\n```\nBy construction we now have `x + y + z = 1`.\nFurthermore for our initial point we had `X, Y, Z \u003e 0`,\nwhich implies `ξ, υ, ζ \u003e 0`, then `s \u003e 0`, and finally `x, y, z \u003e 0`.\nTherefore the point `(x, y, z)` is on our octahedron face.\n`x`, `y`, and `z` are actually the (flat) barycentric coordinates of that point\nin the face.\n\nSo we have defined a mapping from point `(X, Y, Z)` on the spherical triangle\nto point `(x, y, z)` on the octahedron face.\nThis mapping is apparently very well-behaved.\nSo there is an inverse mapping from the face to the spherical triangle.\n\nWe use this inverse mapping to map the vertices of the face sub-triangulation\nto the sphere.\nThe resulting triangulation has has some favorable properties:\n- It has equispaced vertices along the meridians\n  and the equator.\n- It is symmetric with respect to axis permutations.\n  (In particular it maps the center of the face\n  to the center of the spherical triangle.)\n- While any mapping from a plane to a sphere necessarily introduces some\n  distortion, the distribution of vertices is quite uniform.\n\nWe have not given a constructive definition of the mapping from `(x, y, z)`\nto `(X, Y, Z)` and I am afraid that this is not possible in a straight-forward\nway.\nBut it is possible to give an iterative approximation algorithm, which\nhappens to converge very quickly:\n```js\n// barycentric normalization\nfunction normalize1((x, y, z)) {\n  const s = x + y + z;\n  return (x / s, y / s, z / s);\n}\n\n// Euclidean normalization:\nfunction normalize2((x, y, z)) {\n  const len = sqrt(x**2 + y**2 + z**2);\n  return (x / len, y / len, z / len);\n}\n\nfunction sphereToFace((X, Y, Z)) {\n  return normalize1((asin(X), asin(Y), asin(Z)));\n}\n\nfunction faceToSphere((x, y, z)) {\n  // Use the sine-based mapping as the initial guess:\n  let guess = normalize2((sin(x * 90°), sin(y * 90°), sin(z * 90°)));\n  while (true) {\n    const f = sphereToFace(guess);\n    const offset = f - (x, y, z);\n    if (/* offset is small enough */) {\n      return guess;\n    }\n    guess = normalize2(normalize1(guess) - offset);\n  }\n}\n```\n\n\nBalanced Placement\n------------------\n\nWe can also place the vertices in the spherical triangle in such a way that\n- the boundary vertices are equispaced along the delimiting arcs and\n- each inner vertex is \"centered\" between its six neighbor vertices.\n\nLet us call this placement \"balanced\".\nIt can be approximated iteratively like this:\n\n\u003e - Start with any vertex placement P\u003csub\u003e0\u003c/sub\u003e that evenly subdivides\n\u003e   the three sides of our spherical triangle.\n\u003e - For i = 0, 1, ...\n\u003e   - Compute a new placement P\u003csub\u003ei+1\u003c/sub\u003e from P\u003csub\u003ei\u003c/sub\u003e such that\n\u003e     - each inner vertex of P\u003csub\u003ei+1\u003c/sub\u003e is at the \"center\" of the\n\u003e       six neighbors of the corresponding vertex in P\u003csub\u003ei\u003c/sub\u003e and\n\u003e     - each boundary vertex of P\u003csub\u003ei+1\u003c/sub\u003e is at the same position\n\u003e       as the corresponding vertex in P\u003csub\u003ei\u003c/sub\u003e.\n\u003e   - Terminate when P\u003csub\u003ei+1\u003c/sub\u003e does not differ \"significantly\" from\n\u003e     P\u003csub\u003ei\u003c/sub\u003e.\n\nNotes:\n- The word \"center\" has been put in quotes above\n  because the 3D mean of several points on the unit sphere\n  will generally not be on the unit sphere but inside it.\n  An ad-hoc solution is to perform a central projection, that is, to simply\n  normalize the mean value of the neighbors.\n  Alternatively, we could use some sphere-based definition of \"center\".\n- The sequence of placements converges to the balanced placement\n  and does not depend on the initial placement of the inner vertices in\n  P\u003csub\u003e0\u003c/sub\u003e.\n- Each iteration step preserves symmetries of the previous placement.\n  The balanced placement is symmetric with respect to axis permutations.\n- The balanced placement (or a good approximation) looks even more uniform\n  than the placement based on spherical barycentric coordinates.\n\n\nOctasphere: Summary\n-------------------\n\nOf the vertex placements investigated above I think one could use\n- the geodesic-polyhedron mapping if simplicity is most important,\n- the balanced placement if performance is not\n  an issue (for example because the vertices are pre-computed for one or a few\n  values of `n` and re-used in many sphere instances), and\n- the sine-based approach as a good quality/performance compromise.\n\nThe equispaced-geodesics approach and the parallels approach\nrequire more computation effort than the sine-based approach and\nproduce a less uniform and less symmetric vertex placement.\nSo these approaches would be recommended only if there is an\napplication-specific reason to use them.\n\n\nTetrasphere and Icosphere\n-------------------------\n\nIt is mostly straight-forward to adapt the constructions given above to\na regular tetrahedron or a regular icosahedron, whose faces are also\nequilateral triangles.\n\nComputations are a bit simpler for the octahedron case because\n- the octahedron vertices can be aligned with the coordinate axes and\n- the angle between neighboring vertices is `90°`.\n\nThis made the derivation of the sine-based mapping particularly easy.\nTransferring this to icospheres and tetraspheres would mean to extend the\n[slerp formula](https://en.wikipedia.org/wiki/Slerp#Geometric_slerp)\nfrom 2 to 3 base vertices.\n\nOne could argue\n- that it does not make much sense to start with a tetrahedron, which is\n  the least sphere-like among the Platonic solids, or\n- that there is no need to use sophisticated mappings for icospheres\n  because an icosahedron is already quite sphere-like.\n\nIt might, however, make sense to use tetraspheres\nif the modelled objects (for example carbon atoms in chemistry)\nhave the respective symmetry.\n\n\nLiterature and Open Questions\n-----------------------------\n\nGeodesic polyhedra are well-known and even have their own Wikipedia article.\nEquispaced geodesics are also known and I have provided two links above.\n\nHave the other mappings already been suggested and investigated?\nSome of them feel so natural that I could imagine that someone else has already\nthought of them.\nOr are there other approaches for triangulating an octasphere?\nIf you know of previous work, please let me know\n[here](https://github.com/hcschuetz/octasphere/discussions/2).\n\nFinally, I am not too happy with the names I am using for the sine-based mapping\nand the mapping based on spherical barycentric coordinates.\nAny ideas for better names?  Please give your suggestions\n[here](https://github.com/hcschuetz/octasphere/discussions/1).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhcschuetz%2Foctasphere","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhcschuetz%2Foctasphere","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhcschuetz%2Foctasphere/lists"}