Just a little demo of using AmmoJS natively while also using the impostor system, as there are no BabylonJS specific features to create vehicles yet, as far as I know.
12 Likes
Beautiful! Thanks R! Pinging @Theodore_Lee cuzzzz… he might be highly-interested in this. 
And I know that Theo will immediately go to work, fleshing the Ammo plugin, de-native-izing this playground.
Sixty days to a Ammo plugin-programmed car? (ahem. No?) 
Nah. But this playground is also an excellent mini-tutorial into the Ammo native tribal lands. Sweet!
2 Likes
This could be added in the Examples page
2 Likes
Hi V. It’s “native”, so maybe not a good (long-term) example. No AmmoJS Plugin is used. I don’t think the brand new AmmoJS plugin… has motors/joints features added, yet.
Perhaps include “Using Native AmmoJS Calls” in the example’s description.
Longer-term, maybe we prefer that our physics examples… are plugin-using.
Main thing, we don’t want users to THINK that the ONLY way to use motors and joints on AmmoJS… is via native calls. That IS true, now… but later… we’ll prefer that MOST/noob physics-users… use the plugin.
By including “Using Native Calls” in the description, it will remind us to update the example… AS the plugin gets more power, in the future.
Concern aired. Party on!
I’m unsure as of how to approach the issue of making this available in the plugin, as AmmoJS, OimoJS, EnergyJS and CannonJS all have different ways and settings to create vehicles. To get the most of it, you’d need access to all the exposed functions and properties of all the engines. Should a vehicle be created based on its visual representation or is the other way around better? You could create a box and four wheel meshes, and then use the positions to calculate the axis positions, or you could use a basic boilerplate to create the vehicle, at the expense of freedom and customization.
In my example, I’m using the chassis shape with an offset to create a compound shape. What this does is creating an artificially low center of mass, in order to stabilize the car and better prevent it from rolling over. This is a technique most racing games use, but how would that translate into the plugin?
Not an easy task.
Yeah, I hear ya.
Can future funcs on the Ammo plugin… such as: makeJoint(), setSpring(), setMotor() etc… be coded VERSATILE enough… to build “The Rag-Wagon”? (with few/no native calls on the user-side)
(Behind the exposed API, LOTS of native calls happen inside all physics plugins, of course. Plumbing.)
I dunno. I think we should give @trevordev a chance to work his magic. The Rag-Wagon is a good benchmark for the Ammo plugin. The Rag Wag.
Raggar, you should help @trevordev write joint code for the Ammo plugin. I just bought a fresh bag of joint-making material! Let’s bake-up some transformations! err.
What’s that you say? Oh, wrong joint type? Ok.
No mention of “joint” in your code… but… close enough.
var tuning = new Ammo.btVehicleTuning();
var rayCaster = new Ammo.btDefaultVehicleRaycaster(physicsWorld);
vehicle = new Ammo.btRaycastVehicle(tuning, body, rayCaster);
Native built-in car generator? hunh. I wonder how “smart” THOSE objects are? (Go dump them to console in Rags’ demo, Wingleberry.) Sigh. API studying. Too many physics engines… we’re going to get a tumor.
Keep in-mind that basic boilerPlates can have a gazillion optional parameters… which makes them very powerful again. Almost everyone hates writing 70-parameter funcs like that, but… {options}… and doNativeCall(whatever)… to the rescue.
Just think about .doNativeCall(method, stuff); That really powers-up a bare-bones plugin. But, it makes noobs go native-digging… sooner. Simply putting monster tires on their Ammo boilerplate car… could require them to AmmoPlugin.doNativeCall(something).
But physics HELPERS… on the forum… could wash their hands of helping users (gently ignore them)… BEYOND doNativeCall(). In other words, “Hey, if you used a doNativeCall() to go digging-around in Ammo native tribal lands… YOU’RE ON YOUR OWN, Grizzly Adams!” (i.e. “See AmmoJS docs website for native stuff… and get off the BJS forum, eh?”)
If users mess-with the natives, they’re ASKING for trouble! heh.
Once upon a time, the plugin builders tried to mirror the API for the Cannon and Oimo plugins. they did quite well. Then I think EnergyJS rolled-thru, and I dunno WHAT state that is in. Limited mirroring of the Oimo/Cannon “mirror”?
AmmoJS is different, right? We have to say goodbye to some of the basic/generic calls, and hello to a richer toolset, right? Not only a richer set of tools, but possibly a different way of doing things. I bet t-Dev is TRYING for some API mirroring of old-style Oimo and Cannon calls… but I suspect that is marginally successful, at best. With Ammo plugin, I think t-dev and other plugin devvers… will need the freedom to fly… without being bound-by strict “mirror the other/older plugins” rules/forces.
In other words… strangely-named func calls/prop names… on the AmmoJS plugin… a-ok and expected. It’s a 3rd generation physics plugin… it’s going to be different. Mirroring other/older plugin API’s… not required (imho). Thoughts, anyone? Enough text for ya’ll? Use big fonts/control-mousewheel… more fun to read.
1 Like
Just to let you know that trevordev added motor to Ammo at beginning of Dec though nothing in docs yet. Holidays slowing down development at the moment.
3 Likes
Thanks for info @JohnK ! Thanks for working motor, @trevordev!
WHO chose to use the paddle wheel demo? That is SO COOL! (to use/show a demo scene that is already part of this topic).
(Wingy dances around like an idiot - celebrating the AmmoJS plugin’s new motor func.)
(Wingy kicks the Oimo motor, and then continues soaking its bearings with WD-40)
2 Likes
Simplified Playground
2 Likes
`
its so sensitive cuz of the tires being so big
`
i think you should reduce the radius or maybe add some monster truck physics
(suspensions)
if the center of gravity was lower it would be better
( I think wanted to make the car movable even when upside down)
1 Like