I usually do this for slower motions where “ease in & out” are apparent, especially in animated scenes. Additional points are added manually, and can take quite some time.
I’m using the Handy (FW3.0) + ScriptPlayer. (Both don’t interpolate actions on their end).
My experience is that:
It works very well under Wi-Fi connection (via handyfeeling or local-host).
There’s noticeable micro-stutters under Bluetooth connection (via Intiface).
Some concerns I have:
Compatibility issue on devices other than the Handy / OSR2
- This topic shared a similar point of interest. Many seems to experience jerkiness playing interpolated actions.
Conflict with script players / device firmware that interpolates between actions themselves.
- For instance MultiFunPlayer’s built-in interpolation feature @Yoooi
I’d also like to know if there could be ways of bettering this manual interpolation process of plotting out a curve.
If you need something to test the idea out, this script by shbek and this script by me will be good example.
(both includes a detailed version with smooth curve, and a simplified one with peaks only)
I’ll use the my tools plugin inside of OFS for things like that. The big issue there though is the difficulty of learning it. I tossed it out at first because it made no sense but after sitting down and figuring it out over several days/weeks, its actually extremely useful. To the authors credit, I dont think english is his native language so it’s understandable that the documentation is a bit rough. As far as your question though, it can be hit or miss some small movements are actually quite irritating because you wanted to feel them more but others are done in such a way (probably on accident or experiment) that it works. Maybe finding out what those differences are would be a good start. But then again, everyones different, were working with how people percieve things through touch. There wont be a one size fits all answer.
Thanks for the reply. I use MyTools a lot, however hasn’t figured out a way of interpolating curves with it. But I probably haven’t uncover all potential of it. Now I think of that there’s this “slope” feature I never got the chance of using. I’ll try to figure it out and see if it is meant for something like this.
Update: It isn’t, or at least couldn’t achieve the desired result on its own, unfortunately. Still there are many features could help with the plotting process.
Of course this is a much more complex issue. I am merely a scripter who’s not on the technical side of things. Opinions of other users, scripters, product engineers and software developers will be very welcomed.
I think interpollation should be part of the device/program to run the script. As instead of scripts, they might be able to use milisecond precision to handle things and be significantly smoother in performance. While they dont do this now, it would be a welcome feature to support.
Having interpolation in the script causes the issue in which you cant tell interpollation from actual changes in movement.
I think the funscript code itself is too limited for this. As for good interpolation, it should have another value (besides at and pos) which tells the curve (for example 100 being as sharp as possible, and 0 being as smooth as possible). A good standard here that is used acros many devices will do a lot better than those few extra nodes.
This is why i think the funscript should not contain interpolation as nodes in the movement. You can expand the data in such script at runtime to contain that info (for example scriptplayer can set a interpollation treshold and generate such curves), but removing hard points requires manual actions as smoothing actions can often be undesired and break immersion.
This way, you have backward compatibility for devices not capable of performing interpolation even if the data would be there.
Pardon my utter ignorance on codes and engineering. Here’s my analogy of it in terms of vector animation:
Take Blender’s timeline for example. Each key frame can hold an interpolation method, which defines the curve used for the upcoming displacement.
For an animation like this, we only need 2 key frames. The first frame contains the easing type information, and the programme will handle the interpolation accordingly.
Otherwise, we’ll have to key in 12 frames with positional value only. (like how we did with an interpolated script)
Back to machines. That will be 2 commands sent within 2 seconds, versus 12 commands sent in 2 sec. Which should be more tolerant on transmission frequency.
Perhaps we don’t have to bin Bluetooth connectivity then?
For the bouncy cowgirl pattern you should add the extra points to the script. 12 points in 2 seconds is still a very low data rate and should be no problem. In case your device is not able to handle it, the player software could reduce the number of points if needed.
I used that number bc the animation just happens to have 12 key frames XD
I’m currently plotting all the extra points, but then it gets jerky on Bluetooth connection. So I usually release two versions of my script, one without the interpolation and with peaks only.
This procees can be done with OFS’s simplify function. However I’ve not seen a player software supporting that yet.
It could be done by the program, but not by in realtime by a device that only receives the next position to move to (like T-Code).
For example, let script 1 be
at 0 pos 0
at 1000 pos 70
at 2000 pos 0
and script 2 be
at 0 pos 0
at 1000 pos 70
at 2000 pos 100.
Obviously, the slope (speed) at time 1000 is different, zero in script 1 while positive in script 2. So to generate the curve between time 0 and 1000, the interpolating algorithm already needs to know the value for time 2000 at time 0. For slow scripts, you would need to set a latency of several seconds in the player program to make this working.
Right, protocols like T-Code would have to be extended for device based interpolation. Now it’s only “move to pos x in time interval y”, you’d have to at least add the slope at the end of the interval (for a first approximation. With ease in / ease out, the slope at an intermediate point will be higher than with a linear motion).
Script players already must lookahead to the next point (in the example: at 0, the pos at 1000 already must be available to know at what speed to move to the next point. It would be easy to read two or three points ahead, and fit a smooth line through these points. When the script is static (read from a file) it can be done without introducing latency. I understand OSR2/SR6 are already doing this.
Sure, it’s easy from the file / for the player. Spline interpolation should be fine for easing, as it does not overshoot.
I just wanted to mention that interpolation can’t be done by a device as long as it, point by point, only gets the next position to move to.
From an end user perspective, interpolating to simplify point-heavy scripts is a big painpoint for me. Some scripters’ style is to have a ton of points, and some scripting tools also just generate points at fixed intervals. My launch is not great at handling this.
I’ve tried using FunExpander to manually simplify scripts, but it does not consistently give good results. It can lead to missing strokes and jumpiness.
I don’t see why funscript files or similar couldn’t contain more complex curve data instead of just points, and then be able to simplify them down to something the end user’s toy can handle.
Shout out to scripters who also make a simplified version of their point-heavy scripts
Obviously it depends on how the device handles thing, if the device receives commands ahead in time (the handy does as far as i know), then it can do these calculations runtime as it knows when they become relevant. Bluetooth obviously wont be capable of doing this. But any device that can cache info and sync the timer and has a fast enough processor in it can do these things.
Note that calculating a curvature doesnt realy need that much info. For audio they only need double the Hz to make the audio resolve properly with quite some complexity. Sure, scripting does require a bit diffirent handling (audio doesnt require the point to be at its peak for example), but its not like it will need an entire script here, probably using just 5 points (2 ahead and 2 behind of the point you want to calculate) it can already interpolate things accurately on the fly (the 2 behind are there to consider the actual current position and adjust things if needed). And that means just 4 points ahead is technicaly already enough.
But the main issue is in its details, making everything smooth isnt always desired. Quick movement changes in otherwise slow paced action might end up distorted, while the uninterpolated script might have done this more accurately. Sure, this can be handled by using nodes at proper locations (a sharp peak can be created), but guiding the device here by simply stating it must be sharp saves some guessing effort (which still is calculation time).
So these things are very well capable to be done within the device. But again, its mostly about standardizing this, since when every device does it diffirent, it makes scripting unreliable.
Well, quick movement changes require high power and cause high forces and wear. So the motor control will inherently smoothen the curve. The knowledge of how to approach a point (with high speed, continuing in the same direction afterwards, or stopping in order to reverse direction) can only help the motor control to make the motion more accurate.
Sure, some few points ahead would be sufficient, but this requires changes in protocols that rely on the time a command / point is being sent. Just some short latency compensation does not help, as it won’t always cover the next few points.
When Raser1 was developing Joy-Funplayer one big item was the ability to program with a mouse “on the fly” which creates “raw script data” with a large file. It is very smooth with all the points it creates.
There are several interpolation methods. For an example look at the Ver 4 of this player and you will see the choice of Linear, raw, cubic, or cosine based interpolations. You can test what each does with different funscripts.
Thanks for the input, I think I should definitely look into that software more.
I have made one script with an incredible amount of action points before. It was generated with the motion tracking funscript generator. So I believe it’s possible to create silky smooth curves by adding more points.
However what I’m concerned about is the compatibility of these scripts. I’ve ran the script on the Handy (via wifi) and it went like a seizure. If devices like the Launch couldn’t handle the action-rich script we posted on this site, I doubt they can handle anything beyond…
