[ODE] problems with trimesh and capsules

[Jaroslav Sinecky]

Memory allocated by dALLOCA16 should be freed automatically when leaving 
the function, see documentation for CRT alloc function. I did this 
change recently so it's not 100% guaranteed to be bug free, but I tried 
to run test_trimesh and test_moving_trimesh with lot of capsules with no 
problem. And revising the code can't see any error neither.

Jaroslav



Paul MacKenzie wrote:
> Are there outstanding problems with trimesh-capsule collisions?
>
> I tried to follow the scarcity of documentation to set up a simple mesh 
> correctly, and it seems to be okay with spheres, boxes and cylinders, 
> but with capsules I get either a stack integrity error or else the 
> capsule jumps into the mesh and ODE complains about trying to normalize 
> a zero vector.
>
> For the stack problem, in _cldTestOneTriangleVSCapsule() in 
> collision_trimesh_ccylinder.cpp, there are several local dVector3 
> variables used.  However, after a few collision checks, it seems that 
> these local variables are being placed within the allocation of the 
> global variable gLocalContacts.  When this happens, of course any write 
> to the gLocalContacts array stomps on the local variables and I get 
> stack errors.  Is gLocalContacts's memory being mysteriously released 
> somewhere?
>
> I tried changing gLocalContact to a heap variable with malloc() instead 
> of dALLOCA16(), and then I get the zero vector error.
>
> I could be hunting all week on this, but before I do, can anyone tell me 
> if their mesh-capsule collisions are working okay?  If so, perhaps I 
> have a subtle initialization problem with the trimesh.
>
> Cheers,
> Paul
>
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>