Articles tagged with “movers” are articles about the fundamentals of moving things along paths using fast motion setters (llSLPPF).
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.
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.
Let’s try our PathFinder on one of our linearized Beziers. That should tell us whether we’re on the right track. No pun intended.
We’d like to be able to write movers that can use any or all of our various path types—without changes.
Long and largely pointless musing, retained for some thoughts on what Bezier should return. Includes timing result on creation vs reuse of small tables.
That
_position_atmethod bugs me. I could probably explain it, but I’m not sure anyone else can understand it just by reading it. Can we make it a little better? Let’s find out.
Let’s try a compact fast scheme to see what it’s like.
One central issue in our movers is conversion from a distance to a point (and rotation) along a defined path. Let’s explore the space of paths and their representation.
Now that we have this nice little DistanceFinder, let’s work out how to create one that we can use.
I think the Bezier class is quite close to what we need. L_Bezier seems like a valuable component, though I’m not certain of that. What I do not see is quite how to provide quite what the mover code really wants.
I’m still working, slowly, to get my Mac SLua/luau development environment set up to work, if not perfectly smoothly, increasingly smoothly. I have one small idea to try.
My current guess is that we’ll approximate Bezier curves with a polyline representation created by following the control points of 8 sub-curves of the original. Here’s a picture of the accuracy of that approximation.
Still making small changes to smooth my workflow. When common actions go more smoothly, we work with more ease, we tire more slowly, and we are more likely to notice things that need improvement.
I have been doing all my Luau development locally on my Mac for a week or so now. Let me describe my personal development environment, and work a bit on improving it.
Interpolator isn’t doing it for me. Let’s back that out and try something else. We’re here to learn.
In which, we try a smaller object on for size. Doesn’t seem to fit.
Let’s explore the division of responsibilities in the L_Bezier class. I think we’ll learn something useful, and I expect that we’ll improve the code. Here are the two methods we’re considering:
After thinking about searching in my new L_Bezier, I think I’ll try a different storage scheme. Summary article, infinite painful detail left out.
Working toward a polyline creation and use scheme that seems nearly good. We’re learning here.
Let’s begin to create the data structure that represents a linearized Bezier curve. It’s a lot like the thing called “polyline”.
… for searching. Today I want to explore some ideas for searching path objects. That capability is central to the operation of our vehicles. No truly new code, just thinking and some new tests.
It’s time to try a serious Bezier mover in SLua. The result, in my biased view, is quite nice. Lurvely. Added: Caveat.
I am feeling impatient. This tells me that I need to be extra careful today, but I really want to move a prim along a path.
Let’s try that idea for improving
make_waypoints. I have a good feeling about that.
There is a school of thought in object-oriented programming that tends to create many very small and simple objects. And there are the other folks.
No, not Pigs in Space, curves. I plan to do some Bezier experiments in Aditi, leading to some motion experiments, distance approximations, who knows what all. Certainly I don’t.