I'm still learning the innards of the engine but the ResetPosition command moves the physics collision 'box' to match the 'visual' position of the model, if you do this with CollisionOn the two engines start fighting with each other as GG is trying to move the model and Bullet is trying to resist, that's why it judders. ResetRotation is even worse as it will spin madly on the spot!
SetPosition does not move the collision box (I'm calling it a box but in fact it could be a mesh or capsule) which is why you can walk through the object after it has been 'moved'.
How effective the movement by doing the CollisionOff, Re-position, CollisionOn trick is in the physics world depends on the frame rate, especially for fast moving objects.
Basically what happens is that with low frame rate you are moving the object further each time, it isn't really a 'move' as such it is 'transporting' from the old position to the new position so if for example two moving objects are repositioned to the same spot they will visually merge with each other until the next pass of the Bullet engine where it will probably attempt spring them apart again. Unfortunately this causes some really strange behaviour like being able to punch objects through the terrain or having them fly off in weird directions.
The way this is usually dealt with is that all movement should be done via the Bullet engine and if it detects an upcoming collision it generates a call-back to tell the visual side that the movement you asked for cannot be achieved, GG doesn't have a mechanism to do this at present, or at least no mechanism to pass the info back to the script, so getting smooth movement with physics is rather difficult.
In the case of platforms the trick to use is to detect when the player is on the platform and move the player with the platform, the same trick can be used in vehicles but only works well for slow moving ones as if things are moving too fast eventually you will find the player falling through the object or worse getting stuck in it!
Hopefully this will all get fixed now that we have SITD working on it.
As an aside I finally figured out why my original quatlib wasn't working properly, the Bullet engine also uses quaternions to move things around but GG doesn't, the conversion between Euler angles and quaternions was subtly different between my library and the math routines the Bullet engine uses, for the visual side in GG this didn't matter because it will accept 'weird' Euler angles and still show the correct result visually but the repositioning of the collision box is handed off to the Bullet engine and it came up with a different result so the two 'models' ended up in different places!
I'm toying with the idea of replacing my quatlib with direct Lua calls to the same math library that Bullet uses, I would keep the interface to other scripts the same so you would still call the quatlib functions in the same way but under the covers the lib would call the C++ maths routines, the advantage is that I can add SLERP and other cool stuff without having to re-invent the wheel!
Been there, done that, got all the T-Shirts!
