JanetRossini.github.io

Lua, LSL, Blender, Python in Second Life

Project maintained by JanetRossini

Back to the Drawing Board

Sep 6, 2025 • [design, linkages, lua, testing]

I’m feeling a gap between where the code is, and my sense of what it could or should be.

There is always such a gap: my code is never perfect and I rarely run out of ideas for making it better. But I try to be sensitive to a feeling of “this isn’t going well”, long before it turns to panic. I try to take that as a notice to assess the situation.

In the case of linkages, assessment is even more important, because while I have animated many linkages, what I’m trying to do now is to devise a scheme, almost a language for defining linkages that can, in a real sense, animate themselves. If this scheme works—which it might not—we’ll be able to create a bunch of linkage components, specify how they connect, and be done. All the positions and rotations and whatnots and whichevers will “just happen”.

Now there are known algorithms for solving linkages, nominally Forward Kinematics and Inverse Kinematics. What we are doing is more akin to Forward, which, given a starting configuration, computes where everything is, where Inverse takes a desired end position and computes what everything has to do to get there.

But I’m explicitly not using even Forward Kinematics, despite that it is a solved problem. The solution involves creating a very large matrix and applying it. My reasons for not using it are two: first, I think it will be too costly, and second, I just don’t want to. The latter is perhaps the more powerful reason: I’m here to have fun.

Anyway, I think today is a day to think about the code. And then, some things might happen. I might decide to:

push forward with this code in the current style;
scrap this code and try an approach that applies what I’ve learned to some new angle;
identify what I’ve learned, add it into this program, and proceed;

My intuition is telling me to scrap this and begin again. My experience tells me that starting over can give better results but often does not.

And there is a twist: it’s really hard to test this code without seeing what it does with the actual linkage. I can only create snapshots using SVG, and it is tedious to do so. I am quite tempted to move to Python with Pygame, so that I can have dynamic graphics whenever I want them.

There is a drawback to that idea: being able to see the graphics makes me very much less inclined to do real testing, and having solid tests is something that I value highly. It’s a bit dangerous to move to a scheme where graphics is easy, because testing is kind of hard, and I am, if not lazy, at least … well … OK, I’m lazy.

Anyway, today I plan two activities: this article, where I’ll think about and summarize findings, and then some offline sketching and drawing of linkages, thinking about what they are, how to represent them and such. A bit of conceptual design.

Here’s the first part:

Findings

The Classes: The classes so far represent particular named components of a locomotive or similar linkage. Their behavior is embedded directly in each class. It seems to me that the behavior is somehow separate. In a sense, every component is just a rigid thing, a bar or wheel or gear. It is constrained by its connections to other components, not by its own nature.; Therefore, I suspect that the fundamental “smart” object we’re looking for is a Connection or a Constraint, not a MainRod. A MainRod would just be a dumb stick with constraints.; This is a suspicion, not an actual idea, and it’s the main thing I’d like to work on.
Irregularities: The various classes have evolved. The naming is inconsistent, and there are ideas, like the “driven end” that are beginning to appear but are at best still vague. One good way to eliminate irregularities like this is just to work through the code smoothing it out. Another way is to figure out what “regular” would look like and move the code more directly toward that. And a third way is to scrap what we have and start over: at small scale that can be a safe thing to do.; (It is not, in my opinion, a safe thing to do when the program gets sufficiently large. Unfortunately, no one knows what “sufficiently large” means.); Anyway, I want to think about the irregularities and what they’re telling me about what I should do.
Meeting the World: So far, I’ve been mostly ignoring the question of providing the information that a Second Life locomotive build would really need in order to animate its linkage. Fundamentally, we need to return a local position for the object’s root and a local rotation around the locomotive’s y axis. On the one hand, that’s easy and I’m not worried about it. On the other hand, however, the information we need isn’t really present, or at least isn’t readily present in our current objects.; We could defer this question for quite a while. All I’m really doing here is learning how to solve the problem. There is no commitment in my mind that this right here is the program that I’ll use to solve the problem. This is a prototype, a learning platform.; And as such, when it has served its purpose, we can thank it for its service and send it to the repo, where it can rest, drink, and eat with the other fallen warriors.
Graphics: I mentioned that above. I’d like to visualize what I’m doing and presently that’s too difficult.
Tests: At first I was writing tests that checked actual specific numeric results. That was tedious, because I had to draw a picture, then use my calculator to solve some triangles, and then create a test with those numbers.; Finally, I realized that if the constraint is “driven end goes to a point on this line, at five meters from this point”, I could more easily just test the distance to see if it was (very close to) five, and check the point to see if it was on the line, which is easy to do even if I can’t quite remember how to do it right this minute.; Tests like that do not quite satisfy me. Generally the kind of constraints we have “on a line”, “on an arc” produce two possible solutions, and we have to pick the right one, So it is possible that if we don’t do that well, the result we get is mathematically correct but the connecting rod would flip over and bash into the ground.; Therefore, I need to improve my testing a bit, although the constraint checking idea goes most of the way to what we need. I rather wonder why I didn’t think of it earlier: it’s not like it’s a big secret. Somehow, one sticks to the solutions one has in hand, until the pain gets too high, I guess.

That’s all that comes to mind right now. I’m going to start sketching, but if other topics come to mind, I’ll make a note and come back and edit this if it seems valuable.

Until next time, find safe paths!