rotateZ simulation animates invalid values about popmotion HOT 2 CLOSED

That's interesting. First of all I suspect I need to round output values to
three decimal places to avoid invalid numbers like that.

I've had a quick play on my iPhone and you need to explicitly set watch to
undefined on the Spring simulation. I'm guessing what it's doing is passing
rotateZ to the internal Watch action instead of Simulate, hence explicitly
removing 'x'

It's not a pretty solution so I'll look into unsetting this automatically.
Thanks for pointing this out.

Also there's something very satisfying about that spring back on a touch
device!

On Sat, 3 Oct 2015 at 20:01, Chris Malven [email protected] wrote:

This could be a bug and it could just be a misunderstanding of pop motion
on my part.

I've put together a simple test case to demonstrate the issue here:
http://codepen.io/cmalven/pen/dYvevW?editors=001

When the rectangle is dragged, I'm using a track to apply the x value to
rotateZ, then using a simulation to spring back the rotateZ when the
mouse is released.

The x-based rotation on drag works fine, but when I release the mouse
button the rotateZ value just snaps back into place without applying the
spring simulation.

Examining the rotateZ values generated during the simulation suggest why
this might not be working: they quickly become invalid values like rotateZ:
"-7.450580596923828e-7deg"

Any ideas?

—
Reply to this email directly or view it on GitHub
#79.

from popmotion.

Thanks, @InventingWithMonster, watch: undefined worked like a charm, though I'd agree that it's a little strange.

And yeah, the spring interaction feels great on a touch device. :-)

from popmotion.