I am trying to integrate Bepu physics into my monogame project and am trying to figure out the best way to map / integrate the Bepu entities to the Monogame entities.
From what I can gather, Bepu will manage / control the position and rotation of the model, and scale / size can be defined externally (but set on the Bepu entity).
It’s a little confusing as to how I should tie these together…
If you integrated physics, how did you manage this relationship between the physics entities and the monogame entities / models?
Yes, it will be a very good physics framework when all these optimizations are included. (Not it is not currently a good one, it is already a good one, but it will be better/faster)
I’m very excited to try it in my game which is highly demanding on physics to see the improvements.
I am using the code from the github repo, and I don’t believe it has any of the v2 optimizations.
One thing to note… in it’s current state, Bepu does not work with UWP projects. This is due to the code not being .net core compatible i.e. some references / classes are not available in the current version of .net core like Thread.
I created this thread in the Bepu forums on the issue:
Doesn’t Tasks uses Threads in its underlying code?
I hope microsoft will let developers choose how they want their app run instead of commanding how an should be done because it could… It should… Whatever reason.
Over on github, jwollen has compensated for my laziness and created a portable fork targeting .NET Standard v1.4: https://github.com/jwollen/bepuphysics1/commits/portable
I haven’t tried it, but it looks like it covers all the expected areas. v2 is indeed targeting out of the box portability. Probably .NET Standard 2.0, unless platform support is still lagging by the time BEPUphysics v2 is near completion.
You’re correct that the bepuphysics1 repo (library version v1.5.0) does not include any of the v2 optimizations. v2 is a ground-up rewrite with some pretty huge changes in data flow; each new system in isolation wouldn’t fit well or help as much in v1.
@kosmonautgames If you’re seeing garbage, there might be a bug. While there are a few known situations where garbage is generated (one-time array resizes when the simulation expands beyond preallocated complexity, or situations where the API makes it hard to reuse memory like reconstructing a StaticMesh’s internal hierarchy in response to topological changes), regular steady-state execution shouldn’t be creating any garbage. If you can reproduce it in the demos or otherwise in isolation, I could take a look and see if I can fix it.
(That said, v2 should have even fewer opportunities for garbage. Heap complexity is also massively reduced, so unrelated application GCs should go faster too.)
@Norbo Thanks for the update! I have managed to convert the original github code to work with UWP (at least… it appears to be working with the simple test I have)… now just trying to integrate it cleanly into my existing Monogame project.
We’re looking forward to v2 which I am sure is going to be awesome!
You’re correct that the bepuphysics1 repo (library version v1.5.0) does not include any of the v2 optimizations. v2 is a ground-up rewrite with some pretty huge changes in data flow; each new system in isolation wouldn’t fit well or help as much in v1.
Hum… I don’t have time to play with the scratchpad repo
