SolverModel under Archimedea...?

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

SolverModel under Archimedea...?

Postby Aaron » Thu Sep 11, 2008 6:43 pm

I've been working on a project which uses a long string of objects connected together and has a lot of problems with speed as it's very CPU intensive. Recently we found "SetSolverModel", changed this to "1", and amazingly everything is now about 10x faster!... that was great yesterday - today we're finding out the ramifications of changing the solver model...

So, my first question: Is the "SolverModel" setting under Archimedea the same as in Newton 1.5?... Is there any more documentation available on this setting in addition to what's in the 1.5 docs? (ie: http://www.runehunter.phpnet.us/NewtonHelpCode.html#NewtonSetSolverModel)

The problem we're having with setting this to "1" is that when we push the "tail" end of our rope-like object forward, the "head" end moves forward, but not as much as it should, and then takes the next few seconds moving forward slowly till it gets to the right position.... This lag makes the application completely unusable. (The joint I'm using between each segment of our rope object is a custom joint which trys to rigidly maintain the joint position, (like a ball & socket joint), but also trys to stop the joint from bending).

I'm assuming this problem is because of the "non-exact" nature of SolverModel=1... can anyone suggest anything which could help a string of objects connected together act more rigid with SolverModel=1? Is there any way to get a SolverModel which is somewhere between 0 and 1?

This application also needs to give similar physics results on a range of different speed CPU's, which I'm worried that a SolverModel != 0 will have problems with - can anyone shed some light on this for me?
Aaron
 
Posts: 8
Joined: Tue Feb 19, 2008 7:18 pm

Re: SolverModel under Archimedea...?

Postby Julio Jerez » Thu Sep 11, 2008 6:47 pm

Solver mode 1 is the more incurate and it will exibi teh salastic vehabior it is more for games than for more serius application,
you can use solver mode 4 or more. the higher the more acurate and the slow down is not as bad as solver mode 0
also play at higher frame rate.
Julio Jerez
Moderator
Moderator
 
Posts: 11155
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SolverModel under Archimedea...?

Postby Aaron » Thu Sep 11, 2008 6:53 pm

Hi Julio, Thanks for the quick response!

Is the solver mode of 4 or more the same as in the 1.5 docs? Also, what's a good upper-bound for trialing this... I mean is 10 about as high as you should go, or is 10,000 reasonable in some situations too..?

Can you elaborate on what effect the frame rate would have on the simulation?

Thanks,
Aaron
 
Posts: 8
Joined: Tue Feb 19, 2008 7:18 pm

Re: SolverModel under Archimedea...?

Postby Julio Jerez » Thu Sep 11, 2008 6:58 pm

I have not test or run any analitical cost for the iterative solver algorithm.
I can only say tha teh higet teh mode teh beter teh convergence of teh solver, you can try an high number like 16 and see what kind of result you have.
In teh SDK demo I beleive 1, 2, 4 , 8 and at 8 it is almos as acurate as the exact solver.
I guess the answer is that you have to run some test to see the kind of result you get.

fortunatly is just a matter of changing a number and reun the test.
Julio Jerez
Moderator
Moderator
 
Posts: 11155
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SolverModel under Archimedea...?

Postby Aaron » Thu Sep 11, 2008 7:15 pm

