I have a Fruit Jam and several other board (including the Olimex). It's great fun and I'm enjoying programming it. The biggest delight is that it's actually possible to reason about performance, extremely difficult on larger computers because of all the complexity.
That said, Photoshop doesn't feel like the sweet spot of what to run on this hardware. There's only 520kB of fast static RAM, and that's not enough to run a framebuffer with enough bit depth to hold a photo reasonably. I have invented a 4bpp compression scheme which opens up possibilities, but it's asymmetrical and in its current form compression is very slow, so it wouldn't be suitable for interactive work.
As a general matter, emulation makes a ton of sense. You can emulate all kinds of computers up to the late 80s, including video subsystems. Of course Mac and PC don't really do anything interesting like tiles and sprites, they're pretty much just dumb framebuffers.
That was my first attempt at a PhD thesis. The one that actually got me over the line was the second attempt, on spirals and splines. Of course this was all years ago.
Elastica curves have only three parameters, compared with four for cubic Béziers, Spiro curves, and the new hyperbezier. The easiest way to understand that limitation is to consider the parallel curve of an Euler spiral. That has a built-in asymmetry, one end has higher tension than the other. But the math for elastica locks in odd symmetry around the inflection point.
I think hyperbezier would be a natural fit for boat hulls, but it's not a mathematically precise approximation to elastica either. I'd say to carefully evaluate it, and I'd very much like to hear how that goes.
ETA: "parallel curve of elastica" is an intriguing curve family to consider for this application, as it has the correct number of parameters and ticks a lot of the other boxes. However, the math for this is hard mode.
For reference, drawing lines for a wooden boat is still made with actual wood splines on the drafting table, held in place by heavy "ducks" or "whales". Here's what is looks like:
This is future work, but I expect it to go fairly well. One encouraging sign is that there are parts of the parameter space where you do get an exact solution: circular arcs and circle involute. Another encouraging sign is that it's easy to get bounds on curvature, which is important for figuring out whether there's a cusp in the offset curve.
There are two separate questions here. One is how much moving control points creates expected changes in the same direction. Béziers nail this, as the position of a point at t is a linear combination of the control points, with the Bernstein polynomials as weighting functions. So it always feels like direct control. With my mapping, you get this for a nice big chunk of the parameter range – small to moderate angles and control point distances. But this property does fall apart when pushing to extremes.
The other question is whether the control is local. As others have remarked, this has much more to do with the way the curve is embedded into a spline than the curve family itself. In particular, it is deeply affected by the continuity constraints. As payment for the local support, cubic Béziers only give G1 continuity. Euler spiral splines, by contrast, are G2 but changes do cause those ripples.
The pen tool prototype linked in the blog post suggests giving designers more choices. If you specify all control points, you get G1 just like a cubic Bézier. But it also gives the choice of specifying one control point on a smooth endpoint, and solving the other for G2 continuity. In my experience, it feels more like local control than Euler spiral-like splines. When you want smoother curves, you do that, and when you're willing to sacrifice continuity for local control, that's also possible.
Yes, there are regions of the parameter space where moving a control point has vanishing effect on the curve shape. I'm not thrilled about this and have explored alternatives, but this is the best I could come up with. Pretty much all approaches based on solving for optimal curve fit have discontinuous "flipping" behavior. Another approach would be to split
We haven't yet done the work wiring this up into a spline like the older pen tool draft. The "auto point" is not a form of subdivision but is a way of achieving G2 continuity.
Yes, hyperbeziers can be split and subdivided without much trouble at all, and being closed under subdivision is an important mathematical property that was lacking in the earlier draft. This follows directly from their formulation as polynomials. If you look into the code, you'll see that there's subdivision at the near-cusp to make the integral robust.
The P/C naming evokes Hermite but there wasn't a lot of thought into it.
Math is heavier, but this is more nuanced than you might expect. My feeling is that computers are fast, so if we can draw higher quality curves with less human effort, it's worth it. But the seeming simplicity of Béziers is deceptive; you often have to solve inverse arc length problems (for example to compute dashing), and curve fitting is really hard (I have a blog post in the pipeline on that). So I think overall the math is only slightly heavier.
The goal is human-driven interactive design, originally motivated by font design. Splitting into more Béziers obviously gives much finer control, but it's hard to avoid them getting lumpy. In most fonts you have a minimum number of Bézier segments and accept whatever fine details the Bézier math gives you. That's even more so when making variable fonts, where the control points are interpolated.
I haven't yet done a rigorous comparison with NURBS. While they're hugely popular in CAD, they're basically unused in things like font design.
Thanks for these questions, they obviously show a deeper understanding.
Thanks! Okay this makes sense, and I have to agree interactive design with fonts & CAD does call for more control, and subdivision and resampling does often lead to lumpy, or just harder to manage curves. Personally I use splines mainly for CG hair rendering and procedural geometry, so very different goals. Do you see any major benefits to using hyperbezier curves for procedural/simulation assets like hair, or for applications like maps or auto-generated UI or other use-cases outside of manual design?
I have some modest experience with the polynomial curves but very little experience with the kind of non-polynomial curves you post about. I’m always curious but haven’t spent the time studying that I’d like to. I don’t have a lot of experience with NURBS either; it was just the rational in the hyperbezier curvature formula that made me think maybe there’s a relationship, and/or the rational in NURBS has something to do with it’s greater level of control versus the uniform B-spline.
First, for hair rendering you've got a 3D trajectory, which Béziers can handle just fine, but I'm not sure about these spirals. I do have a chapter in my thesis and there has been a bit of followup from others, but I can't say anything with confidence.
That said, because of the specular reflections, applications like hair really would benefit from higher degrees of continuity. Cem Yuksel has a recent SIGGRAPH paper on how to tweak Béziers to get more continuity. In fact, seeing that was one of the motivations to take this work off the back burner.
I'm not sure about maps. But I do know of applications representing the centerline for autonomous vehicles that use polynomial spiral representations, specifically because of the extremely high degrees of continuity you can attain. For that, you don't have to represent these high-tension curvature regions.
I do think there is a specific application for drawing smooth connecting lines in autogenerated diagrams. These tend to be S-shaped, and with Béziers you tend to get curvature peaks near the endpoints. You're much better off with monotonic curvature and with spirals that's easier to achieve. And I also believe being able to get those squircle/superellipse shapes would help as well.
> because of the specular reflections, applications like hair really would benefit from higher degrees of continuity.
Oh this is interesting. So FWIW - I’ve done a bit of CG hair in production (in a previous life, for DreamWorks) - and now that everyone’s ray tracing, I like to advocate for considering quadratic B-splines for CG hair over cubics. In practice, I don’t personally think you can see anything in hair specular reflections that is based on degree or continuity beyond C1. Catmull-Rom is only C1 and people have been using Catroms for hair for a long time (and interesting side note - I’ve found that Catmull-Rom curves are pretty lumpy and ugly, even lumpier than quadratic B-splines. This is possibly very similar to the issue of designing with subdivision you mentioned).
My opinion here does not apply to surface patches - with surfaces, the continuity can be visible in the reflections. But at my work among the researchers there was a very strong assumption that cubic B-spline curves would be visibly better than quadratic, and that quadratic would suffer from reflection artifacts due to the C1 continuity, which just doesn’t seem to be true (and ignores the history of Catmull-Rom). Quadratic curves are faster and more accurate for ray intersections and bbox calculations, and they offer some interesting advantages like having an analytic rotation-minimizing frame (with the Frenet frame, even…). Of course with procedural curves, I recommend only the quadratic B-spline, not Bézier. With a uniform B-spline, the degree of the curve is essentially nothing more than a smoothing factor. Production hair/fur/sim data tends to be over-sampled already, so the smoothing factor doesn’t buy you much.
BTW, yes I know Cem and I’m familiar with his work. He also has published on some non-polynomial curve types, so your post reminded me of him as well.
re: the control points having areas where the curve is unresponsive. IIUC, whereas the control points of a Bezier have direct meaning, this is an attempt at a sensible/usable mapping of synthetic control points to the curve? Which presumably means it could be made much better with some work/exploration? Or did I misunderstand that part?
As a clarification, the hyperbezier curve can do a loop, but I deliberately chose not to make that accessible in the parameter mapping. I couldn't figure out how to do it with any reasonable continuity. It's possible to flip from the normal shape to the loop, but I wanted to avoid that. And if you don't flip, then all trajectories have to go through an exact corner as an intermediate, which is very different behavior than the cubic Bézier. In the Bézier, the cusp can occur anywhere along the curve, but to make the corner shape it has to be exactly at the intersection of the endpoint tangents.
There are other Bézier shapes that the hyperbezier can't match, including two cusps on the interior. As you say, I consider these not very useful in actual 2D design, and am happy to give them up for smoother curves and the increased range of superellipse shapes.
I was curious about this and had a look. The code doesn't look much better than what a good C compiler might produce, and I found quite a few opportunities to optimize. It doesn't look much at all like the 8088 code I wrote when I was a teen. Among other things, so much pushing and popping.
Take the irow loop in vga12.inc[1] (of course I'm going to look at the graphics code). Each iteration does push di; rep stosb; pop di; add di, ROW_BYTES (and some other stuff). Why not save the push/pop and add (ROW_BYTES - count), which could be stored in a register (dx is free here)? Just the push+pop is 15+12 cycles.
True, that piece can be optimized better, but quality of the assembly code in general is not far away from what I had been writing in 1993-96. Back then, push/pops in function prologues/epilogues were a sign of experienced assembly programmer who avoided register clobbering by using standard calling conventions.
That said, Photoshop doesn't feel like the sweet spot of what to run on this hardware. There's only 520kB of fast static RAM, and that's not enough to run a framebuffer with enough bit depth to hold a photo reasonably. I have invented a 4bpp compression scheme which opens up possibilities, but it's asymmetrical and in its current form compression is very slow, so it wouldn't be suitable for interactive work.
As a general matter, emulation makes a ton of sense. You can emulate all kinds of computers up to the late 80s, including video subsystems. Of course Mac and PC don't really do anything interesting like tiles and sprites, they're pretty much just dumb framebuffers.