Yes - do it in one thread! Namely call the step function from the jme update method (or simpleUpdate) and adjust all geometry data after that.
You can do more complicated stuff to speed things up on mutiprocessor systems (some people like to support that with jmephysics) but in my oppinion that's too much headache for a little performance gain (and on single proc systems you might even loose some speed).
Hey people, I am having the same problem this guy did two years ago and I tried the solution y'all recommended but it isn't working for me. Specifically, I use the slow step function instead of the quick one, and with only a dozen or so objects, a collision will pretty quickly cause a stack overflow in the ODE DLL. I set a ludicrously high Xss value and caused the function that ultimately calls step() or whatever (as well as the rendering logic) to be run in its own special thread, yet the problem is unchanged. Any thoughts? Why do virtual machine designers make it so hard to change stack sizes?!?
That's a known ODE limitation with the step function. The ODE community suggests to use quickStep and/or a high stack size to circumvent it… another possibility would be to replcace alloca calls with mallocs in the natives, but this causes memory leaks and is a lot slower… so there is no really good solution available for ODE based simulations with high contact counts
OH AND ALSO. You suggest that ODE may be altered via the replacement of stack allocations with heap allocations–wouldn't that actually work, and be fast, if a proper custom memory manager were used, like with overriding of operator "new"? Well I guess that is C++ and maybe ODE wouldn't support it… ? Oh well I suppose that's outside your purview anyway since this isn't the ODE forums!