[ODE] Problems with CVS/Unstable

[Peter Kyme]

Tanguy Fautre wrote:
> Peter Kyme wrote:
> 
>> I've just been trying to update my code to work with ODE unstable from 
>> CVS, from using a patched version of ODE 0.5. I've encountered the 
>> following problems.
>>
>> - The new dRandInt seems to cause stability problems in certain 
>> situations. I've specifically noticed a problem where an aMotor 
>> attached to a ball joint will become extremely unstable when a high 
>> value for max force is given. This problem disappears entirely if I 
>> revert dRandInt to the old version.
> 
> 
> The dRandInt in the UNSTABLE branch is broken and should be replaced by 
> the new one already in the STABLE branch.
> 
> This is something that has been on my todo list for months, but never 
> had the time to (this is not the only patch that has been applied to 
> STABLE but not UNSTABLE).
> 
> It is probable that within a month I'll need to work back on ODE source 
> because of the project I'm working on. So if you can wait...
> 

Ok, I grabbed the latest STABLE misc.cpp and that fixed the problem I 
was seeing.

>> - The dEpsilon configurator.c patch applied a couple of months ago was 
>> applied to MAIN, but not UNSTABLE where it's needed..
> 
> 
> As Rodrigo already pointed out, try the autoconf. The configurator.c 
> method in UNSTABLE is being deprecated (not officially though, but due 
> to the lack of time to maintain both build systems).
> 

I get the following errors when running make using autotools on Redhat 9.

/user_data/RND/ode/unstable/ode.test/drawstuff/src/libdrawstuff.a(drawstuff.o)(.text+0x733): 
In function `Texture::Texture[not-in-charge](char*)':
/user_data/RND/ode/unstable/ode.test/drawstuff/src/drawstuff.cpp:250: 
undefined
reference to `gluBuild2DMipmaps'
/user_data/RND/ode/unstable/ode.test/drawstuff/src/libdrawstuff.a(drawstuff.o)(.text+0x905): 
In function `Texture::Texture[in-charge](char*)':
/user_data/RND/ode/unstable/ode.test/drawstuff/src/drawstuff.cpp:250: 
undefined
reference to `gluBuild2DMipmaps'

It's not a big deal for me, I'm happy to patch the configurator.c file 
manually. I just figured if both build systems are currently still 
available it would worth keeping them up to date.

>> - In amotorSetEulerReferenceVectors, joint.cpp:2378, a line is 
>> commented out that checks if the aMotor has an associated body. This 
>> means you get a segfault if you do a dJointSetAMotorMode before 
>> attaching the joint to  a body/bodies.
> 
> 
> As far as I understand, in ODE it's however illegal to set up joint 
> parameters before the joint is attached to its bodies. Can anyone 
> confirm this?
> 
> If so, then it's probably better to get a segfault than a silent error.
> 

If it is the case that you have to attach the joint before setting 
parameters, I haven't experienced any problems setting the parameters 
first (with the exception of anchors/axis).

Thanks,

Peter