Particle physics overloading the browser (Chrome)


#1

I am making a collision in Hype using physics:

One element (an image turned into a static physics object) collides with a bunch of particles (a small picture of a circle copy and pasted several times and made into dynamic physics objects). Think of a train hitting a bunch of rocks, seen from the top. Here’s the file: CollisionAndParticleTest.zip (70.9 KB)

There are about 206 particles. The browser (Chrome) does not play the animation. If I erase a good amount of the particles then the animation plays. Sometimes it stagnates and plays slowly. The less particles the better the animation plays.

Is there a limit to amount of particles the browser can process?
Is there a way to minimize the load on the browser or processor so that it can handle a high number of particles? Thanks!


(Mark Hunte) #2

Good question.
But it is not just Chrome.

Try and replace the ball images with Ellipses and you may still need to cut down on numbers.
My tests show a combination of both improved the animation speed.

Hopefully someone will have a better idea …


(𝕄𝕚𝕔𝕙𝕒𝕖𝕝 𝔾𝕒𝕣𝕠𝕗𝕒𝕝𝕠) #3

I’m busy with the Hype book project, so I was only able to look at the project briefly. It looks like your particles are using the “Dynamic” physics setting. That’s basically a heavy element. It’s using a lot of physics processing. Typically, particles are light-weight actors, so that they don’t slow down.

Basically, it looks like there are too many heavy actors.

I’m not sure what you could do to easily fix this problem. It’s why I’ve been posting so much on the Physics API thread. Hype is really close to game development software, but it needs to tap into the matter.js API.


(Jonathan Deutsch) #4

By my count there’s 560 dynamic bodies in that document, which is a lot. Unfortunately the performance for physics scales exponentially because each body needs to calculate if it is colliding with each other body (to over-simplify things).

One thing to note is that we typically err on the accuracy side for physics. We’ll try to catch up to real time by doing the physics calculations but not rendering for up to 20 steps a cycle if we’re behind - in other words with Physics we may sacrifice the frame rate.

Generally when we were experimenting, we used 50-100 bodies for our upper bound, which worked pretty well. Here’s one of our standard documents, which you’ll find works well on desktop browsers but suffers a bit on mobile:

https://dl.dropboxusercontent.com/spa/jbj423z5m7y8em0/Exports/LotsOfPhysicsObjects/LotsOfPhysicsObjects.html

There’s no specific limits, it is entirely dependent on performance of the hardware/browser.

There’s no simple switches you can do unfortunately.

I haven’t done specific tests myself, but I suspect this would lead to worse performance. The pasted images are rectangular physics bodies which only have 4 vertexes. An Ellipse would have a higher number of vertices to simulate its roundness, so that means more calculations per cycle.

(That said there’s gonna be some browser rendering time in there too, and an image probably requires more general browser effort, but I’d guess 99% of the time is on physics).

I’d agree with this; depending on your particle effect the Physics engine might not be right for you and you’d be better off using a particle engine than phsyics engine.


(Mark Hunte) #5

I did a test where I had about 129 red and 50 yellow. ( I think I kept every thing else the same ) One project with all Ellipse and the other with images.

The Ellipses performed much much better. Here are the two maybe you can tell from them what the main performance hit is.

Archive 2.zip (131.9 KB)


(Mark Hunte) #6

P.S an easy way to get a count is select all the elements and give them the same class.
Then making sure the classname is set, Select and copy the elements.

Open up TextEdit and in a new plain text document, paste .

now do a search for the classname.