Cheeky movementFactor

Rick in this video made the:

movementFactor = (rawSinWave + 1) / 2f;

just for a much cleaner from 0 to 1 instead of -1 to 1, and until here all good and dandy, but he did not mention that it will also behave properly, bacause if you do instead:

movementFactor = rawSinWave;

the block will behave differently with a much longer movement and because with Rick’s code we basically halve the rawSinwave, kinda make sense…

Until i noticed that with Rick’s code, the block movement move exactly how we set it up at the beginning, instead of maybe something less…

So, why is this the case?

This is where my non math brain starts farting, and probably Rick knew it was something too fancy to explain this early in course, since we have to start dealing with the understanding of Cycles.

But still…if some Galactic math brain will come in rescue, i will be very glad to ear why is that.

The only thing Rick did was to remove the need to slide the movementFactor slider by hand and let the code do it. The value we get is still between 0 and 1 just like it was when we initially did it by hand. We did not really halve the rawSineWave, we just reduced its amplitude (I think - probably some loose interpretation of it on my part) from 2 to 1.
With the slider we had a value between 0 and 1, but the rawSineWave is between -1 and 1. So, Rick adds 1 to it and now it’s between 0 and 2, and then he divides by 2 making it go from 0 to 1 - matching what we got from the slider.

We turned this


Into this

2 Likes

Yeah after we deleted the slider in the inspector i totally forgot about it…damn ADHD it’s the worse

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms