BEPUphysics

I have a dynamic entity (a sphere) and, in a maze, when the sphere is blocked by a wall, the LinearVelocity in the related direction stay as it was before (ex linVel.Z = -6.6 when the sphere stop moving).
Is this the expected behavior ? If so, how can I get the actual velocity (knowing a non moving entity should have a velocity = 0 in the 3 ways) ?

2nd question: does a CompoundShape made of a List<CompoundShapeEntry> is better when it has less components or not ?
(rephrased: are all the members making a CompoundShape object are merged in some phase ?)

Norbo wrote: That's not expected behavior. Is the measurement being made after the LinearVelocity is being manually set each frame?

Note that an entity that appears to be stationary may still have very small nonzero velocity (e.g. 0.00001), so avoid floating point comparisons with zero. Also, note that a deactivated entity may still have a velocity below the deactivation threshold. Unless you changed that threshold, -6.6 is a couple of orders of magnitude too high to be explained by deactivation.

string.Format("\nBallPos X={0:F1} Y={1:F1} Z={2:F1}\nspeed X={0:F2} Y={1:F2} Z={2:F2}", ball_test.Position.X, ball_test.Position.Y, ball_test.Position.Z, ball_test.LinearVelocity.X, ball_test.LinearVelocity.Y, ball_test.LinearVelocity.Z);

Norbo wrote: Having less entries in a compound will tend to make it faster. There is no automatic merging.

I would suggest testing the performance without this optimization first to see if it's fast enough. My guess is that it will be.

Norbo wrote:Is the ball controlled in any way? Do you ever set the ball's linear velocity yourself? If so, is it being set after the Space.Update? If so, the velocity read in draw will always pick up that written value, not the solver-computed value that got overwritten.

To avoid this, either read the velocity between the Space.Update and manual velocity set, or put the manual velocity set before the Space.Update so that the draw (which does occur after the update(s)) will see the solver-computed value. If it's based on user input, putting the manual velocity set before Space.Update will also remove a frame of latency, since the simulation feels the change sooner.

Norbo wrote:Oop, I just took a closer look. In that picture, the output speed and position seem suspiciously similar, almost as if they're the same values formatted differently

Pos X={0:F1} Y={1:F1} Z={2:F1}\nspeed X={[b][u]0[/u][/b]:F2} Y={[b][u]1[/u][/b]:F2} Z={[b][u]2[/u][/b]:F2}