Section 31

[rsfairman]

Something's not right in the presentation of cubics. In particular, it reads

e_1 = B + td
e_2 = B - (1-t)d
Where d is the total length of the line segment from e_1 to e_2.

You can't add a scalar (t and d) to a vector (B) like this.

In my opinion, the presentation of the argument for cubics is unclear. The argument that I think you are trying to make can be summarized by

1. Let S, B and E be three points in the plane. We want to fit a cubic Bezier to the these points, so that it starts at S, passes through B, and ends at E.
2. The three points determine a circle.
3. Given such a circle, it is easy to determine the tangent to the circle at B.
4. We don't want to fit a Bezier to the circle, but it is reasonable to use the same tangent at B.
5. Somehow, knowing the tangent at B allows you to determine e_1 and e_2. It is intuitively clear that this is so, but you haven't worked it out in your usual (admirable and very useful) level of detail.
6. You point out that the length of the e_1/e_2 line should be equal to 1/3 the S/E distance so that three co-linear points do generate a line as the fitted curve, but you don't explain exactly why this is so. Maybe this is clear in light of some earlier portion of the document.

This is a side issue, but the last interactive figure of the section appears to show that the line determined by the control points will be parallel to the line determined by the starting point and final point. I haven't tried to prove this, but it certainly appears to be so, and it's an interesting observation if it's true.

Finally, I would point out that you can also choose e_1 and e_2 so that the e1/e2 line is parallel to the S/E line. The algebra in this case seems to be easier. Maybe there's some reason (that I'm not aware of) that is a poor choice.

[Pomax]

Very good point, d is not the "total length" here, it's the vector from e1 to e2 (which has length ||e2-e1|| of course). As for point (5): it heavily relies on having read chapter 30 first, so in isolation to would certainly read like some details are missing. As for (6), that's a fair point. It's an shortcut choice based on what a cubic approximation of a curve looks like, but that's worth explicitly mentioning.

Time to rewrite the text a bit.

This is a side issue, but the last interactive figure of the section appears to show that the line determined by the control points will be parallel to the line determined by the starting point and final point. I haven't tried to prove this, but it certainly appears to be so, and it's an interesting observation if it's true.

Only because we used a circle as our initial guide to construct the curve, so that's not universally true (after all, we're fitting a cubic polynomial through only three points, so there are infinitely many curves. For "the" unique solution we'd need five points)

Finally, I would point out that you can also choose e_1 and e_2 so that the e1/e2 line is parallel to the S/E line. The algebra in this case seems to be easier. Maybe there's some reason (that I'm not aware of) that is a poor choice.

You can, but then the resulting curve will bulge out, rather than start off already heading towards the middle point. So that's one of those "the maths might be easier, but the program functionality this is meant for in the first place would be a worse experience":

If someone if using a graphics package and wants to join up the yellow point, point B, and the red point using some "points -> fit curve" that builds them a Bezier curves/paths, that is not the curve they would have wanted to see 99.99% of the time =)

(the story is different if they're trying to form a path through lots of points, but then there's no sense in using curve fitting, we'd instead build a spline through all those points)