Jul 19, 2012 at 9:01 PM
Edited Jul 19, 2012 at 9:05 PM
As a first step I'd check the actual mass just to be sure. Mass of 1 is just a too nice round value :) Just put a breakpoint after you create the body and examine the member variables of the Body class.
Secondly you need to play with the parameters (Farseer has a lot of them). Some vibration is "normal" for a physics engine since it does not provide an exact solution to the equations of motion but instead converges to a solution with each step
(and sub-step iterations). It's important that the instability is imperceptible. You are lucky you don't deal with complex joints - I can tell you it's a world of pain sometimes :)
Restitution - this affects the bounciness of the object. 1 means perfectly elastic collision whereas 0 means all energy is lost in the collision.
Friction - you can up the friction to make the object slide less.
Angular&Linear Damping - increasing those will definitely eliminate small oscillations (sort of like simulating viscosity only linearly). I use them always.
Farseer has some global settings too (FarseerSettings) - it's usually not recommended to change those but might be necessary:
Velocity/position iterations - increasing those (in your case more the velocity iterations) will make the solver work harder each step to converge to the solution. Results in much higher CPU use so unfortunately can't go too high.
There is a setting for max velocity - again a problem of scale - if you're shooting with a velocity too high (I don't remember the exact value but let's say above 400 km/h give or take) the engine won't simulate it properly. This value can be changed safely
if the scale cannot be otherwise altered but the engine is fine-tuned to work with those values so it's best kept as a last resort.
Decreasing the time-step - will make the simulation more precise but at the cost of CPU. If the time-step is too big the simulation will be unstable. For example if I ask the engine to simulate 5s of the time per step instead of 15ms (at 60Hz which is a
"good" update frequency to aim for same as 60 fps for graphics) the error of integration will be so high that it will look completely unrealistic. This is a common problem in network games where there is "lag" and it's a tough issue to
Another problem I've often had myself is having the sprite positioned incorrectly with regards to the actual physics so everything seems to be working but collisions look very weird. I have no experience with the framework you are using but Farseer has a
DebugViewXNA so in XNA you can actually draw the physics shapes on top of the graphics to quickly see if there are issues.
Finally Farseer has a special setting for bullet type bodies (IsBullet=true) which could be useful (it has to do with continuous collision detection and fast moving objects).
HTH but in the end of the day trial and error is the best weapon.