Kinematic Joint Assert [SOLVED]

Report any bugs here and we'll post fixes

Moderators: Sascha Willems, Thomas

Kinematic Joint Assert [SOLVED]

Postby MeltingPlastic » Mon Oct 15, 2018 12:54 pm

HI Julio - I have another assert that is being thrown under normal circumstances, Whenever I initialize the kinematics joint I get a dgAssert(m_dof >0) in dgSkeletonContainer.cpp. Not sure why it is being thrown:

https://drive.google.com/open?id=16smfdEizEgYc5HdKEU4A7ntjcxN7kpyb

It happens in the demo whenever you click one of the objects.
Last edited by MeltingPlastic on Mon Oct 22, 2018 5:11 pm, edited 1 time in total.
MeltingPlastic
 
Posts: 237
Joined: Fri Feb 07, 2014 11:30 pm

Re: Kinematic Joint Assert

Postby Julio Jerez » Mon Oct 15, 2018 1:51 pm

in newton the joints can be exact, but there are strict conditions to use that solver.
one is that the contraction must be acyclic, this is done automatically by calculation the tree forest of the body with the heaviest mass.
the second is that each joints most at least have one bilateral constratint row.

this rules out joints like contacts and kinematic joint because a kinematic joint may break all row limits.

did you set kinematic joint solver mode to zero?
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Kinematic Joint Assert

Postby Julio Jerez » Mon Oct 15, 2018 2:29 pm

I just looked at the joint and is set to solve mode 2
Code: Select all
void dCustomKinematicController::Init (NewtonBody* const body, const dMatrix& matrix)
{
/// ....

   // set as soft joint
   SetSolverModel(2);
}


solver mode 2 tells the engine that when calculation the forest, joints with the option 2 are to be ignored.
solver mode 1 means that when searching for the forest, some time that are more than one joint that can be selected. therefore joint will solver mode 1 is used to weight the sort the order.

for example imagine you have a vehicle.

if you start at the vehicle body, the children are: the tire the engine, the transition, and any other stuff or this are mode 0, because they by definition only have one parent.
now say you are a tire, the tire ha at leas two parent,
the tire joint that connect wo the chassis, and the axel joint the connect to eh transition.
any choice will make the other joint form a loop.
in the case the application set axel joint as solve mode 1, meaning the can be acyclic only of the do not form a cycle.

Kinematic joint do not meet any of those conditions therefore unless there is a bug, you must have overridden SetSolverModel to 0 or 1 can you verify that?
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Kinematic Joint Assert

Postby MeltingPlastic » Mon Oct 15, 2018 2:31 pm

I did have the solver set to zero. changing it to model 1 got rid of the assert as you say. Thanks!

Are you saying that newton can determine if a joint can be set to solve mode 0 or not? For example is there a way I can make a function like
Code: Select all
DetermineBestSolverMode(myJoint)
without necessarily knowing the details of the joint. of course the joint would have to be part of an existing contraption.

Like lets say I make a game where users can create objects, joints etc in a sandbox like environment. It would be cool If I could run routines on their contraptions that determines the best solver mode for all joints in the current configuration. So for example a user builds an Acyclic contraption with joints that have >= 1 bilateral constraint rows. In my api I could update all those joint automatically to solver 0. Then later the user creates a loop in the contraption making it cyclic, then the joints would be set to iterative.

Question: Consider a closed loop formed with hinge constraints - Do all joints need to be iterative? or Just one?

I would be cool If I could automate that process based on the internal graph based on the conditions you describe.
MeltingPlastic
 
Posts: 237
Joined: Fri Feb 07, 2014 11:30 pm

Re: Kinematic Joint Assert

Postby MeltingPlastic » Mon Oct 15, 2018 2:33 pm

Oh Wait - If I didn't set the solver mode explicitly anywhere the engine figures it all out even after changing configurations of contraptions? Maybe I should just get rid of setting solver modes from my API!?
MeltingPlastic
 
