12
\$\begingroup\$

A bit related to this question.

The idea is to guarantee the same physics behavior as much as possible. Would it be possible to run fixed time step physics on a web worker? The UI would update itself with different/variable refresh rate.

Has anyone tried such yet?

|improve this question
\$\endgroup\$
  • \$\begingroup\$ What do you presume to gain by using a web worker? So far my answer would be, that'll work, but why bother? \$\endgroup\$ – aaaaaaaaaaaa Oct 25 '11 at 20:39
3
\$\begingroup\$

I found this experiment. It runs Box2d physics on a web worker. I haven't yet checked in the detail how it gets around issues mentioned in Vincent Scheib's comments.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Good experiment. I've been following these types of projects too. Unfortunately, most are still tied to Java/C. I believe that OP is looking for a way to pull this off natively in the browser (no plugins). \$\endgroup\$ – Kevin Peno May 11 '11 at 15:24
  • 2
    \$\begingroup\$ Article about the same by a google guy: t.co/AuhPptB \$\endgroup\$ – sorenbs Sep 9 '11 at 21:47
2
\$\begingroup\$

This could work, however WebWorkers follow the observer pattern, the document (html page that owns the worker) can only listen and post messages to/from a worker. From that, there's a few options, I guess. In all cases I think you will need to find someway to determine the optimal FPS of the user agent in order to optimize the information. Then you could either:

  • Tell the workers to post messages at those time intervals
    • Downside(s?): you have to assume that the document will be ready for the response when it happens.
  • Tell the document to send a message to the worker requesting physics at time interval x, then the worker would post a response (hopefully) shortly after that.
    • Downside(s?): since all posts and responses are asyncronous, there may be delays between the request and response from the worker. In this case you would also have to null out the onmessage event to prevent your document from listening when it doesn't expect to be.

I'm sure there's other things I missed or ways to handle communications as well. I'll be looking forward to other answers on the subject myself!

|improve this answer
\$\endgroup\$
  • 1
    \$\begingroup\$ a) Caution regarding performance! Consider requestAnimationFrame and signal a 'keep alive' to your worker from it, so that you don't burn CPU if the tab is placed in the background (perhaps for too long) \$\endgroup\$ – Vincent Scheib May 10 '11 at 3:23
  • \$\begingroup\$ b) IIRC All messages from the worker will be received on the main thread, they'll queue up. Think about what impact that will have on your main thread, if you got 5 updates but only need the latest. You also can't tell that you have more coming. \$\endgroup\$ – Vincent Scheib May 10 '11 at 3:27
  • \$\begingroup\$ c) All messages are making copies of data. The more data you have to send between threads the more data copying and garbage collection work. So, a win here will only exist if there is a high computation / message data ratio. \$\endgroup\$ – Vincent Scheib May 10 '11 at 3:29
  • \$\begingroup\$ @Vincent, regarding B) that's why I said that you would either need to have document always ready by finding a reasonable fps or go with option 2 where the worker does nothing until document asks for it. \$\endgroup\$ – Kevin Peno May 10 '11 at 20:59
2
\$\begingroup\$

Physijs uses a web worker. It glues together ammojs physics with Three.js objects and updates them as need be. It features both fixed and fluid time steps, I believe

|improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.