Articles tagged with “linkages” are about moving the pistons and rods that make a locomotive appear to operate in SL.
Let’s start with a clean, um, slate and build up some linkage code again, from scratch, whatever scratch is.
We have some decent progress with the constrained point idea. Let’s assess how it’s going, and decide where to head next.
We’re in the middle of working on the idea of “constrained points”, which seem to me to be a smaller object that may serve as components that we can combine to make linkages. Today I plan to get a solution by transforming the problem.
Maybe we should constrain points, not wheels and rods. Then wheels and rods would span points …
I’m feeling a gap between where the code is, and my sense of what it could or should be.
Let’s push on with the arc-following idea. I think we’re just about ready to put it into and object and thus into play, but I could be wrong.
OK, I understand that x/y swap. Let’s see what’s next in my tests.
Now that I’ve done the math, let’s code the function. With tests, of course.
The next linkage component that I plan to work on is a link that changes the direction or amount of motion from an input object, typically a main rod or possibly a piston rod. In fact, we don’t care what the input is, we only care about where its effector end is, as is usually the case.
Today I propose to remove the MainRod and GeneralMainRod classes, replacing them with the NewMainRod. Probably not interesting.
I’ve been working quietly on a new MainRod. Finally getting somewhere. Here’s my report.
Today I think we can find a simpler implementation of the Main Rod (formerly connecting rod). I think a few simple rotations should do the job.
I managed to draw some pictures of a simple linkage of DriveWheel, MainRod, PistonRod:
It’s time to figure out next moves. Small steps, always, but do we need to bend the path a bit? If so, tending where?
Today we’ll see if we can do the piston rod. We’ll stick with the horizontal version for now. Wish me luck!
After our brief trip into AI-suggested code for finding points, let’s get back to the main thread here, defining linkages and animating them. A bit of progress.
I asked the evil LLM for a polar coordinates solution using a vector type. It is hard to dislike the result.
I have sinned: I allowed an “AI” to write some code for me. I am astonished and ashamed.
I’ve been reading a bit about linkages and forward kinematics. That leads, after a bounce or two to geometry and algebra.
A timing test for the table-style object creation. After that, I don’t know yet.
Today, we’ll consolidate some of our learning into the code. The idea is to have a system that we can use readily.
I’ve decided to use my vector class with the linkages. It should make things easier to express. We’ll find out.
The linkage-to-SVG yak is sufficiently shaved. Its supporting yak, the SVG library Group object is also sufficiently shaved. Now can we get back to the reason we came here?
By Odin, I think she’s got it!
Behold the awesome power of … POLYMORPHISM!!!
OK, let’s try to add a Group to Suzanna’s SVG library. How hard could it be?
It would be a lot easier to be sure that my test linkages are working if I could see pictures. That’s nearly convenient. Nearly.
OK, moving right along, now comes the learning. (distance/radius doesn’t really count.) Let’s make a new linkage piece and make it connect.
I have done the calculations to move the elements of a linkage, more than once, in LSL. It’s tedious and error-prone. Might SLua be more helpful? (Mistakes will be made below.)