Simulation speed changes for unkown reason

[hpesoj]

1 is a bit faster than 0 except for the cache invalidation, there 0 is faster. 2 seems to be the worst.

FYI, 2 is the same as 1 currently.

[Marc]

How do I show the counters in the game?
I hit the leter p and nothing happens

P should be doing it. Maybe you have to select the window first, there is something odd with focus I have to figur out. So clck in the middle and then try p.

[Marc]

FYI, 2 is the same as 1 currently.

That's odd then. Maybe it's related to the bug in the performance counters?

[Marc]

Now it fits:



I made the changes for the graph. You should get them by running update.exe

[Julio Jerez]

Ok could no be the worse than I was expecting.
The time is spend in the collision steme doein teh contact calculation.

Ok I will check a few things. But I need the binary that show teh counter so tha I can see the effect of teh modification.

you say you are using a library for collsion queries? OpCode is tha right?

are you collison meshes very dense?
can you use the newton collison trees? I think you show try that an dsee if it is better,

but now what I need is teh binaty that I can run with the visual counters.

[Marc]

just run update, you should get the new binary with the modified graph.

Yes I use Opcode for a few things, but in that scene it's just around 11 max - compared to all those other >900 bodies. I can just remove those thigns from the scene to see if that changes anything. But as far as I can see it, this Narrow Phase graph goes up when bodies start moving. When everything is at rest, it looks like the graphs I post afterwards. When I tell some monsters to move around, that narrow phase graph goes up. I'm not sure if it's important: All opcode-newtonusercollions are static.

Another thing, I tried with my manual freeze commands on and off and compared the two graphs (with the flipped values, they scene actually behaves the same now):




Looks like these calls sitort everything a bit. The large spikes when I invalidate the cache are a bit smaller but therefore there are smaller spikes in between. Don't know what's better though. Maybe I shouldn't just call them at all, makes a cleaner ai code anyways ...

Ah ya, and those graphs were taken from the same scene where everything was at rest. You can see the narrow phase being really fast there, except for invalidate cache frames.

[Marc]

I made that test and removed those opcode-newtonusercollisions from the scene. Now the scene only consists of a usercollision heightfield, ellipsoid bodies, most of them static.

At the beginnging nothing moved, then, when I command about 10 ellipsoid bodies to star moving, the narrowphase suddenly raises. You can see that in the graph below, I captured it right then. When I wait, it slowly goes down again as the units stop moving one after another.

Maybe I should try to profile the heightfield callback or replace the heightfield with a large box.

Surprisingly, the broadphase is always fast, even though I think it still assumes y up while I use z up.

[Julio Jerez]

Ah execnelnt.
I beleive I knwo what it is and and I have a solution.
firt st let us make sure wi have a clean scen for debuging, sicn eyou are using external collision is dificult for me to debug.

you do not need to swith Opcode, but for this test can you just remove those objects and leave teh terrains and the elipsis?

[Marc]

That's what I already did for that graph. It's only the heightfield and the newton ellipsoids.

I can give you that version without the opcode collisions if you want.

[Julio Jerez]

The broadPhase and all other part of ther engine are fine, but the narrow phase is taking lot of time.
in each update, I am getting about 104 colliding pairs give it or take few more,

each body is bieng test against about 8 face of a hight filed,
That would not be a problem, but because the hightfirls is bigger that the AABB of the shape, the collision test is failing and resulting to a more expensive contact calculation that also fail buit waste lots of time.
this is why the Solver only increase a lithe while the Narrow phase spikes.

I can fix this by adding a special case for test againg the AABB of the Face before trying to do generic contact calculation.

The spike are because of the calls to invalidate cache, I am presuming that when you do that you need the advace the world by calling several iterations of world update in a loop in one simulation frame.
This is why you see the first spikes followed by a negative small ramp.
it is no invalidade it is the several calls in a loop.

do not do anything yet until I add the AABB test shape VS face. and let os see who that works.

[Marc]

each body is bieng test against about 8 face of a hight filed,
That would not be a problem, but because the hightfirls is bigger that the AABB of the shape, the collision test is failing and resulting to a more expensive contact calculation that also fail buit waste lots of time.

Hmm, maybe then, it#s not actually your fault but mine. Instead for returning the 8 faces that lie instied the 2d x,y box of collideDesc->m_boxPX, I could as well check for the height of the triangle vertices and retrun only those that are within the collideDesc->m_boxPX[2] interval. I guess that'ld be a little bit more efficient than letting newton always calculate the bounding box around the returned triangles and do that test. I'll try that.

[Marc]

Ok I did that and it works - when the moving units are in the air. Then the narrow phase is almost 0 like when everything is at rest. But when they hit the ground and move around on it, then it's slow again.

So I guess what you could try to speed that up is to do ellipsoid vs aabb of the triangle before doing ellipsoid vs triangle.

Still the previous callback optimization maybe should go into the example - or maybe it is already and I just reinvented it (as I said I took the heightfield code from 1.32 or 1.53)

[Marc]

But it's still odd. If there are 8 trianlges / moving body vs. the moving body's ellipsoid and there are 10 moving bodies, can that take actually 2.5ms? That makes 80 triangle vs. ellipsoid tests which are are few multiplications and addtions and ifs - Even without some aabb test in between it should be faster I guess.

[Julio Jerez]

Good News I added teh AABB polygon shape and teh spike when form arond teh throd horizonat bar, to a bearly over the first bar, thats more two fold in prerformance.
The optimized version should be even better that.

But I have to go to work now, I will write tonigh, an dlet us see what happen.

[Julio Jerez]

But it's still odd. If there are 8 trianlges / moving body vs. the moving body's ellipsoid and there are 10 moving bodies, can that take actually 2.5ms? That makes 80 triangle vs. ellipsoid tests which are are few multiplications and addtions and ifs - Even without some aabb test in between it should be faster I guess.

The thonk is teh for soem reason it is coleting more than 100 pairs, so ther are many static meshes that are touchin teh 10 dynamics bodies.
how many terrain are they in teh scene?

Another test that can help to isolate teh problem more is to leav teh terrains and teh dynamics player tah will defienetly shwo if teh problems in the Heightfield are creation more pairs than they should