We have some decent progress with the constrained point idea. Let’s assess how it’s going, and decide where to head next.
We’ve created some Point classes of dubious merit:
When we look at the work that has actually been done in this file, we find that the bulk of it has gone into the function point_on_line_at_distance, which can provide the logic for a better DistanceAnglePoint, which sorely needs to be better—I abandoned it when it became clear that I should focus on the solution function first.
There is nothing in this file that has much value other than the point_on_line_at_distance function. The tests are green. I’ll commit the file, then strip everything out except for the above function, whose name I choose not to type a third time, and of course its supporting tests.
Done. Remaining tests run. Commit again.
Ah. Feels good to get those not very useful things out of here. I do think we’ll want something similar but let’s do a bit of speculative design.
We’re working on a way to specify a locomotive linkage and then compute its motion as the locomotive runs. The idea will be that the user will draw or build the linkage, and then transcribe certain details as data for our program, and then our program will be able to animate the linkage. Whether we run the animation live, or export its critical points isn’t clear, but it doesn’t matter. If we can do the one we can do the other.
Let’s picture a piece of linkage as a rectangle with some key points identified. Why a rectangle?
So a linkage component will have a root, and some number of key points of interest, where other things are attached.
The current idea that we’re looking at is the notion of various specialized kinds of “points” that could be part of a linkage component, specifying connections and other aspects of motion. If the idea works, all the linkage components we could imagine could be configured as a collection of points that enforce various constraints.
One of those points will be connected to a “parent” that drives the component, and the other points take up their positions based on what the driver does to them.
A wheel’s parent is probably a fixed point, as it will always have a given offset from the root, which we can treat as a constant. (This is not strictly true, since we actually move and rotate our bogies. But the wheel’s position and rotation are not handled by the linkage, they are provided “from above”.)
A side rod might have an OffsetPoint as its parent, while the OffsetPoint would be taking its position from its parent, the wheel’s FixedPoint (and the wheel’s rotation.) The side rod just circles around, like the crank.
A main rod, on the other hand, would have an OffsetPoint at one end, but a DistanceToLinePoint or whatever we might call it at the other end.
So what I’m envisioning is that this program, when it grows up, will provide classes like MainRod, whose constructors know how to configure them, and that furthermore, if you need to configure something special, like a bell crank with three output points, or five, you can just create a GenericComponent and toss in your own selection of constrained points, to get whatever odd shape you need.
The question today is “where should we go from here?”
I’ve played with some simple constrained point ideas, and decided that there isn’t any code worth saving, though I propose not to forget what I’ve learned in the doing.
As I’ve been writing this, an idea has been forming. What if a Component is an object containing named Points. It has a parent, which is always a Point or equivalent, from a preceding Component, that will have a defined position (and rotation) by the time we go to calculate this Component.
I mentioned named points. There might be some fixed predefined names for points, such as driven_point or root, but when you define your five-pointed bell crank, you’ll want to give its points names that you prefer, since the thing has never existed before.
So what if the Component has a Lua table of Points, indexed by name? The good news would be that we could define any kind of Component and link them up. The not so good news is that tables take space and accessing them by name takes time, and we do want this code to be tight, at least if we’re going to run it live.
(If it’s going to be used to generate a set of critical points to be animated like a puppet, speed would not be an issue. And Python might be a better choice than SLua.)
From what we’ve seen, the puppet mode looks fine in operation, although sufficiently slow motion might conceivably look jerky. Although … we could interpolate between points … maybe not an issue. Surely faster and perhaps no more memory required, or not much more.
Needs analysis and experimentation, I guess.
What to do, that’s the question of the morning.
I think the answer is:
Toss the code, keep the learning. Quite often the best thing. I think that’s the case here, and there’s no one here to stop me.
Or … I might start with the one I have and refactor / rebuild. Sort of start at #4. Not sure yet.
Safe paths!