Mismatch before:

Hi @notgiven688 thank you for this but my PR which I have had already in working has fixed this issue and I have just merged my PR. I did also some clean up in this example so it is more consisent with the other examples.

We would like to add more examples, raycast and 2D, I would need to check your docs how you support 2D. Nice to have another physics engine on board so people can try it with Stride 💪🙂.

@VaclavElias Okay, perfect - thanks for the update!

Regarding 2D: Jitter2 is fundamentally a 3D physics engine, but 2D-style behavior can be achieved by constraining motion and rotation. This comes up quite regularly. I outlined the typical approach here: notgiven688/jitterphysics2#232

In short, you lock one translation axis and two rotation axes using constraints, effectively restricting bodies to a plane. That works well for many 2D use cases, but it’s worth keeping in mind that it’s still running on a 3D solver internally.

@notgiven688 you are welcome. Thanks for the link, it will definitely help to speed things up on my side.

I had to do something similar for Bepu as well (https://github.com/stride3d/stride-community-toolkit/blob/main/src/Stride.CommunityToolkit.Bepu/Body2DComponent.cs), so constrains really are the way 🙂.

It's always nice to see that with a few tweaks, a 3D physics engine can still handle some 2D use cases.

It makes me wonder whether 3D physics engines should offer a basic, optional 2D resolver, just enough to support simple 2D scenarios without compromising their 3D nature 🤔.