This is the accelerating/decelerating transition effects capability.
Usage:
When “Bend” Time is less than 32768 the transition will start fast and decelerate at the end, when it is above 32768 it will start slow and accelerate to the end.
You can use IgnitionTime<0>, RetractionTime<0> or WanLen<> to auto time the transition to the sound.
In testing thus far you need longer transition times to show the accel or decel well.
Best bend values to start are either Int<10992> and Int<98304> but you can play with values to adjust accel/decel times.
The BEND values will be editable via Edit Mode and ProffieOS Workbench using below arguments so you will be able to test and adjust on the saber when OS7 releases
having the inflection point at 32768 is kinda confusing. Can you make it zero instead? In other words, positive values are fast then slow, negative values are slow then fast… Also, can the acceleration be position based rather than time based? For example, slow close to the hilt, fast close to the tip, such that on extend it starts slow and finishes fast, but on the retraction it starts fast and finishes slow.
As a future idea, it could be fun to have acceleration intervals, being defined by x equally spaced points along the blade. Each interval could have its own bend factor, and the animation would then follow a spline through those points. Think of a graph, x axis is the position along the blade, and the y axis is the bend factor. Every 10 pixels (for example) gets a point on the graph corresponding to location and bend factor. Draw a cubic spline through those points, and that will be the instantaneous bend value at any point in the blade.
The BEND value is actually converted to an exponent by dividing by 32768 (@profezzorn can probably explain better).
So setting to 32768 is equivalent to the power of 1,
65536 is equivalent to the power of 2 (squared)
16384 is equivalent to power of 1/2, etc.
The “speed” is then calculated based on the current pixel being transitioned along the exponent curve.
Fredrik can give a better explanation but it is 32768 for a reason.
That makes sense. It would be pretty easy to just shift it though. for example suppose the bend is configured to be 0 centered and stored in inputed_bend_value, and the actual bend variable you use for the exponential calculation is calc_bend_value:
in the first case, the actual bend value used for the exponential is 60768. In the second it is 18768. If you wanted, you could even make the input range -1 to 1 just by multiplying. I hope that makes sense.
All of the functions that could be used to determine BEND amount return 0 ~ 32768 already, @profezzorn is better to explain but all Proffie functions are 0 ~ 32768, this is no different.
Hmm. I’m not understanding the limitation I think. I’ll have to get familiar with proffieboard programming sooner or later I suppose. Anyway, this is cool feature to have, regardless.
Fredrik will explain it far better than I can. I’m not a programmer (I just have an overactive imagination and play with code as a hobby
He’s explained it before, there is a reason. In the OS any function BladeAngle<>, TwistAngle<>, SwingSpeed<>, etc always returns 0 ~ 32768 and they can be used to determine BEND in transitions.
Centering the bend at zero would make more sense if it was also symmetric, which it isn’t currently.
The bending uses an exponent in the same way that a gamma curve works on a picture. For gammas, 1.0 is a straight line. 1.5 is bends the line upwards and 0.75 bends the line downwards. The proffieos bend functions works the same way, but using fixed point values, so everything is multiplied by 32768.
If you are familiar with gamma curves, then this should make sense. Is it the best, or most user-friendly way to do it, perhaps not…
