I’m using a single worker for native AmmoJS physics. I’ve chosen to do so, to separate the render loop from the physics loop, in case I need a more dynamic world down the line, in which case I’ll need all the performance possible. A worker is indeed nice to not block the render thread, but does come with some drawbacks. One is of course the added complexity of the code, since you need your physics to run independably of the rest of your world, and therefor have to keep track of both visible meshes, and their corresponding physics bodies.
Another, and possibly the biggest issue is, that the communication between the main thread and the worker thread isn’t quite real-time. I’ve messaged BitOfGold about this issue on the old forum, since I read that he implemented worker-physics as well. Whenever I try to measure message-delivery-time, it seems to work at a steady 16ms, however, updating the meshes with new information still seems jittery. His conclusion was that some kind of buffering happens to the messages. I’m simply using setTimeout or setInterval on the worker thread to step the physics, and then send the updated state to the main thread.
SharedArrayBuffers are slowly coming back: Can I use... Support tables for HTML5, CSS3, etc
This doesn’t prevent the jitter completely for some reason unknown to me, but it makes it less noticeable. All you can do to smooth it out, is interpolate some amount. This has the disadvantage of making the simulation seem a bit less accurate, depending on interpolation amount.
So when you create your worker, check:
If SharedArrayBuffer is supported, use it.
if not, check if transferable arrays are supported, if they are, use them.
if not, use postMessage with object cloning.