Physics in WebWorker

Demos and projects
1

Happy Martin Luther King Jr. Day! :smiley:

Source Code: docs.zip (3.6 MB)

The demo above is trying to compare 3 physics implementations:

  • Pure Babylon implementation using PhysicsImpostor, AmmoJSPlugin, and other Babylon API’s
  • Separated physics script (not nearly as comprehensive as Babylon’s API) running in a WebWorker
  • Separated physics script running in the main thread (no WebWorker)

This was inspired by @RaananW 's article, @yannick 's video demo, @Raggar 's Playground, and more!

Comparisons (1000 physics boxes):

1. Pure Babylon:

14 FPS, Physics step compute time: 16.6 ms

Screenshot (1854)
Screenshot (1854)2553×1300 214 KB

2. Separated Physics (No WebWorker):

74 FPS, Physics step compute time: 12.1 ms

Screenshot (1855)
Screenshot (1855)2554×1297 195 KB

3. Separated Physics (WebWorker):

199 FPS, Physics step compute time: 22.0 ms

Screenshot (1860)
Screenshot (1860)2554×1298 200 KB

Using physics in a WebWorker can give high FPS, but seems to be unstable. As mentioned by @sebavan, @Cedric, and @Raggar in Using web workers for the physics, world and networking?, Running physics in a webworker, and Questions on Updating Heightmap Physics Impostor - #3 by Cedric, there seems to be a delay in the messages between the main thread and the worker (which grows over time as more and more messages are sent). This may be related to the high 22 ms physics step compute time, which gradually grew from 12 ms and stabilized at 22 ms. Also, triggering events (e.g. mouse click and drag events) seems to temporarily block worker messages, causing visual pauses in the physics

We could maybe improve the stability of the worker solution by limiting the number of messages. Currently, assuming 200 FPS, 200 messages are sent to the worker per second. ~60 messages (with data about the 1000 physics boxes) are sent from the worker per second regardless of FPS. This may be too much data being transferred

For an interactive, real-time game, perhaps physics in a WebWorker is currently not ideal. But, if you want to just display many physics objects at a crazy high FPS, maybe it’s worth looking into :slight_smile:

13 Likes
2

I love it :slight_smile:

1 Like
3

That is really nice experiment. Thanks for sharing it @gbz

1 Like
4

I really like this, thank you for taking to time to research this topic.

1 Like
5

I got same 48fps for all 3 playgrounds

#1. Pure Babylon implementation with no Web Worker
Pros: Feature-rich and stable physics with decent step compute time, simple development
Cons: Low FPS* No Worker (Babylon)

#2. Custom physics with no Web Worker
Pros: Fastest physics step compute time with decent FPS
Cons: Far less physics features compared to Babylon, not as simple development* No Worker

#3. Custom physics with Web Worker using postMessage and onMessage
Pros: High FPS
Cons: Same as #2 + unstable physics (slows down with time), thread communication overflow (blocking events), difficult development (coordinating render and physics objects in different threads)* Worker

6

@HiteshSahu could you please share which type of device and browser you were using? Thanks!

7

I trie don Google chrome on WIndows 10 Laptop

8

Thanks, @HiteshSahu! I can try looking into this. I’m also using a Windows 10 laptop and Chrome/Edge. I noticed that when my laptop isn’t charging, it goes into performance mode causing FPS to decrease and fluctuate, so maybe this is related

It makes sense that some demos may run at 48 FPS on certain machines. But, it’s strange how the 3 demos listed are all running at the same 48 FPS on your machine, since the worker demos are doing far less computation in the render loop. So, I would expect the FPS of the worker and non-worker demos to be different, but maybe there is something that needs to be fixed in my implementation

9

image
image1920×1032 266 KB

1 Like
11

Here is a demo I had created a while ago can you try to export it to webworker.