[ODE] vector has zero size

[Jon Watte (ODE)]

To debug this, you need to figure out which primitive it is that causes 
this problem. It is not a problem that is known in general, and if it 
actually happens, it is a bug in ODE.

I had this happen a while back when a capsule was pushing into a box; it 
turned out to be a division by a denormal number. I patched it locally, 
but the patch was rejected by the ODE community because it hard-coded 
float and double epsilons instead of introducing them as globals.

Cheers,

          / h+


Wouter Mollemans wrote:
> I don't think the problem arises from performing simulations with small 
> ERP or CFM values. To clarify:
> after i call the nearcallback function and perfrom dCollide(), the 
> position of most contact points is completely correct. Only for a few 
> (most often only for one point) a NaN position value is returned. So I 
> don't think that simulation goes wrong.
>
> Best regards
> Wouter
>
> Hampus Soderstrom wrote:
>   
>> Hi,
>>
>> I think the best way to get rid of this is to fine tune ERP and CFM values.
>>
>> If it is a case of exploding simulation that causes this, adding damping 
>> and making sure the mass of objects isn't to small can also help.
>>
>> /Hampa
>>
>> On 18 Oct 2006, at 8:20 PM, Wouter Mollemans wrote:
>>
>>     
>>> Thx I will try to use your solution, but this is of course only a work
>>> around.  Does anyone has an idea what causes these infinite values?
>>>
>>> Is it the collision detection algorithm? I noticed that the collision
>>> algorithm (dCollide()) frequently reports a NaN value for the position
>>> value of the first contact (contact[0]).
>>>
>>>
>>> Alex Green wrote:
>>>       
>>>> Apporx once every 12000 simulations I get the same error. The error can
>>>> be detected. I run a function called 'checkPhysicsForError()' per frame.
>>>> It works as follows:
>>>>
>>>> bool checkPhysicsForError(void){
>>>> dReal *pos = (dReal*) dBodyGetPosition(bodyID of one of my boxes);
>>>> if(!(pos[0]==pos[0]) || !(_finite(pos[0])))
>>>> {
>>>>     dWorldDestroy(world);
>>>>     reset all my stuff
>>>>     create everything again;
>>>>     rewind one test (ie do the one that failed from the beginning);
>>>>     return true;
>>>> }
>>>> else return false;
>>>> }
>>>>
>>>> Notes:
>>>> pos[0] == pos[0] checks for NAN (not a number);
>>>> _finite() is windows, is there a cross platform check?
>>>>
>>>> Cheers -alex
>>>>
>>>> Wouter Mollemans wrote:
>>>>         
>>>>> After some debugging, I noted that some of the collision points are
>>>>> lying at infinity. This causes dNormalize4() to go nuts. Has anyone
>>>>> seen this problem before and do you know what causes this effect?
>>>>>
>>>>> Greetz
>>>>> Wouter
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> In my simulator I try to fit two rigid objects into eachother (a
>>>>>> little bit like a 3D puzzle).  The rigid objects are trimeshes
>>>>>> (around 4000 triangles) and all my joint are of the type contact.
>>>>>> Sometimes this works nicely, but mostly I get following message: "ODE
>>>>>> message 2 : vector has zero size" emmtted by dNormalize4().
>>>>>> Consequently the velocity becomes Nan and my simulation is ruined.
>>>>>>
>>>>>> Is there a solution? Is there a maximum number of triangles that can
>>>>>> be used or what is the source of the error?
>>>>>>
>>>>>> Thanks
>>>>>> Greetz
>>>>>> Wouter
>>>>>>
>>>>>>
>>>>>> --_______________________________________________
>>>>>> ODE mailing list
>>>>>> ODE at q12.org
>>>>>> http://q12.org/mailman/listinfo/ode
>>>>>>
>>>>>>
>>>>>>             
>>>>> _______________________________________________
>>>>> ODE mailing list
>>>>> ODE at q12.org
>>>>> http://q12.org/mailman/listinfo/ode
>>>>>
>>>>>           
>>> _______________________________________________
>>> ODE mailing list
>>> ODE at q12.org
>>> http://q12.org/mailman/listinfo/ode
>>>
>>>       
>>     
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>
>