[Bf-committers] About bug 675 - Analyse and possible solution

[Stephane SOPPERA]

Hi,

I think I've found the reason of the bug 675. Here is the comment I've 
added to this bug in the tracker:
"
Root Cause Analysis of bug 675 
(http://projects.blender.org/tracker/index.php?func=detail&aid=675&group_id=9&atid=125)

The assertion in MT_Vector3::operator/=(double) () is due to the fact 
that in member function IK_QJacobianSolver::Solve, the vector goal_dir 
has a null length.

This vector has a null length because g_position and 
segs[0].GlobalSegmentStart() are both [0,0,0].

This happens because when the IK constraint is created, after the user 
has setted the armature as Object parameter, the bone setting is empty. 
That leads to get_constraint_target function to return the position of 
the armature as target. This target is the g_position parameter of 
IK_QJacobianSolver::Solve function.
The function get_constraint_target returns the position of the armature 
because it calls constraint_target_to_mat4 function with an empty 
substring parameter (because the bone setting of the constraint is an 
empty string). And the code of get_constraint_target returns the 
position of the armature when this string is empty.

As a conclusion, the assertion occurs because when a user creates an IK 
solver constraint using another bone as target, it has first to specify 
the Armature as Object of the constraint and next the bone. But before 
he can specify the bone, the constraint is evaluated with bone == "" and 
that make the constraint use the origin of the armature as target.




Proposition of solution?
I don't know the armature code, so I'm not sure the following solution 
makes sense.
There can be many situations where g_position and 
segs[0].GlobalSegmentStart() are close to each other. When 
goal_dir.fuzzyZero() is true in IK_QJacobianSolver::Solve the constraint 
should be displayed in "red"; the same way the track-to constraint is 
displayed when the axis settings are incompatible.
Another solution (that I've tested) is to consider it to be a normal 
situation to have goal_dir.fuzzyZero() true, and to add the following 
code in IK_QJacobianSolver::Solve just after goal_dir has been computed:

if ( goal_dir.fuzzyZero() )
  return false;
"

As I don't know the armature code, I'm not sure the solutions I found 
are valid or not.
At least the test of goal_dir for fuzzyZero prevent the assertion.

Thanks in advance for your comments,
 

-- 
Stephane SOPPERA
http://perso.wanadoo.fr/stephane.soppera