BEPUphysics

All the demos seem to ignore friction of static objects. In ConfigureContactManifold, they always take the friction of A and then average it with the friction of B if B is not static.

Is there a reason for this? Are you allowed to allocate BodyProperties for a static handle? And if not, what's a good way to do this? Obviously static objects still have friction, so it would be nice for an object to slow differently on a floor of ice versus a floor of sand.

Good catch. There's a (bad) reason: laziness!

The BodyProperty was a piece of demos-focused code that was intended more as an example than anything else, since it doesn't do anything special. At some point I moved it into the engine and didn't generalize it (or even update some of the comments, apparently).

0aec2c4a replaces BodyProperty with CollidableProperty with more generality. I'll see about modifying a demo to explicitly use it.

Awesome! Thanks for the super fast turnaround.
Follow up: how often do you publish a new nuget version?

Historically, infrequently to the point of inconvenience. I keep intending to set up automatic prerelease publishing. I might just do that today while I wait on my ML training runs to fail

I would appreciate it but I suppose it's easy enough to copy that one class into my project.

This is kind of breaking out of the point of this thread, but in my game I have an ECS where entities have a PhysicsComponent that contains a BodyHandle or StaticHandle. I think want the remainder of my physics properties (e.g. Friction) to be on this component as well, so all game properties are managed by the same system. To map an entity to a body I can easily do Entity -> PhysicsComponent -> BodyHandle, and to map a BodyHandle back to a PhysicsComponent I was planning to do BodyHandle -> CollidableProperty<Entity> -> Entity -> PhysicsComponent. Entity is unmanaged so I think this should be safe. I'm just wondering if there's any reason this is a bad idea... it's one extra layer of abstraction, but that seems better than using a CollidableProperty<PhysicsComponent> directly, which may cause confusion around why some properties are managed by the main ECS buffer and some are managed by the BEPU property buffer.

If it's convenient and speedy enough, it'll be fine. As always, being 'speedy enough' depends on the data access patterns. If you need to jump through those indirections a million times a frame, it might require some more attention, but otherwise, might as well do the simple thing.

Although on second thought, getting an object's position will require diving into BEPU properties anyway, so maybe my PhysicsComponent will simply be the CollidableReference with some helpers for GetBodyReference and getting CollidableProperty.

FYI, updated nugets: https://www.nuget.org/packages/BEPUphysics/2.3.0-beta0

It's automated now, so they'll be quite a bit more frequent. There's supposed to be a package uploaded to the github registry too, though that's... currently failing for inscrutable reasons.