Unfortunately the new Newton version crashes some times with the wrapper.
OK, anyway, I've prepared a test case for v. 2.00:
Testcase linkThe archive includes all sources and a release version
Z pushes the ball
My expectations are that the ball rolls normally on those adjacent models, without bouncing on their edges, and doesn't tunnel through the final model - lifted a bit to act as a wall. The latter is achievable by enabling continuous collision mode, but still is not 100% secure (and probably will never be exactly 100% as far as I understand physics engines, but let's say I'd like it "even more secure").
From what I've read on Newton forum, to increase the engine's precision, you have to call its Update function as often as possible. Some students reported that their collision problems were solved after calling the NewtonUpdate() 10 times of their graphics engine framerate. Supposing that this would solve my bouncing-on-egdes problem (I have to ask on Newton forum to make sure), here's the show stopper - in GS you can't wait for shorter time than one frame (graphical frame as far as I understand). From help, subject - wait():
"The shortest wait time is one frame cycle, the longest wait time is (...)"
This means that we can't call your newton_update() function inside for example while(1) { wait(-0.001); } loop, because the time may be less than the frame cycle and won't work this way.
My idea is to write a C++ plugin which would be passed the newtonWorld pointer, then it would spawn a thread (f.e. Boost::Thread). Inside the thread we could have this loop:
double prevTime = 0;
while (!quit)
{
double time = timer.GetTime() - prevTime;
NewtonUpdate(newtonWorld, time);
Sleep(10); // sleep for as shortest time as possible
prevTime = timer.GetTime();
}
I already have a working plugin using Boost::Thread, but I'm not doing the most important thing there - I'm not calling the NewtonUpdate() function, heh.
What could also help could be using the double newton.dll instead of float. If the Newton's author confirms this, I could spend some time on reworking the wrapper to make it support doubles instead of floats. I think it should be a matter of some replacements in the wrapper's code and typedefing dFloat as double. What do you think?
Also check this reply from Julio:
http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=4631&p=33329&hilit=edges#p33329I think that we should update the wrapper to make it support version 2.02 of Newton. Any ideas where to begin?
