Okay, I think we've isolated the problem; we've also done a build with Newton 1.53 and confirmed that we don't get the same slow-downs when changing the solver model in there.
So today I realized that when I said it was an empty scene except for one capsule & one joint, I was in fact quite wrong!....
. I had forgotten about the "runway" we had also been testing with, which was invisible in the scene the whole time, and it's this runway that shows up the problem. I'll explain the scene layout:
We have a single capsule:
Radius: 0.11
Length: 0.4
Position: -0.2, 0.05, 0.0
Mass: 1.0
AutoSleep: false
LinearDamping: 0.5
Inertia: calculated with ConvexCollision->calculateInertialMatrix()
The ForceAndTorque callback is a standard gravity callback provided by OgreNewt.
We have a joint attached between the capsule and the World to set the position of the capsule. This is the simple custom joint from my previous post.
We have a static "runway" object which is a hollow square tube made from 4 boxes. It runs left-to-right on the screen, is 40 units long and 0.72 units wide with a 0.24 unit square hole through the middle. Here are the sizes and positions of the 4 boxes:
//Bottom
Size: 40, 0.24, 0.72
Position: -10, -0.24, 0
//Front
Size: 40, 0.24, 0.24
Position: -10, 0, 0.24
//Back
Size: 40, 0.24, 0.24
Position: -10, 0, -0.24
//Top
Size: 40, 0.24, 0.72
Position: -10, 0.24, 0
Lastly there is one single material applied to the capsule and the runway. This is a default material apart from the default friction being set to (0,0).
Two keys on the keyboard are set up so that we can move the capsule 2 units to the left or right by way of the joint. We added a small cube in the visual scene (not in the physics World) which shows the position the joint is currently set to, (which is the location the capsule should be pulled to).
As I've mentioned above:
If I set the
solver model to 0, when I move the position the capsule speeds to that new location and is there in a fraction of a second.
If I set the
solver model to 1 (or any other value up to 4000), when I move the position the capsule starts moving at a moderate speed toward it, then slows down as it approaches and eventually glides to a stop in the correct position after a second or two, (actually more like 5 seconds).
If I build the application with Newton 1.53 I get the same fast response with the solver model set to 0 or 1.Now the space between the edge of the capsule and the surrounding runway is only 0.01 units... If we make the capsule radius smaller so this distance is instead 0.05 units then it all works fine using either solver model, but having done this, if we then attach a couple more capsules to the front of this capsule in a line so that gravity pulls the front-most capsule down to touch the runway again, the whole thing moves slowly using solver model 1 and we're back to where we started
.
To see exactly what I mean by this slow-down, please check out this video:
http://nz.youtube.com/watch?v=0p2AgsI_fo0Note that the visual representation of the objects isn't quite the same as the objects in the physics World, so look at the white wireframe rather than the grey boxes.. The small grey box that speeds ahead is the marker showing where the joint position is set to, and the runway is in fact all around the capsules but only the bottom piece is displayed as solid. The "position" joint is only attached to the left-most capsule.
With Newton 1.53, both Solver Models behave the same as Solver Model 0 in Archimedea.
We really get a lot of performance and stability gain from Archimedea in other areas, so rolling back to 1.53 would be a very unhappy option for us. I guess the question is: what are the chances of getting this problem fixed in Archimedea, and is there any way we could work around this problem?
We also seem to be getting the same "lagging" problem with completely different joints being used in completely different ways, so although we could probably do away with the runway and avoid this specific instance, we really need some more general mechanism for avoiding it completely in the application.
Thanks in advance!
-Aaron.