WIP: Frequency split algorithm

[IvanSanchez]

Partial implementation of #3 - only implements the interior of the faces and not the vertices on the shared edges.

It's buggy (specially when the frequency is higher than ~90), breaks compatibility (changes the meaning of the only parameter of the API of this module), it's incomplete, it could be optimized further (make less calls or no calls to the pairing function), but should be a good point to do a benchmark.

On the plus side, having a frequency instead of a recursive order allows users to tweak the precision of the icosphere at a finer level. I can imagine there's an use case for using the max screen resolution as the frequency of the subdivision, in order to have something like e.g. resolution of 2px per triangle kinda reliably.

[IvanSanchez]

See also https://observablehq.com/d/45378773bf64820a

[IvanSanchez]

Biggest unresolved issue with this implementation is assigning the vertex IDs for the edge subdivisions.

The idea is to:

• Assign each edge (of the original polyhedron) an index equal to applying the Cantor pairing function to the (ordered) indices of the vertices of that edge (this approach has the disadvantage of creating gaps in the data array, as not all combinations are possible).
• Vertices along an edge have an ID of (20 + 20 * edgeDI + i)
• At each face, fetch the vertex IDs for that face, calculate the edge IDs, use that when a edge vertex is needed.

Rest of TODOs are in the code.

[mourner]

@IvanSanchez awesome attempt! How does the performance look at the moment (when using spheres of equivalent triangle count)? This is cool, but I'm most worried about the code complexity — ideally we would keep the library as minimal and simple as possible.