Trying to find bottleneck in NewtonUpdate

[andylhansen]

I modified the demo, and it runs at a good 30-40FPS even while the collisions are happening. Maybe I need to compile my project with Visual studio 2008 rather than 2010. I had to download 2008 in order to compile the Newton demo. Maybe something different in the way they compile is causing the problem. Otherwise it must be something in my code I need to optimize.

[Julio Jerez]

you can build Newton with 2010, there are project in teh SDK for that. In fact 2010 should be marginally better than 2008 specially in the simd code generation.
also make sure yopu are no running in a separate thread so tha everything is equal?

the same demo in the SDK is running better in teh SDK demo than in yor app, how many bodies are you testing with now?
The only think I can think of is that you migh be compiling in debug mode. Did you checked the compiler settings?

[andylhansen]

I've made some progress. I did some cache optimization in my graphics rendering code, which helped a lot.

I also changed my physics update to simply call this every frame:

Code: Select all

NewtonUpdate(pWorld,deltaTimeInSeconds);

This combined with the optimizations I made in my code allowed my program to run at around 20FPS with 150 bodies, which is about how fast the demos run.

The only problem I have now is that everything runs in slow motion when the FPS drops down lower. Is this a clamping issue within NewtonUpdate? The wiki says it will clamp between 20 and 600 FPS.

[Julio Jerez]

I did not mean to just make one update per frame. I meant for debug porpuse only. you should have the time slice loop as you had before.
time slice with smooth interplation should be good to make the physics run on it own frame rate still at a fix rate,

tell me is the performance on the desktop and the laptop similar now?
also caused the slow down?

[andylhansen]

I think part of the problem was with my timeslice code. When the frame rate would drop, the loop could end up being run several times per frame. I'm not sure how to implement time slice with interpolation. Is there a simple example of how to do this?

Performance on my laptop is still better. It can have 250 bodies before it reaches 20 FPS, whereas my netbook could only have 150.

[Julio Jerez]

The laptop/desktop diff now makes more sence because intel core duo are a one to two generarion better than AMD, not only more cache, also more intructions per clock, more internal units, and so on.

the interplation does that, you need to put a limit as to how many iteration will the loop execute.
basically you have two rotation and tow position in you model, and you copy teh conrrent frame to the preveius, and teh new to teh corrent.
then you graphics loop using a continuos timesteping and figure out what fraction of the fixed physics time step the graphics time is, then using lerp and slerp calculate the interpolated matrix.

The interalation make more sence when inplemnet he on a separate thread to run asyncronous with teh graphics.
the sdkdemos has a sample of that and also encapsulate a dThreah class to help with that.

[Stucuk]

Having the newtonupdate in a seperate thread gives you a constant rate, but you do then have to make your code thread safe.

[andylhansen]

I will look into adding threading. I think I've optimized it as much as I can currently. I overhauled my rendering loop. I think I just need to avoid making huge piles of objects. The boxes in my app were larger than those in the demos, so there was a lot more collision going on than what was occurring in the demos.

I randomly got this debug assertion though. : _ASSERTE (dist2 > dgFloat32 (0.0f)); in the file dgMinkowskiConv.cpp on line 2117.
I don't know what this means. Any suggestions?

[Julio Jerez]

The assert is inevitable when using a Minkosky asum lgorithm with bith and small convex shapes.
Minkosky is a steepest descent algorithm and in the present of big and small numbers the lost of presicion makes it stops in a local minimal.
the only way to solve that is by using adaptive arithmetic, and currentlly newton 2. does not supports that.
besically what you get is a collision penetation for one frame. It ussually recovers.

[andylhansen]

So the solution to the assert is to run it in release mode? Is there a way I can turn off the assert while in debug mode?

[Julio Jerez]

you can commnetd it out temporarrily,
i leave it because some day I will probable make it better by either, writng a version that uses dapative aritmentic, or a simpler version tha use teh fallback call whih use double.

are you using shape with very different aspect ratio in size?

The trick on collision is to have a poweful convex hull algorithm, Newton had a perfect one.
in fact it is the same that is use at the core of the minscosky sum of teh collision system, modifyed so that the contruction is directed toward the origin,
some day I will make it so that it using adaptive arithmetic, and then the collision wil always be perfect.

[andylhansen]

I don't think my bodies are that different in aspect ratio. Except maybe the ground, which is a thin, wide box. My dynamic objects are pretty close to cubic. I will just comment out the asserts.

[Julio Jerez]

yes the assert would be happening when a small box hit teh large thing box.

what happen si the depenet o what faces at touchiong the net result is a very thong conve hull with very long quasy flat faces, and teh float presition is no en ugh to register if a very big flat face has zero curvature.
so it terminate on a face the is not a face of the conve hull form by the mink sum, but the the contact calculation find the some points are in fact cross the plane.