BEPUphysics

This is most likely a bug with the DynamicBinaryHierarchy broadphase. It attempts to grab the first entity out of a list under the assumption that there's an entity there, but this of course will fail if no entities are present. It's fixed in the upcoming version; until then, you can add a few entit...

That project looks great! One way to do what you want is to change the inertia tensor inverse on two of the axes so that it can only rotate around one (as if it were 2D): Matrix inertiaTensorInverse = vehicle.body.localSpaceInertiaTensorInverse; inertiaTensorInverse.M21 *= 0; inertiaTensorInverse.M2...

The subsequent hits probably don't get the body shape into contact with the ground, so there's nothing to bounce off of. Part of the character controller's job is to keep the body elevated some amount off the ground (which can be violated by hitting the ground with a large velocity since the body sh...

One way to do it is to set the linearVelocity based on how much you've moved it. For example, before you move, store the entity's internalCenterPosition. Move the object and get the difference between the new and old positions. Divide this vector by the timestep (space.simulationSettings.timeStep) a...

I'm not entirely sure, but it looks like your RenderState.CullMode is opposite what the objects were built for, allowing you to see through their front faces. There might be some perspective issues as well, but it's a bit hard to tell.

After one frame, only one timestep has elapsed. The default duration of a timestep is 1/60 seconds (.01666..). The force property is a bit of a misnomer at the moment as it shows the momentum change of the last frame, which is the timestep times the total force applied, or 9.81/60 = .1635. I'll clar...

Thanks for the information, I'll investigate further and fix any bugs for v0.10.0.

The engine isn't based on any single resource; it basically evolved over time with independent work and varied research. I've learned quite a few valuable concepts from resources/information put out there by people like David Baraff, Erwin Coumans, Erin Catto, Gino van den Bergen, Christer Ericson, ...

Your project looks great! In some quick tests I couldn't seem to replicate the issue so I'll just try to collect some diagnostic information; are you using version 0.9.0? What kind of scaling does the terrain have (I.E. how large are individual triangles)? Does it occur at the meeting between differ...

The best way to find out would be to test your specific scenario, but they should be comparable. The algorithm doesn't do anything remarkably different for different types of shapes, but some contours can take longer to converge. MPR tends to work pretty well with both traditional polytope style obj...

Just about, it's:

(Entity).localSpaceInertiaTensorInverse = Toolbox.zeroMatrix;

Since StaticTriangleGroup triangles 'come alive' when entities' bounding boxes approach, you can create and maintain the position of a ghost entity which somehow represents or contains the camera path. A big box would do the job. The now living triangles will be in the controllers list of the ghost ...

The easiest way would be increasing gravity (space.simulationSettings.gravity). Chances are the 'slowness' you notice is caused by the character controller being quite large compared to a real human, so the default 9.81 m/s/s isn't sufficient to give the same effect. Shrinking the character would ad...

Applying impulses will only immediately change velocities and momentums; if you look at the internalAngularVelocity or internalAngularMomentum they should change. The orientation matrix is updated only when the position is calculated for a new timestep in the update method. Additionally, the applied...

While you can't get the contacts directly (they aren't any when the objects are resting on a STG, actually), you can do a brute force activation on all entities within a bounding box. Grabbing the StaticTriangleGroup.triangleMesh.hierarchy.boundingBox and querying the broadphase with space.broadphas...