space.Solver.Starting += new Action(Solver_Starting);
For some reason the space.SolverStarting Action is called twice per frame instead of once.
My algorithm for valid collision detection relies on this action only being called once per frame and I'm not certain why it is called twice. There is probably a valid reason for this though.
I can get around it by setting up a bool to return if the Action has already been triggered this frame but I would like to know why this is happening, just out of curiosity. Is it an intended behaviour of the physics engine?
If Space.Update(dt) is being called (as opposed to Space.Update() with no parameters), the Space can take multiple time steps per Update to keep up with the accumulated time. For example, if the target update rate is 60 updates per second and the Space.TimeStepSettings.TimeStepDuration is 1/120f, Space.Update(dt) would perform two time steps on average. Even if both the target update duration and time step duration are the same, tiny differences in the accumulated time can cause some frames to have zero time steps and other frames to have 2 (or rarely, more) time steps.
If you want to guarantee a single time step per Space.Update call, use the parameterless Space.Update() method. This will make the physics update rate dependent. If IsFixedTimeStep is true in the XNA game, it won't be a problem; if it's a free running update, the physics will appear to speed up and slow down depending on framerate.
Another option is to perform all the physics-related logic within the context of a time step as opposed to an update, so the number of time steps per update is irrelevant.
Another option is to perform all the physics-related logic within the context of a time step as opposed to an update, so the number of time steps per update is irrelevant.
Any handler hooking into a starting or finishing event of any per-timestep space stage will execute on each time step. Updateable types (other than the IEndOfFrameUpdateable) offer hooks into various parts of a time step as well.
By putting the logic into such an event handler or updateable, it will execute along with every time step rather than with every frame. If your logic expects to run on each time step as opposed to each frame and internal timestepping is used, executing in this 'inner' per-time step context is required.