Wanted to share something I did at work over new years, I wanted to do a snowglobe shake effect. I used a bunch of methods but out QA app was really making it chug so I went trough a lot of versions with different engines. They all run fine on android, ios etc, it’s just within our environment they didn’t run so I ended up using GSAP’s pay for physics extension which isn’t really a physics library , but a small collection of scripts to simulate acceleration for div tags.
[Click on the icon to trigger it if you’re on desktop]
Unfortunately the GSAP file won’t have the library because it’s pay for but the scripts attaching to it are still there
But yeah I wanted to share in case anyone is wondering how to work with physics libraries within hype.
I also incorporated Shake.JS and DeviceApi Normaliser. The second because i originally had a way to detect the angle of the tablet so the snow tilts with the tablet. But yeah, lag(just in our app).
For the record
Easiest to use: PhysicsJS
Most Flexible: PhysicsJS
Ran the fastest: GSAP
(but again pseudo physics, does not use canvas)
Interesting to hear your experiences! I started using PhysicsJS as the engine within Hype originally, but ran into some roadblocks (my recollection was mainly about simulation accuracy) and missing features. I switched to Matter.js and was pretty happy with how easy it was for Hype’s runtime to interface with it and the small footprint. Performance wasn’t a primary concern though. I’ll be looking at integrating 0.9 and am curious about the performance differences there.
Well pure performance alone physics won but not by much. I prefeted physics because of the easier to read coding as well as better demonstrated docs. I found myself digging through the matter demo js source code way too much and it was a giant mess of everything it does in one file. Where as physics had clean docs and i could import only the parts i need to use and reduce size. This is just my experience.
Also collision detection was way more responsive in physics as well as the fact that I could do complicated shape collision. And there were more threads about it online. I tried the dom renderer in physics though and it was ridiculously slow in Android.
But with both the longer they ran even with sleep enabled the slower it got. Again this is based on my 2-3 month experience with both. I’m super sad i can’t use either for very interactive things because of the lag.
Oh and matter js completely crashed the digital paper at 2am when they were compiling it. I can only assume it was from the constant running in the background in between 50 pages of assets and code but that’s a guess. We don’t have decompiling tools
Matter.js has the notion of ‘sleeping’ for when objects get into a steady state, but there are plenty of conditions where that doesn’t happen or can’t happen by the nature of the animation. Now that I’ve dived much deeper into physics I’d like to see how PhysicsJS (and other libraries) handle some of the same problems. Sadly it seems the tradeoff is always accuracy vs. performance for physics; knowing a specific purpose for a physics-based animation could help make better tradeoffs but these engines are meant to be as generic as possible. I threw out a few other engines because their simulations weren’t accurate enough. I originally figured for iOS most animators would need to limit to a few physical bodies, but the iPhone 6s is pretty amazing performance wise and I’ve seen ~50 bodies animating at 60fps.
As for Matter being hard to read; I definitely looked at the unbuilt versions where the components were separated out. I know the author is also planning to make it even easier to choose just what parts you may need for an animation.
