dMassSetCylinderTotal: bad direction number?

[Marcel]

Hello,

I recently (yesterday) switched from ODE 0.9 to 0.11. Another part of code I
got from somebody on the Irrlicht forums now works, but ODE complains about a
bad direction number:
$ ODE INTERNAL ERROR 2: bad direction number in dMassSetCylinderTotal()
once I run the code. The "direction number" is 3, so it's actually not that
bad:
$ dMassSetCylinderTotal(&wheel[0].mass, 30/*kg*/, 3/*z axis*/, 0.45f, 0.34f);

What can I do about this? Might something else have caused the error?

--
Marcel

[Daniel K. O.]

Marcel escreveu:

> What can I do about this? Might something else have caused the error?

My guess is precision mismatch. Make sure you are using dSINGLE or
dDOUBLE properly when compiling your code.

--
Daniel K. O.
"The only way to succeed is to build success yourself"

[Marcel]

Am Wednesday 18 March 2009 12:49:04 schrieb Daniel K. O.:
> Marcel escreveu:
> > What can I do about this? Might something else have caused the error?
>
> My guess is precision mismatch. Make sure you are using dSINGLE or
> dDOUBLE properly when compiling your code.

Ha! Thanks Daniel! :)
I have to define dDOUBLE by hand in my code since the debian package gets
compiled with double instead of single precision since 0.10. That gets my
code finally running again - leading to my next question. :/

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4
() [../../include/ode/odemath.h]

That happens about half a second after the trimesh collided with a cylinder
(standing on it's side like a wheel) and is lying on the groundplane.
What might I have to change in my vertexes/indices?

--
Marcel

[Oleh Derevenko]

This error can be a consequence of variety of different problems: incorrect
input data or model setup or instabilities in the system (resulting in
value growth to infinity, then NaNs, then normalization errors), bugs in teh
code, after all. The problem is that ODE does not have sufficient amount of
assertion checking in simulation stepping code. This assert is just the one
(and, probably, even, the only!!!) which catches model issues. But it
usually catches the problems very late, when all the model is already
completely broken and full with NaNs. I could see it in last two days when I
was checking why latest release does fail to simulate model in my program
while 0.9 did it.

Oleh Derevenko
-- ICQ: 36361783