Posts: 237
Joined: Fri Feb 07, 2014 11:30 pm

Re: Kinematic Joint Assert

Postby MeltingPlastic » Mon Oct 15, 2018 2:43 pm

Yeah I was overriding solver mode to 0.
MeltingPlastic
 
Posts: 237
Joined: Fri Feb 07, 2014 11:30 pm

Re: Kinematic Joint Assert

Postby Julio Jerez » Mon Oct 15, 2018 2:57 pm

MeltingPlastic wrote:I did have the solver set to zero.

ok that's the problem, bu setting to 1 imply that the joint can be acyclic, so the engine will so a lot of work try to find a forest that accommodate it, you should set it to 2. or leave the default it if you are using the joints in the dcustomjoint library.

MeltingPlastic wrote:Question: Consider a closed loop formed with hinge constraints - Do all joints need to be iterative? or Just one?
I would be cool If I could automate that process based on the internal graph based on the conditions you describe.

thats actually more unnecessary and confusing interface to exposed.
notice that a joints with solve mode set to 0 or 1 are also solved exactly, only joints with solver mode 2 are send uncoditially to the iterative solver.

in the example you provide of a ring of hinged this is how is works.
the body list is sorted by mass, since all bodies have the same value anyone will be the top.

them the engine iterate over the list selecting the next body and forming the forest of the body.
This is a texbook algorithm that will give to the maximal acyclic graph that can be possible made.
http://mathworld.wolfram.com/Forest.html
and I will be more accurate that a person making the selection.

them the engine form a large mass matrix that add al the joint that corm loops, and these are solve wing an exact solve, therefore in the rig example all joint are solve exactly the difference is that all but the n Joint forming the ring are solver in linear time O(k n).
whet n is the number of bodies and k is a high value constant.

Oh Wait - If I didn't set the solver mode explicitly anywhere the engine figures it all out even after changing configurations of contraptions? Maybe I should just get rid of setting solver modes from my API!?


the default is solver mode 0, so not setting it implies an acyclic joint. this is how the end user can hint the construction of a contraction, you can hint the engine that a joint is not very important by setting to 1, or that a joint is not important at all by making 2.
making is 0 will be always solve exactly whether is a loop or not.
and it is up to the use to decide if a joint will be like that or not.
In general a use can determine the by inspection.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Kinematic Joint Assert

Postby MeltingPlastic » Mon Oct 15, 2018 3:09 pm

Awesome! I think I understand better now. Generally Solver 1 is the way to go. Also I am no longer going to override what is inside the dCustomJoint initialization routines.
MeltingPlastic
 
Posts: 237
Joined: Fri Feb 07, 2014 11:30 pm

Re: Kinematic Joint Assert

Postby Julio Jerez » Mon Oct 15, 2018 3:28 pm

MeltingPlastic wrote:Awesome! Generally Solver 1 is the way to go.

Generally Solver 0 is the way to go if you know the joint is acyclic
mode 1 if for joint that can form cycles because they can form loops. so the mode 1 tells the engine where to break the loop whenever possible. else the engine will make an arbitrary break.
a simple example can better clarify.
say you have a rag doll that can carry a weapon, say the weapon can be a gun or a rifle
here you know that either attachment can be acyclic and you also know that the second hand is the secondary point.

as user you can say the attachment that make the weapon single handed is mode 0, the attachment point for second hand is set to mode 1.

what that does is that when build the forest, joints with mode 0 are added to the end of the queue, joint with solver mode 1 are added to the top of the queue, so is in general joint modes 0 are breadth first search, and joint with mode 1 are depth first search.
if you make the all 1 it all become depth first search but it will be and inefficient forest.
if you leave all 0 it will be depth first search but the break is arbitrary.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles


Return to Bugs and Fixes

Who is online

Users browsing this forum: No registered users and 8 guests

cron