I agree I see nothing bad on bjs side, the fact that cpu is more used when there is more activity / meshes.
Here is my test:
All of this is expected. Maybe you could reduce the load by not using PBR materials but this is not the root of your problem
Honestly, the only think I could think about is slowly removing features until you find what is causing the lag (that I do not feel in my case)
I do not see spikes:
Another thought
If you’re seeing these CPU spikes while locally testing multiplayer
I definitely see that in my game too, but I think it’s just the computer getting slow from rendering multiple copies of the game at once, in addition to the server and VSCode etc
So I would check if it feels slow between multiple players on different computers. It’s especially bad in my case when it’s Firefox and Chrome instead of two different Chrome versions
I will try each of your recommendations and see if they help.
And it isn’t because of local testing. Users on the live version experience the lag as well.
Hmm. There are some users who don’t experience the lag and some take some time before it starts happening, so that could also be part of it. But anyways, I appreciate your help. I’ll let y’all know if I can figure anything out.
Wow, so I’m starting to think this is a Chrome issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=600385
These are with the mousedown event, but they have similar effects.
It sounds like ondrag, onmousemove, and onmousedown each call RequestAnimationFrame (apparently people with higher refresh rates are more likely to experience the bug for this reason), which in turn somehow block the websocket packets.
What if you try using a passive event listener and do it on a parent element that’s not the canvas
