Are webworkers a must?

Help & Support
1

Generally the last 12 months ive spent developing on Playcanvas i’ve gone from strength to strength but when it came to combining all of my very essential real-time systems ( modifying character spine in update, modifying character skeleton in update, modifying animations in update, weapons systems, terrain, and ofcourse the physics as well ) i’ve found that my game is now affected by slow physics.
Not only this but added things like the Tiled Terrain Manager and so on, it really feels like i’m running out of capacity to run my game well even on a desktop.

It was my impression that I could build a proper game in Playcanvas but have gradually become aware that it is still in its infancy.

Some questions :
Are web workers the answer to my pains ? Should i offload all of this performance heavy aspects on a web worker?

Would this work with the editor version of Playcanvas?

2

I can’t say anything about PlayCanvas and web workers but one thing I found imperative to implement in mid to large sized projects is async update loops. This isn’t PlayCanvas specific but in most of the demanding 3D apps is something you should be looking to.

Normally all of your script update functions will run per frame. Running everything per frame might be an overkill in many cases, e.g.:

  • you can get away with updating UI values 2-3 times/second.
  • calculate your fog of war once per second.
  • distance checking between camera/player/objects depending on the case.

On the tiled terrain manager you can find this kind of a loop on the terrain generate method, where I create each chunk per frame to avoid hanging the main thread for long.

So find your frame budget and profile/time all your methods to come close to your target framerate (16-32ms for 60/30 fps).

Hope this helps!

3

Updating and calculating is a drop in a bucket of frame cycle.
I don’t think you can achieve a real performance boost because of that.

The bottleneck is render and physics, ordinarily.

I tried to make physics working on webWorker. It was great, but there are a lot of things I had to implement and I faced with some problems.

But still, I had a very efficient physics usage. My render didn’t relate on it and was smooth even with freezing physics.

4

When it comes to that magical 16ms per frame to get a smooth 60fps everything counts.

Always profile, profile, profile all your code. Don’t depend on Javascript being fast because it is just calculus.

Check this procedural stars/solar systems generator. Obviously rendering isn’t the bottleneck … but even updating the billboards (star flare) has to be done in intervals and not per frame to achieve semi-decent performance:

3 Likes