PDA

View Full Version : remapping values with ease...


3rd Dimentia
04-18-2012, 02:14 PM
I've always wondered what are the economical ways to remap values between 0 and 1 with an equation so that you can control ease-in ease-out like you can with bezier controllers. I've used quadratic equations before, but they seem to be quite slow. Anyone got any tips on good ways to do this? Even just the name of an equation that I can research?

3rd Dimentia
04-18-2012, 02:32 PM
Here's some I've figured out with trig

ease Out-In
((1-(sin ((1-theVal)*90)))*(1-theVal)) + ((sin ((theVal)*90))*(theVal))

ease In
sin ((theVal)*90)

ease Out
(1-(sin ((1-theVal)*90)))

Are there more economical ways to do this kind of thing?

denisT
04-18-2012, 02:40 PM
when you say slow what do mean by its performance? where do use it? could you give a sample?

3rd Dimentia
04-18-2012, 02:43 PM
I'm really tired right now (heading up to 1am here) so I'll dig one out tomorrow. I just remember adding it (quadraric) to a single script controller in a scene and it seemed to slow the scene down dramatically. I can't remember what it was as it was years ago but I'm sure I can find a file somewhere that has it implemented.

Cheers,

Cg.

denisT
04-18-2012, 02:48 PM
well... using SIN is:

fn easyINNOUT x = (sin (180*x - 90) + 1)/2


but i'm using TRUE Bezier. It helps me control IN/OUT values

i think that PURE sin is going too slow.

denisT
04-18-2012, 03:02 PM
i think that PURE sin is going too slow.
but you can use another degree segment to make in-out faster. like:

fn easyINNOUT x angle:90 = (sin(angle*(2*x-1))/sin(angle) + 1)/2

3rd Dimentia
04-18-2012, 11:33 PM
This is the old way I've done it in the past that seemed to slow rigs down. It turns out it was a cubic bezier equation rather than quadratic. I've not done any speed tests yet (but I will later today when I get a chance), but this it.


p0 = 0.0
p1 = 0.0
p2 = 1.0
p3 = 1.0

finalresult = p0*(pow(1-t)3)+3*p1*t*(pow(1-t)2)+3*p2*(pow t 2)*(1-t) + p3*(pow t 3)

denisT
04-19-2012, 03:15 AM
This is the old way I've done it in the past that seemed to slow rigs down. It turns out it was a cubic bezier equation rather than quadratic. I've not done any speed tests yet (but I will later today when I get a chance), but this it.


p0 = 0.0
p1 = 0.0
p2 = 1.0
p3 = 1.0

finalresult = p0*(pow(1-t)3)+3*p1*t*(pow(1-t)2)+3*p2*(pow t 2)*(1-t) + p3*(pow t 3)

that's exact bezier interpolation... it's not slow. it's almost nothing for any expression. that's what i'm using.

PiXeL_MoNKeY
04-19-2012, 04:44 AM
A whole list of easing functions can be found in this (http://forums.cgsociety.org/showpost.php?p=4334220&postcount=31) post. Now the question is how did you compare speed? Could it be something else like comparing a bezier (or other) controller to a script controller that is really causing the slow down?

-Eric

3rd Dimentia
04-19-2012, 06:36 AM
Pixel Monkey, I haven't actually done a side by side comparison of any of these. The speed issue that I was having was a few years ago when I implemented the cubic bezier equation to remap a range of linear values to easein-easeout on a rig. Which then started to slow down dramatically. Maybe that was just the tipping point rather than the actual cause. This is though, how I came to the conclusion that it might be an uneconomical way to do things. I don't have a math/coding background at all, hell I didn't even finish highschool so I thought I'd ask some more educated peeps on here.

Cheers,

Cg.

denisT
04-19-2012, 01:33 PM
I've checked the performance of Bezier interpolation function. As I said it's fast enough to be used in any expression. 10000 calls take 50 msec (0.050 sec) and not use memory at all.

3rd Dimentia
04-19-2012, 01:57 PM
Great, thanks for all your replies.

Cg.

3rd Dimentia
04-20-2012, 04:11 AM
I just did a speed comparison over 10001 iterations between the cubic bezier and the sin ease that I hacked together and found that the cubic bezier was over 40% slower. I don't know if I'm not doing something correctly, but here is the code and my output

(
startTime = timeStamp()
for theVal = 0.0 to 1.0 by .00001 do ((1-(sin ((1-theVal)*90)))*(1-theVal)) + ((sin ((theVal)*90))*(theVal))
format "sin ease:%\n"(timeStamp()-startTime)

startTime = timeStamp()
for theVal = 0.0 to 1.0 by .00001 do 0.0*(pow(1-theVal)3)+3*0.0*theVal*(pow(1-theVal)2)+3*1.0*(pow theVal 2)*(1-theVal) + 1.0*(pow theVal 3)
format "cubicBezier ease:%\n"(timeStamp()-startTime)
)


sin ease:292
cubicBezier ease:517

denisT
04-20-2012, 05:12 AM
that's correct ... but you make 100,001 calls. so the result is exactly as mine. do you not trust me? :)

well... we have 10,000 calls for 0.05 seconds. what does it mean? if we play an animation in real time we need 30 frames per second (or 1 frame per 1/30 sec) . this time we can do more then 1500 bezier calls... if we will do 100 calls (which means 100 expressions in our scene) the bezier interpolation will take less then 7% of our performance. is it slow? no!
so it's not a subject that you should care about.

3rd Dimentia
04-20-2012, 05:59 AM
Haha. Denis you are a funny guy. Of course I trust you. Well sorta. ;)

I did the speed comparison test cause I said I was going to and I was curious.

Oh how can you say that speed improvements aren't something we should worry about? Even if they are so negligible. That's not the Dennis that we know and love. Always striving for better more economical results with less code.

As well as being faster than cubic bezier with my hacked sin code, it's less typing. ;P

Have a good weekend,

Cg.

CGTalk Moderation
04-20-2012, 05:59 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.