[free DL] Snowglobe -HYPE with PhysicsJS, MatterJS and GSAP

knowledgebase

(Lucky) #1

Hey guys,

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]

PhysicsJS version
http://www.luckyde.com/ipad/subaru/physics/
subaru_v2-physicsjs.zip (317.1 KB)
(you can up the snow count to hundreds, i just had it set to low so it works in our QA)

MatterJS version
http://www.luckyde.com/ipad/subaru/matter/
subaru_v3-matterjs.zip (315.3 KB)

GSAP
http://www.luckyde.com/ipad/subaru/gsap/
subaru_v4-gsap-bare.zip (327.8 KB)

Unfortunately the GSAP file won’t have the library because it’s pay for but the scripts attaching to it are still there :smile:

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)

Anyway enjoy!


#2

It’s disappointing that matter.js didn’t do better in performance, flexibility or ease of use. Although, there was a massive update recently.


(Jonathan Deutsch) #3

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.


(Lucky) #4

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 :frowning:


(Lucky) #5

Yeah that’s the one I used, not much performance difference I’m afraid


(Jonathan Deutsch) #6

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.