I've just tried the solver mode at 4, 40, 400, and 4000 (just to be really thorough :)), and apart from CPU usage, it doesn't seem to make any difference to the application at all. Setting the solver mode to 0 is significantly different. (I've also tried increasing the frame rate from 60 to 600 which also seemed to have no effect).

I have just noticed thought that the problem doesn't seem to be coming from the segments getting condensed when the rope moves, but rather from the joint that's pushing the "tail" of the rope.... I've got an IK-type joint between the tail of the rope and the world, which pulls the tail into a specific position. The problem seems to be this joint moving the whole thing slower now rather than the "condensing" problem I thought it was originally.

I'll do some more looking into it and post back.
Aaron
 
Posts: 8
Joined: Tue Feb 19, 2008 7:18 pm

Re: SolverModel under Archimedea...?

Postby Aaron » Thu Sep 11, 2008 8:27 pm

Okay, it doesn't seem to be related to the IK joint that pushes the tail around either, as if I manually set the position of the tail the rest of the segments move just as slowly as they did before to catch up. There are usually 30-60 segments making up the rope, but I've reduced this to 5 and still get the same effect (at the same speed).

Basically it seems like if I set the SolverModel to anything other than 0, any joints in the simulation will move as if the environment is submerged in molasses and they have to struggle to move anywhere..

I'll keep looking into it, but any thoughts on ways around this would be most appreciated...
Aaron
 
Posts: 8
Joined: Tue Feb 19, 2008 7:18 pm

Re: SolverModel under Archimedea...?

Postby Julio Jerez » Thu Sep 11, 2008 9:13 pm

I do no tknwo what you are doing to make an opinion.
Julio Jerez
Moderator
Moderator
 
Posts: 11155
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SolverModel under Archimedea...?

Postby Aaron » Sat Sep 13, 2008 12:59 am

Ah, yes, you're quite correct...

Let me explain where I've gotten to since my last post:

First off, I'm using Ogre with the most recent version of OgreNewt for Archimedea beta 14. I also tried the beta 17 yesterday and got the same results.

I have a scene that's completely empty except for a single capsule. The capsule is connected to the world by a single (rather simple) custom joint which just tries to set its position and orientation; Here's the code ("mPos" and "mDir" are set externally):

Code: Select all
void PosAndDirJoint::submitConstraint( Real timeStep, int threadIndex )
{
   Quaternion currentOrient;
   Vector3 currentPos;
   mChild->getPositionOrientation(currentPos, currentOrient);

   //Connect the point to the world on all three axis
   addLinearRow( currentPos, mPos, Vector3::UNIT_X ); setRowStiffness(1.0);
   addLinearRow( currentPos, mPos, Vector3::UNIT_Y ); setRowStiffness(1.0);
   addLinearRow( currentPos, mPos, Vector3::UNIT_Z ); setRowStiffness(1.0);

   //Rotate to point in the right direction
   Vector3 currentDir = currentOrient * mPin;
   Quaternion rotationNeeded = currentDir.getRotationTo(mDir);
   Vector3 rotationPin;
   Radian rotationAngle;
   rotationNeeded.ToAngleAxis(rotationAngle, rotationPin);

   if (Math::Abs(rotationAngle) > Degree(0.001))
   {
      addAngularRow(rotationAngle, rotationPin); setRowStiffness(0.0);
   }
}

Displayed on the screen I have the capsule and a small cube showing where the "position" of the IK joint is set to. I have keys set up to either move the joint position 2 units to the left or 2 units to the right.

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.

This behaviour doesn't seem to be restricted to this specific joint, as another three joints I use in the application seem to have the same problem. On the other hand if I fire an object at another object it will bounce off and push the other object around the same way no matter what the solver model is set to.

The setup I have for testing with is really quite minimal - I don't think there are any other non-default settings in play. Any ideas why the solver model would have such a huge impact on joints, and what I could do to combat it?
Aaron
 
Posts: 8
Joined: Tue Feb 19, 2008 7:18 pm

Re: SolverModel under Archimedea...?

Postby Aaron » Mon Sep 15, 2008 5:26 am

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!.... :oops:. 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_fo0

Note 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.
Aaron
 
Posts: 8
Joined: Tue Feb 19, 2008 7:18 pm

Re: SolverModel under Archimedea...?

Postby Julio Jerez » Mon Sep 15, 2008 8:19 am

you are moving one of teh bodies linked to teh chain, that the problems .
Actually the should also malfuntion in all othe solvers.
The rrason why it worl in 1.53 is because the solver is exact so it will iterates until teh force to maintin teh contsration are wh athe neww to be,
in 2.0 he iterations solves has a fix number of passed and use an algorithm.
it is the way you move the bodies by teleportiong the the cases the problem, because the newton solver use a fix Max velociy to resolve penalties, so if bodies seperate beacuse you are adding huge penalty then the solver cannot keep up.
you need to apply a force or a velocity, no teleporting. Has you try increasing teh frame rate and see if it get better?

Aaron wrote: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?
-Aaron.

the chances of the happens are zero, I am no going to tell you that I will fix it because that is imposible and is a violation of the law of algebra. The only way to solver that is using an exact solver which is in 2.0
I do not know how to solver large linear systems exactly in few iterations.
Beleive me if I new that I will more famus than Cottle and George Dantzig which invented the theory of solve those kind of optimization problems.
I am not that smart to invent a brand new methods that is linear and also exact for optimizing large systems of equations, which is what is needed it to solve that problem.
Netwon have two solvers, one for simulation which is exact within the limits of the condition number of the system matrix, and another for fast aproximation wich is will work fine as long as the penalty error is small.
I am sorry but you are asking me something I am incample of delivering.

what it si that you are doing anyway? Maybe they are other ways to adress the problem.
Julio Jerez
Moderator
Moderator
 
Posts: 11155
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: SolverModel under Archimedea...?

Postby Aaron » Mon Sep 15, 2008 8:35 pm

Hi Julio,

I'm not an expert on the inner workings of physics engines by any means, and from what you've said I think I may have made a couple of wrong assumptions..

Let me start by clarifying a couple of things about my last post:

Firstly, this problem only happens when the body I'm moving is in contact with another static surface (even if the friction values are set to 0.0). If there is no other static body next to the capsule then Solver Model 1 gives exactly the same fast results as Solver Model 0. It seems as though Solver Model 1 is applying friction somehow, or interpreting the contact as a constant stream of collisions and slowing the body down(??)

Julio Jerez wrote:you are moving one of teh bodies linked to teh chain, that the problems .
...
it is the way you move the bodies by teleportiong the the cases the problem

I'm not actually teleporting any bodies around in the example - the small grey cube that gets teleported around isn't a physics body; it's just a marker on the screen so I can see where the joint connects to in the physics World. The joint is between the left-most capsule and the world, and when a key is pressed I'm changing the point it's connected to in the World. This might internally equate to "teleporting" something around though, I'm not sure?

Julio Jerez wrote:the newton solver use a fix Max velociy to resolve penalties, so if bodies seperate beacuse you are adding huge penalty then the solver cannot keep up.

In this example I'm moving the World connection point quite a long way in one go, just to make the problem obvious, which might be causing problems with this "Max velocity" you mention, but in the actual application I only move this point forward a tiny amount each frame and using Solver Model 1 it can't even begin to keep up. Also, the distance I'm moving the connection point by in the example is only 2.0 units, and it takes the joint about 5 seconds to achieve that - is that really the expected behaviour?

Julio Jerez wrote:The rrason why it worl in 1.53 is because the solver is exact

I've tried using both the "exact" and the "adaptive" mode in Newton 1.53 and they both work the same fast speed as the "exact" mode in Archimedea - it's only the "adaptive" mode in Archimedea that lags. I thought that the adaptive mode in Archimedea was the same as the adaptive mode in 1.53, so when Archimedea went a lot slower I thought it was possibly a bug, but if Archimedea is using a completely different solver for its adaptive mode it might just be a limitation of the new solver - does that sound right?

Julio Jerez wrote:you need to apply a force or a velocity, no teleporting.

I expected that when I changed the position in the World that the joint was connected to, the joint would internally work out the forces needed to get there and apply them itself.... Is this the way joints work, or do they move and rotate bodies using a different method?
If I calculate the force and torque myself and apply them to the body, is this doing anything different to what the joint should do?

Julio Jerez wrote:I do not know how to solver large linear systems exactly in few iterations.

I get the same result if I set the "Solver Model" to 4000, (ie: 4000 iterations?) - obviously this number is way too big, but if I set the solver model to use say 16 iterations as you mentioned before, should this give the same results as the exact mode?

Thanks for your feedback on this so far Julio; it's really appreciated. I'll go and try using forces rather than a joint as you suggest and let you know how I get on - please just confirm that my assumptions above are correct.

Cheers,
-Aaron.
Aaron
 
Posts: 8
Joined: Tue Feb 19, 2008 7:18 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests