Articles tagged with “blorg” are generally ongoing reports on a day’s work, deemed not worth retaining under specific headings, to keep those more useful.
The Beta version of SL with the SLua-VS Code connection is out, so this morning I’m going to try to follow the instructions and load it on my Mac. I’ll echo the steps and comments below. Here goes.
It has been a while. I’ve been working in Python, where I could draw and export moving linkage diagrams. But I am motivated, I can’t imagine why, to return to Luau and SLua for this work. Weird twists and turns, including a brief detour into VSCode. Weird.
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.)
In my never-ending quest for something to think about, today we’ll try to make linearizing a Bezier a bit faster, with a bit less memory impact. We’ll measure what we can.
Just for fun, I want to see whether I can speed up the search of the linearized Bezier object. With a change in structure we may be able to binary search it. Result: Not enough improvement.
Let’s experiment a bit with converting the LSD mover to SLua. Today I’ll try to do it with tests, which should provide some confidence in refactoring. (Still not seeing enough benefit in an SLua conversion.)
This morning I plan to look at the main loop for one of our movers and see what it might be like in SLua. I’ll just follow my nose: I have no idea where this leads. Just a quick look.
More by way of exercise than purpose, I propose to continue “refining” the production of split bezier points.
Having read and experimented a bit with Luau performance, I’m in a refinement frame of mind. Let’s look at the Bezier and its approximation as linear segments.
In a search for something else entirely, I found myself reading an article on performance in Lua. I decided to test an alternate representation for the Bezier.
When we program, many if not most of our mistakes fall into a few categories. I set out to get help with one of mine by improving my tools.
Let’s clean up this code and get the new Tests as clean, lean, and mean as we can.
Let’s do a bit more with the CodeaUnit cloning. Maybe before / after?
Having added some CodeaUnit features to our own Tests framework, I’m deciding whether to port it to SLua, or whether to improve our existing Tests along similar lines.
Today I propose to improve our
Testsframework a bit.
There’s another kind of “iterator” possible in SLua. You pass it a function, which it applies to each of the elements one after another. Let’s see what that might be like.
WARNING: Some learning in here but no production code yet. Processing oddly-designed data structures can be tricky. Last night I wrote an “iterator” just for fun. Let’s think about collections and how we can process their elements.
We’ll explore aligning responsibilities in our little objects, and I even think we’ll rename one of them, now that we can see what it is.