First of all, I love playcanvas and the community, and ofc the dev team behind it!
i think its quite clear that the physics intengrated in this engine just doesnt really work, especially if there are a lot of rigidbodies, or if rigidbody.teleport is being called on a number of rigidbodies.
If the rigidbody collides with a triangle on a mesh collider, it also just falls through. It surely is unnacceptable and we cant honestly expect many complicated games to come out of this.
I get that p2.js has been suggested in the past but again a 2d physics engine(even if it is playing out on a x and z axis) cannot really do everything we need it to.
At this point I am stuck with moving away from ammo and onto oimo or something similar, this again is not ideal since as game developers we don’t want to keep building every single frame work while the world outside is moving forward with better games and more tech.
I will however say that it is CLOSE. Just need some real solutions, if oimo.js is it, then so be it, but where are the plugins or documentations based around how this externally integrated physics would work ?
I’ve done some basic benchmarking a while ago between ammo.js, oimo.js and cannon.js with lots of rigid bodies and they all suffer in performance at around the same number of rigid bodies in a scene (lots of 1m cubes).
The main problem is this is still being ran on a single thread. The physics could be ran on a web worker, taking advantage of multi core processors and I think it is now widely supported.
I haven’t yet come across this issue. Is either body moving at high speed? If so, it would be worth enabling CCD on the fast moving object so it doesn’t go through another body.
I’ve done some basic benchmarking a while ago between ammo.js, oimo.js and cannon.js with lots of rigid bodies and they all suffer in performance at around the same number of rigid bodies in a scene (lots of 1m cubes).
Do you have any projects with this Benchmarking? Would be interesting to see in general how to attach playcanvas to another physics engine apart from ammo.
I haven’t yet come across this issue. Is either body moving at high speed? If so, it would be worth enabling CCD on the fast moving object so it doesn’t go through another body.
Yes this is a rigidbody moving towards and colliding into part of a terrain for example. Its been mentioned a few times in numerous threads. The suggestion in the past has been to further edit the model to cater to this but cant always do that especially in generated terrains.
Would other physics libs have the same issue?
We can. We just haven’t got around to it yet. It’s quite a significant job to implement that. Before that, I’d probably add support for the WASM build of Ammo:
You’re welcome to, yes, that’d be great. I guess the main thread would just have to communicate instructions to the worker (set gravity, create rigidbody, set mass, etc) and the worker would have to send the simulation state back to the main thread every frame (updated transforms).
For us to update to use WASM, we’d have to change how published apps load Ammo - in other words, we’d have to update the Editor as well as the Engine.
PhysX is a really good option, and I feel we should try it out. And it’s not entirely open source, like something with the MIT license - copyright of NVIDIA must still be mentioned explicitly(https://github.com/NVIDIAGameWorks/PhysX).