search

chandlerprall / Physijs

Physics plugin for Three.js
MIT License
2.77k stars 455 forks source link

Support for all Cannon.js functionality #250

Open nmai opened 9 years ago

nmai commented 9 years ago

Cannon.js has certain features like the RaycastVehicle helper class which cannot be accessed through Physijs. I think everything the library has to offer should be exposed through Physijs.

The Cannon branch doesn't seem to get too much love, so I'd totally be willing to implement this and submit a PR sometime. I've actually started working on this already but all my changes are just direct edits to the lib file I'm using in another project.

Let me know if you'd be OK with this.

gmaliandi commented 9 years ago

I would certainly love seeing the Cannon.js branch get more attention. Actually, I'm evaluating using that branch and in that case I might also contribute if I find something cool to do :)

The question would be: is the Cannon.js branch just an experiment that got dismissed? If so, why? Did it turn out not to be a good idea for any particular reason?

(My motivation for potentially using Cannon.js is that I strongly prefer native JS over stuff compiled with emscripten, and also that the examples using Ammo crash in Android Chrome, and I imagine with Cannon it might work OK.)

nmai commented 9 years ago

My motivation for potentially using Cannon.js is that I strongly prefer native JS over stuff compiled with emscripten, and also that the examples using Ammo crash in Android Chrome, and I imagine with Cannon it might work OK.

Precisely why I picked Cannon as well. Yeah, it doesn't offer everything Ammo.js offers but it's simple, easy to use, and performant which is everything I am looking for.

The following is unrelated to this issue specifically, but the physijs-cannon branch does need to be updated as it is calling certain deprecated functions. Furthermore, there is a nasty bug that I'm running into regarding the Physijs worker's "chunk" system in reporting. I was able to work around this but as for finding a true solution, I am totally lost. I'll open up separate issues to address all these bugs but I just thought you should be aware of this before you start using the Cannon branch, @gmaliandi

chandlerprall commented 9 years ago

About two and a half years ago I started Goblin Physics for this reason, to be the new engine behind Physics v2. At the time Cannon was missing a lot of its functionality and there wasn't much development going on. Since then both Goblin and Cannon have kinda raced to be a full-fledged engine. Turns out it takes a long time to write a physics engine. It's now time to start on version 2 of Physijs, which will be a complete rewrite (while maintaining the same easy-to-use API. If anyone is interested in helping with that I'll be creating a road map on the Physijs wiki soon. Also, if anyone wants to contribute to Goblin I'm more than happy to introduce you to the codebase and help you get started, remaining problems range from algorithms to data structures to calculus.

nmai commented 9 years ago

@chandlerprall Interesting- I saw the v2 branch of Physijs but it doesn't seem to have been worked on in a long time. I'm definitely curious to know more about your plans for v2. Are you planning on dropping ammo/cannon entirely for tight integration with Goblin, or are you trying to take a more engine-agnostic approach? And I'd be totally willing to help with both projects, I just need a little direction.

chandlerprall commented 9 years ago

The original goal of Physijs was to allow any engine to run. However, for a few reasons I don't believe this is really a great solution. Without a tighter coupling you lose performance optimizations you could otherwise have, and it's much much harder to debug issues.

nmai commented 9 years ago

Sure, and if you try to offer a single API layer over multiple engines you run into issues like this one. Some of the unique features of these engines are overlooked (and made inaccessible) simply because other engine options don't have anything similar.