If you are setting keys for transform properties then the normal interpolation between keys applies. If you see no interpolation, maybe your keys are stepped?
I suggest using the latest 4.3 beta version, which should work correctly.
If movements in-game give you unwanted physics movement, simply disable transfer of game object movement into the skeleton's physics. Then you will have only the physics you see in the Spine editor.
There are 2 ways that external movement gets transferred into physics:
1) Some game toolkits apply an external transform when rendering so the origin of the skeleton's world space doesn't change. When doing this, the skeleton does not see any external movement so such movement must be manually transferred into the skeleton using Skeleton physicsTranslate and physicsRotate. Omit calling those to remove the external physics movement.
2) Otherwise, physics sees movement by noticing changes in the skeleton's world space. If you are moving the root bone or setting the skeleton position, that affects the world position of bones and so physics sees it and reacts. You can counteract such movement by calling physicsTranslate with the opposite amount, like this:
float oldX = skeleton.getX(), oldY = skeleton.getY();
skeleton.setPosition(newX, newY); // Skeleton moved.
skeleton.physicsTranslate(oldX - newX, oldY - newY); // Give physics the opposite movement.
This cancels out the skeleton movement for physics, so physics doesn't see it at all. Or you can allow physics to see only a fraction of the movement, eg 25%:
float physicsScale = 0.25f;
skeleton.physicsTranslate((oldX - newX) * (1 - physicsScale), (oldY - newY) * (1 - physicsScale));
That can still jump a large amount, so you may want to instead provide a limit in world space units:
float physicsLimit = 40;
float dx = newX - oldX, dy = newY - oldY;
float length = (float)Math.sqrt(dx * dx + dy * dy);
if (length > physicsLimit) {
float scale = (length - physicsLimit) / length;
skeleton.physicsTranslate(-dx * scale, -dy * scale);
}
That lets some movement through so you get some dynamic movement, but the limit can be adjusted so you don't get so much it looks bad. You can also both scale and limit:
float physicsScale = 0.25f;
float physicsLimit = 40;
float dx = newX - oldX, dy = newY - oldY;
float length = (float)Math.sqrt(dx * dx + dy * dy);
if (length > 0) {
float kept = Math.min(physicsScale, physicsLimit / length);
skeleton.physicsTranslate((oldX - newX) * (1 - kept), (oldY - newY) * (1 - kept));
}
The scaling controls how much skeleton movement is transferred to physics and the limit prevents too much movement from looking bad.
The above is done each game frame, so you may want to scale it based on your game's frame rate. If you are rotating the root bone, you'd use physicsRotate in a similar manner.
This seems like a better solution than baking if the goal is to keep how your physics look in the Spine editor, plus it is usually nice to keep some dynamics. There are still use cases for baking physics, but they are rare and have their own significant downsides.
