https://observablehq.com/@jrus/spheredisksample

https://news.ycombinator.com/item?id=44963521

to fit the trend of the day. People may also enjoy

https://observablehq.com/@jrus/sphere-resample

It has equal spacing on the surface between lines, a loxodrome can't have that property since by definition it must cross the meridians at the same angle at all times. That means it always gets denser near the poles.

---

Start with the curve:

x = 10 · cos(π·t/2) · sin(0.02·π·t)

y = 10 · sin(π·t/2) · sin(0.02·π·t)

z = 10 · cos(0.02·π·t)

Convert to spherical coordinates (radius R=10):

λ(t) = π/2 · t (longitude)

φ(t) = π/2 - 0.02·π·t (latitude)

Compute derivative d(λ)/d(φ):

d(λ)/dt = π/2

d(φ)/dt = -0.02·π

d(λ)/d(φ) = (π/2)/(-0.02·π) = -25 (constant)

A true rhumb line must satisfy:

d(λ)/d(φ) = tan(α) · sec(φ)

which depends on latitude φ.

Since φ(t) changes, sec(φ) changes, so no fixed α can satisfy this.

Conclusion: the curve is not a rhumb line.

this is how one should look for varying intersection angles:

https://beta.dwitter.net/d/34223

"The simple requirement that one should move on the surface of a sphere with constant speed while maintaining a constant angular velocity with respect to a fixed diameter, leads to a path whose cylindrical coordinates turn out to be given by the Jacobian elliptic functions."

In both of these cases, mathematically generating the points to visit (in gcode) is needed, and we don't care about constant speed - the firmware handles the instruction->motion part.

I am thinking about non-planar printing mostly, but this could also apply to CNC finishing passes.

The actual "correct" thing to do would probably be to have the point maintain constant speed in 3D space like a real boat sailing on a globe, right? But that's a rather bigger lift:

    const degrees = Math.PI / 180;
    const bearing = 5 * degrees; // or it might be 85 degrees? Not sure off the top of my head
    const k = Math.tan(bearing);
    const v = 0.001 // some velocity, adjust as needed
    const phi = (t) => v*t/Math.sqrt(1 + k*k) // the sqrt is not strictly needed
    const theta = (t) => k*Math.ln(Math.tan(phi(t)/2)) // this is the annoying one haha

    const x = (t) => Math.sin(phi(t)) * Math.cos(theta(t))
    const y = (t) => Math.sin(phi(t)) * Math.sin(theta(t))
    const z = (t) => Math.cos(phi(t))

Actually, now that I think about it, choosing z = c * t is kind of both influencing how the path is parameterized as well as the path carved out on the sphere.

that was also my first intuition when making this, but turned out making the z function linear won't make it a sphere.

to make a sphere, you have to configure it in a way so that it forms a circle with the other axes. In this vis, its the sin(0.02 * πt) and cos(0.02 * πt) part that do this.

someone makes an interactive version here: https://www.desmos.com/3d/t66etxi1y8 (thanks!) so you can try changing the z function for yourself.

thanks for sharing! definitely an inspiration, I might use it for next project :D

Unfortunately, there’s usually no closed-form solution for it, so we have to do it numerically. And for doing that there’s in general no better way than at each t, binary/interpolation search a dt that roughly corresponds to the ds that you want (start with the previous dt, it’s likely a very good approximation).

In practice, you’d do that once and store the results, basically approximating the curve as a polyline of evenly-spaced points– at least assuming that the curve itself isn’t changing over time!

It’s sort of like an Archimedean spiral. So, yeah, if you parameterize velocity and make that constant, you’re in better shape. Note that the radius starts at zero, though, so something is going to have to deal with limits.

A simpler path following approximation (e.g., for a game) might be to just give an iterative system path and tangent targets with respect to Z and then provide an iterative constraint on velocity with some sort of basic tweening (e.g., new = a * old + (1 - a) * target). Then just drag the thing along Z, like bead toys for toddlers.

What you're looking for is called arc length parameterization. Basically, you need to compose the curve with the inverse of its arc length function. Aside from a few special curve families, closed-form solutions don't exist.

currently the path is expressed as function of (t), and it's the t that progressed at the constant speed.

so the cube will finished one loop at the same duration, and thats why it moves much slowly at the beginning and end, where distance of one loop is smaller.

I have to admit I made it that way because it's simpler to implement:D. Making it move at constant speed require some more works, but others have provided some solutions here so I think I'll try

Let's find out where this sentence goes!

> Linux

Would look into that.

> Brave.

Definitely would look into that.

> 32 GiB RAM, Intel i9 w/ 24 cores

This part is not relevant

Based on a quick Firefox performance report on the minified source code, most of the time seems to be spent in functionality looking like frame handling. There are some signs of time calculations.

One educated guess would be that something in frame time calculations goes off, possibly due to restricted time resolution to prevent timing related fingerprinting. This would cause next frame computation to start immediately instead of after the intended timeout.

Later on - about a quarter of a century ago - we had VRML which enables anyone to just focus on the what rather than the how. But VRML always needed a plugin to download, which was no fun at all in the dial-up days. We almost had a 3D web, but no, it ended up 2D.

I digress. However, if you want 3D plots without having to reinvent the wheel, three.js is fit for purpose, with the right CodePen example to get you started.

I am guessing that the HN audience would be / should be interested in that distinction. Mathematically speaking, chaos is an extreme sensitivity to initial conditions, and is very much still in line with deterministic systems. The resulting output, while seemingly random (since there is no easily identifiable pattern), is mathematically and conceptually different from actual randomness.

I believe you. But the colloquial definition (I’m looking at a dictionary right now) is “complete disorder and confusion”; “a state of things in which chance is supreme”; “the inherent unpredictability in the behavior of a complex natural system”. That path fits that apparent definition. The post is written in a way that a relative layman would understand, so it makes sense to speak/write in a way non-mathematicians would expect.