Vehicle physics with Cannon.js

I tweaked my flight model values a bit and I’m pretty happy with the result. My model is definitely more arcadey than realistic (especially when I’m landing at the end :smile:) but I like it.

In the beginning (0:10) I rapidly press up / down buttons to show what how my model behaves compared to yours. I think you should add some sort of input smoothing so that your model doesn’t react as immediately as when I rapidly moved my mouse up and down in your demo. Just my opinion obviously.

1 Like

Yes, I like your flight model too. It looks like you’ve gotten it working just fine and it looks like a lot of fun to fly.

Was the airplane available in your sandbox? I only saw a couple of cars. What controls do you use to fly it?

That’s a good point about my controls. I had set limits on the amount of change, but had not considered limiting the rate of change. The change you propose would definitely make it more realistic and less “twitchy”. (Although the controls on aerobatic airplanes are extremely sensitive, the kinds of planes that I am trying to simulate - including warbirds - are not extremely sensitive and are designed to travel long distances in stable flight.)

1 Like

Was the airplane available in your sandbox

It’s on the runway through one of the tunnels, you have to drive to it.
Controls are displayed in the bottom left corner when you enter the airplane.

Please keep in mind that the live demo is using my old flight model without today’s adjustments. I’ll upload the new code tomorrow.

aerobatic airplanes are extremely sensitive

I think limiting the rate of change would be a nice improvement. Sensitivity is one thing, but surely no real airplane can behave like this?


Yes, no aircraft can do that. In addition to speed of movement of the control surfaces, I can see that I also need to take angular momentum into account, which should resist such sudden changes. (I assume that cannon.js does that for you automatically?) Until that problem is solved, I need to add a placard in the cockpit warning against such violent movements.

1 Like

placard in the cockpit warning against such violent movements

Good idea. :smile:

I also need to take angular momentum into account, which should resist such sudden changes. (I assume that cannon.js does that for you automatically?)

Sort of? All I ever modify is the airplane’s velocity, and angular velocity. Cannon applies the velocities every simulation update, but that’s not difficult:

# Obviously you can do this without cannon
position += velocity
rotation += angularVelocity

There’s no hard limits on the absolute position or orientation of my airplane. I never modify or limit them directly, only through velocity. I think that might be one of the main differences between our models?

I could never perform such sudden changes in your demo. A ridiculous acceleration amount would result in an equally ridiculous reaction, because like you said, my airplane respects it’s momentum (positional and angular). But your airplane can accelerate it’s rotation very rapidly and then stop immediately, which feels unnatural to me.

It looks like the problem is not with ACflyt, but with the way I implemented the pitch animation. I have now loaded a version of the demo with the pitch animation disabled so you can see how ACflyt computes pitch: ACflytModelDemoXP

In ACflyt, you are not inputting pitch directly. This is one of the unique aspects of the program. What you are inputting is the coefficient of Lift (cfLift), which affects the lift vector. ACflyt computes the change in the flight path caused by the Lift (and Gravity) and then, by default, points the aircraft in the direction of flight. (So when you start out on the ground, the aircraft is pointed level since that is your initial direction of flight.)

The conversion of mouse movements into changes in cfLift is handled by the demo program. I was concerned that the program might be converting mouse Y movements into cfLift directly, e.g. cfLift = mouseYdiff * factor. However, the equation I am using is cfLift = cfLift + mouseYdiff * factor. This should be okay…

So that leaves the pitch animation as the source of the problem. In Blender, I created an animation that allows you to pitch the aircraft back and forth - a deflection from the direction of flight computed by ACflyt. Since clLift is a direct result of this deflection, I can use cfLift to back into the required deflection. It could be that I was keying this animation based on instantaneous changes in cfLift rather than on the actual change in cfLift. I will investigate.

I couldn’t tell from your video - was your frame rate over 60fps?

Cool! That feels a lot better. :slightly_smiling_face:

My app runs at 60 fps at most. I think it’s a requestAnimationFrame limitation.

Regarding limits, I believe that ACflyte can accept whatever inputs I throw at it. However, the demo program imposes limits on max cfLift and Bank speed, dictated by aerodynamics, the aircraft structure and pilot G-tolerances. If I removed those limits, our programs would probably perform similarly.

I spent a lot of time developing routines to handle a taildragger. However, cannon.js may be able the handle those interactions as well as other interactions with the ground.

this is so good, im scared of the math behind it, i dont think i could ever do something close to that, but it must be so much fun. i saw an older kenney tweet where he mentioned that for arcade-like drifting he’s just using a sphere and applies directional force: is the way you handle it much different from that approach?

1 Like

Yes it’s completely different. I didn’t write it, but I’m using the cannon.js’ raycast vehicle component. I actually suspect cannon’s creator just ported the component from bullet, but I don’t know for sure.

It has a raycast for each wheel and does a lot of complex math to simulate suspension, tire grip etc. I just used it since someone did the hard work already.

By the way, here’s work in progress airplane entry animation.


After all that soul-searching and reviewing my code, I ended up simply decreasing the sensitivity of the MouseY axis (“pitch”) - which has the effect of limiting the change.

That animation is great! Certainly eliminates the need for a door.

Is your program going to incorporate mouse controls? Some people are great with keyboard controls - not me. Also I am left-handed, so something involving a combination of mouse and arrow keys works best. I would suggest a trailing camera, so that when things move, the camera automatically falls in trail. You could even use the mouse as a primary control, on both 2D surfaces and in the air.

Finally, I was reminded that you have some great looking water. You ever going to add boats bouncing around in the waves? Many years ago, I designed several vehicles for the MS Flight Simulator. Since I enjoy pushing boundaries, most of the vehicles I designed were boats, which proved very popular. I spent a lot of time trying to create animated waves - and now you have them at your disposal!

I look forward to seeing your future additions and improvements!