Oh yeah totally - I more meant that like, adding too much detail might add information that works against the way the motor controllers and stuff are designed to work. So in your example with the banana-beatdown, I’d definitely script it in the simpler way.
The more detailed one looks much better in the simulator, but the simulator is able to respond instantly and perfectly. The actual motor has weight and momentum and friction and stuff.
idk maybe people have had different experiences to me, but whenever I’ve tried to add those ‘smoothing’ actions into my funscript, I’ve noticed the Handy kind of stuttering at that point as the motor attempts to slow down the slider to match the more detailed script movements.
If my Handy wasn’t busted, I’d make a bunch of test scripts and record them with my phone camera’s slow-motion mode to see what the optimal rate is
That high power is obviously something that the device can compensate for if the script requires excessive values. Again, if the device does the calculations of those curves, this can just be part of that. It can even use some extra logic to detect when a curve can no longer be followed and the max speed is desired anyway. No scriptplayer can does this reliably on the fly as everything is always delayed by the connection.
So a protocol change would indeed be needed, but do not thing that this is excessively difficult either (only its initial step would be). Firmware can be designed to handle this. For example, lets say the handy normaly expects full file uploads. Firmware now changed it so it can accept an emtpy script (but instead contains metadata), this metadata then can give feedback on which features are usable, its limitations etc. Or just ask for a certain version of a file. There is a massive amount of freedom as there is no true standard.
The hardest step is to make sure that unupdated devices can give the feedback it doesnt work reliably, so the program can fall back to an older version automaticly. Once the protocol includes a firmware version/script version that it can handle, programs can already act on that.
Its not like USB where due to global and excessive usage standards are a lot more strict. The current devices are still mostly driven by reading a file and loading it internaly. And this same behaviour makes it very much possible to add in extra handling.
Well I would hope that future devices will have better motors the launch, and better api than the handy.
I wouldnt make everything for the lowest common denominator device because we will be stuck with super simplified funscripts forever. Current scripts lack any acceleration and are just triangle waves.
Adding many points to achieve a smooth curve is currently just a solution to funscript limitation.
Thats why I suggested using tangents instead, because then you can send positions and tangents to the device and it can perform smooth moves, instead of having to send small linear steps. Kinda like spline moves (G5) in gcode.
Only problem is that all devices would have to support this kind of moves, but scripter software could save two versions of the script, one with tangents, and one where the splines are sampled to linear steps.
I think you’re overestimating the differences between that initial script and the smoothed version. The character of the strokes are going to feel the same. It’s still a relatively slow rise followed by a comparatively rapid drop. You’re not going to notice the subtle differences beyond possibly feeling a slightly less jarring change in direction at the top.
Maybe you cant tell on the handy or launch, but personally on OSR the more defined the script it the better.
The script just has more character and is more interesting by having varying acceleration than just mindless up-down strokes which I could generate without a script.
MFP with OSR doesnt care about how many points the script has. I have some old scripts that were iirc done in JFS that have 333 commands per second and are like 5-8MB. Works perfectly fine.
I think tangents are a great idea. It could be made backwards-compatible by adding the tangents as a separate array in the funscript, so devices that don’t support custom tangents would just ignore that section of the file. It would also give even current-gen devices some idea of the ‘intent’ of the curve and would probably eliminate the jerkiness problem.
The point of the person I replied to was that algorithmic smoothing changed the nature of the stroke, reducing the desired effect. I replied that I don’t think it does.
I use an OSR2 with spline smoothing because it’s better, and it doesn’t alter the nature of the stroke (e.g. slow upstroke followed by fast downstroke).
Near as I can tell, your reply doesn’t address either position.
The interpolation we are talking about is not an overall smoothing algorithm you apply to the entire script. But rather, a command sent to the software / firmware that indicates the curve used for the upcoming stroke.
For general smoothing, spline would do a decent job. But for building curved strokes, there exists more than a single method. When scripting videos, these different curves can be used to match the dynamic of strokes represented in the video, and could largely enhance the experience if used correctly and artistically.
Here’s some scripts by @99DM, see how different curves are used strategically to match motions in the video.
These are scripted for the Handy under wifi connection, and the nuances are already noticeable. For a stroker like OSR2/SR6, no way it will feel indifferent to triangular waves.
With what we have now, the curves are manually plotted out by adding in extra actions. They are incompatible with devices that uses Bluetooth connection such as Launch / A10 Piston and will feel horribly off. This spawns a script compatibility issue. As a result, 99DM had to make a “simple” version of the same script consisting triangular waves only.
Therefore I see the need for a more elegant solution to these curved strokes. Not only does that allows fallback compatibility (so we don’t have to keep duplicates of scripts), and it could potentially be more efficient, with greater tolerance on transmission frequency. Maybe BLE is quite capable afterall and companies will have no reason to bin it?
Eh, why does it matter that the script will be 100kb bigger. But I guess you could also use m0/m1, and it will be more mathy.
Depending on the script layout and the interpolation type used yes it can change the stroke:
Unless you are looking at it at super basic level, then yes, an up stroke will be followed by a down stroke.
Yea IMO the tangent data added to each script point is the solution.
So we just need:
Decide on the format, like property names, which spline to use, maybe the script could specify the spline type?, maybe each point could use different spline type? etc.
New TCode version with spline moves
New OSR/SR6 firmware which supports spline moves
OFS needs to rework the whole script editor to support in/out tangent handles at each point
Script players need to add support for it
Script creators need to use it, and it will probably increase script time by 50%-100% since you cant go frame by frame
On that last point, maybe OFS could have a spline point fit option, that way you could convert old scripts to spline ones, and you could script frame by frame and then convert it to spline after.
Another solution is to just script very detailed scripts with a lot of points and ignore anything that uses BLE.
Pls no.
Even with spline support scripts might have to add points close together to get the desired curve.
BLE is useless for anything real time related. At minimum it needs some full power modern bluetooth version made for high frequency data transfer. But ideally it should be wifi or usb.
Right. I thought about this after making the previois post.
In the example script there also exists other small actions such as vibrations at the bottom. Even if BLE devices can handle curve movements on their end, these vibrations will still be messed up. (I don’t think their manufacturers will issue a firmware update just for the curves either)
There’s another possible solution, if people would not like to go through the hassles of implementing tangents (and most importantly, start using it).
Like quickfix said - to have some sort of simplify function built in script players. So any complex scripts can be converted into simple ones with peaks only, thus run smoothly on BLE devices.
OFS already has a simplify (Ramer-Douglas-Peucker algorithm) function built in. However it’s not very accessible for an end user who’s not familiar to scripting.
@defucilis Do you think it would be plausible to have such a feature in Funscript.io as well?
Just a friendly reminder here: you don’t have to add those points manually. You can use My Tools extension for OFS to make it semi-automatic. Here is the result that can be adjusted as you wish:
It’s pretty simple, I guess someone could create lua script to make it one step process, but it’s still faster than adding points manually for longer parts of the script:
Select desired part of the script
Add actions - 3
Select middle x2
Delete
Select the same part of the script
Select middle
Select top
Scale - STEP by STEP:
Start: 40% (you can adjust it to your taste, make sure it’s the same as end value)
End: 40%
Step: 5
Scale from 100: selected
Min travel: 0
Select the same part of the script
Select middle
Select bottom
Scale - STEP by STEP:
Start: 40% (you can adjust it to your taste, make sure it’s the same as end value)
End: 40%
Step: 5
Scale from 0: selected
Min travel: 0
I guess it’s not ideal and probably won’t work in some cases, but you could see if it helps a bit at least.
My good idea is to add a ramp attribute to the action of Funscript, in addition to the at and pos attributes. Ramp can be a complex animation function such as cos, sin and so on, but this requires MFP and similar software to work together, and also requires the script writer to be very familiar with various animation functions
Pop in to say that it’s been one year and I’ve found my way to approach this subject. In short, only add intermediate points when needing to represent a noticeable speed change. Also, prioritize compatibility.
There is a problem with Makima interpolation, where two equally high points can cause overshoot. In addition, the animation curve is complex, use tangent is elegant. Increasing two attribute values will increase the file capacity slightly, but it is definitely less than manual interpolation
I’ve been working on a custom OFS build that has full spline support.
Can be tracked on feature/funscript2 branch.
Builds can be checked here: Workflow runs · Yoooi0/OFS · GitHub
To edit tangents/weights you have to select one point and enable View -> Action editor
There have also been talks about having full spline moves in OSR/SR firmware. If they get added they should allow for really smooth motion without having to interpolate the script at 333hz.
But it remains to be seen if this is a feasible to use, and what helpers need to be added to OFS for faster scripting.
Did not read all posts but I think interpolation seldomly happens on both sides of the curve. Motion is mostly stopped abruptly, by direction change or bumping into something. I think that does not have to be interpolated as the change is very fast. On the other hand there are intermittent delaying motion like twist or just big mass movement and then delayed acceleration. Delayed acceleration has to be interpolated.
Was just making a script and I had to add interpolation but could not add it always. Sometimes the direction change was sudden, like foreseen and by choice (not interpolated), sometimes passive delayed acceleration (interpolated).
