Exactly! Well said. Historically, using my bad memory and low knowledge… it all started with Oimo… and Temechon and DeltaKowboy… wrote the first basic plugin. It was a year-long party… because it was big big big. Basic “physics engine API” was established.
Then… perhaps Oimo got another version, and Raanan (and possibly others)… did an Oimo re-factor… added more power… but still tried to mirror the “PE-API” (physics engine API).
Then Cannon came along, and I think some “maintain the pe-api scrambling” had to happen… because there were differences between Oimo and Cannon.
Energy physics engine plugin happened about this time… in history. Many yawned over it, because most of us hadn’t even learned to drive Oimo yet… no time to learn more… barely/no time to write advanced-feature docs.
Now… Ammo… which has much more power… but… in order to fully exercise that power… I think we might need a NEW BJS PhysicsEngine, PhysicsImpostor, PhysicsJoint, etc… things that require LEAVING BEHIND the legacy pe-api. I believe that the current AmmoJsPlugin is still an attempt to mirror the legacy plugin API… and understandably, it can only meet “most” of the criteria to “fit” that.
Writing a new AmmoJsPlugin “system”, which fully exposes all the newest powers of AmmoJS… is quite a task, I imagine. It will need to evolve and have multiple smart contributors… could be a 3-year project to fully flesh. And what IS “fully flesh”. We will ACTUALLY be establishing a “2nd gen” pe-api… upon which many future physics plugin api’s COULD be modeled after. It needs to be sweet, but in doing that… it might need to stay Ammo, even if other more-powerful physics engines come-along.
And of course… maintenance hell.
I once proposed DE-powering all the plugins… just providing a “get a ref to the physics world object” and not much more power. Then make people do native calls to the PE, whichever they were using. No/few helper funcs on the plugins, no BJS-wrapped impostor or joint classes… just make the user talk native from within their code. LOTS less maintenance for the BJS core physics team.
So, where does it go from here? Who knows? I think I have to heartily thank the devvers mentioned earlier… for their excellent work bringing AmmoJSPlugin to life… it’s real nice… including the docs. That is a lot of hard work, done well.
And… oh geez… we should ponder IF/NOT… physics engines will become part of next-gen computer hard/firm ware (PhysX?). Can JS even process the return-values from a hardware-speed physics engine… getting them to the scene impostors fast-enough to benefit from the added speeds?
In short… how much work, and how much features-exposing (such as making soft-bodies easy)… SHOULD be put-into things? If we “wrap” 75% of AmmoJS… so users never/rarely need to make any native calls, will people ever use 50% of that advanced feature exposure?
And maybe the BIGGEST question… Why am I still typing?
Ya know… for GeekTrains… are you going to make the crane-loads “swing” on cables? If not… (straight cables only, yet still need to carefully align loads with flatbed railcars), then I would consider NOT using a physics engine, and faking it all. Perhaps make views from multiple cameras… pop-open… for crane operator, and then just make them cursor-key that puppy into place. Perhaps add a simple inertia system… so the load tends to over-shoot a bit when rotating… and then returns. All your loads could still have mass values… and they affect a few things in your fake-physics loading system.
I’m sure you’ve thought about this. And yes, I’m STILL typing. sigh. Sorry if I’ve side-tracked [sic] the topic.