Simulation speed changes for unkown reason

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Simulation speed changes for unkown reason

Postby Julio Jerez » Fri Aug 21, 2009 11:16 am

Marc wrote:
Julio Jerez wrote: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.


If you are going to do that, you might try the HightField shape, unless you have soem other reasons for using a custom one.
The build is has all those checks aready and planty of precomputes values.
Plus it also has a channel that tell the engine edge information for producing smother collision,
edge can be convex, flat or concave, with the user collision that channel is set to Convex all edges are treated as convex,
meaning they will be par of the collision, but if an edge is concave it can be removed from collision resolution, and if an edge is flat in can be replaced with the face normal.
this preduces moch high quality contact resolution by the solver.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Simulation speed changes for unkown reason

Postby Julio Jerez » Fri Aug 21, 2009 11:22 am

I check the test again from outside the compiler and the spikes are below the firs bar at all time.
without the optimizatiuon they are alway between the secund and third bar,
so it suggest that it codul be up to two and a have time faster. :mrgreen: :mrgreen:
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 11:32 am

There is only 1 heightfield and it's 1025^2 in size.

... and I completely missed that there is a heightfielshape integrated in newton now ... :shock: I'll check that out.
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Julio Jerez » Fri Aug 21, 2009 11:42 am

Only one?

how many dynamics bodies when the scene start?
I am getting 104 pairs and many of then hit with a polygonal static mesh.
Does than means there are about one hinder dynamics boides? Or are thier hitting another static convex shapes?

anyway I will do this optimization an dteh I will check for the other pairs.
It only mean that ther may be more room for improvement :mrgreen: :mrgreen:

But I really need to leave for work now.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 11:55 am

Tehre may be 100 dynamic bodies, look on the map at the lower right. There are red dots, which are monsters and essentially dynamic bodies. Since they spawn over time and the limit is somewhere near 100, it might be that you have 100 dynamic bodies colliding with the heightfield.
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 12:11 pm

I checked NewtonCreateHeightFieldCollision():

Code: Select all
NEWTON_API NewtonCollision* NewtonCreateHeightFieldCollision (const NewtonWorld* newtonWorld, int width, int height, int gridsDiagonals,
                                                  unsigned short* elevationMap, char* attributeMap,
                                                  dFloat horizontalScale, dFloat verticalScale, int shapeID);


I assume width and height is the width and height of the elevationMap and attributemap, horizontalscale is the scale of one elevationMap Pixel to world units or the scale of the whole elevationMap to world units? vertical scale is equivalently unclear. Where is the origin of the created collision? at the lower left corner of the elevationmap and height = 0 or in the center of the resulting bounding box? It's just complicated to experiment all that - so many combinations ;) I tried two: the frist let fall everything down, so it was clearly wrond, the second crashed my app when I tried to add a create with m. :/

Basically I want to acchieve the following scene setup:

I want the heightfield bounding box be (0, 0, 0) and (1024, 1024, 256). The grid is therefore 1025 x 1025, unsigned short with a scale of 1/256 in height. gridpixel to world unit is 1. (0, 0) of the grid should be at (0,0,?) in world space. (1025, 1025) of the grid should be at (1024,1024,?). z up.

Right now I do this:
Code: Select all
        NewtonCollision* collision = NewtonCreateHeightFieldCollision(physics->nWorld, 1025, 1025, 0, hf->p, attrib, 1, 1.0f / 256.0f, 1000);
   float t[16];
   t[0]=1;
   t[1]=0;
   t[2]=0;
   t[3]=0;
   t[4]=0;
   t[5]=0;
   t[6]=1;
   t[7]=0;
   t[8]=0;
   t[9]=1;
   t[10]=0;
   t[11]=0;
   t[12]=0;
   t[13]=0;
   t[14]=0;
   t[15]=1;
   NewtonBodySetMatrix(heightfieldnewtonbody, t);

but this is probably completly wrong because it changes orientation. It also doesn't work in practice :/
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 12:30 pm

I there a way to get all triangles or edges in world coordinates of all bodies in NewtonWorld so I could add some debug visualization as wireframe? Might be handy for this as well for the future.

[edit]I see there is this in the header file:

// NEWTON_API void NewtonBodyForEachPolygonDo (const NewtonBody* body, NewtonCollisionIterator callback);
[/edit]
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Julio Jerez » Fri Aug 21, 2009 12:44 pm

check the file HieghtField collision in the SDK.
I has all the nessesary information.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Simulation speed changes for unkown reason

Postby Julio Jerez » Fri Aug 21, 2009 12:53 pm

Marc wrote: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.

yes teh BroadPhase is fine, we were looking in the wrong Place, But it is all good because we found few Bug and ineficeencies.

The Narrow Phase increases wjn eth usint move because it start to do the work, whoever it does a lot more work than nessesary,
when I put the new Build the base line of the Narrowphase will be less then half of the graph shows, and so will be the spikes.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Simulation speed changes for unkown reason

Postby Julio Jerez » Fri Aug 21, 2009 1:09 pm

Marc wrote: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.


Not it is not because the code that calculated contacts works best for descret shapes, when you have smoth shapes the runtine is much longer,
This is even worse for shapes like Elisoid with high aspec ratio, because the have very high degree on non linearity.
To make and analogy it you polgonize an elisoid you need more texelation for a high aspect ratio elipsis than you need for a sphere.
Since the collision code code builds a partical convex shape from the different of the two colliding shapes,
this parcial convex shape will have a lot more detaill for an elipsiod than for a descret shape.

when I check the loop for a normal shape the collision points betwen a convex shape and a polygon is about 5 to 6 iterations when starting from schatch,
when the last contacts are cached and use as first guess, it does it in about 2 to 3 loops on average.
when I check the elipsod/polygon in your game, it goes as high as 15 loops, and I stop checking there. In the test I did it never was less than 11 loops.
Plus since you flush the cache so much then it almost never get the chance to take advantage of the contact coherance.

Do not worrry this can be eassly solved by special casing the elisoid code.
I can make that better by singling out the elesiod/polygon contact calculation altogether like I do for spheres.
Maybe it will not be a bad thing to write some spacial case collision functions like Box/polygon, Capsule/polygon that works in constant time.

I have all those in 1.3 and I think in 1.5, so I will check this weekend.
But for now let us add the AABB check and see what we get
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 1:51 pm

agreed :)
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 4:24 pm

Is NewtonCollisionForEachPolygonDo() supposed to work on a Newton Heightfield collision? If I try to use that, I only get vertices on one line.
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 4:31 pm

Ah no, it's ok, I screwed up. It's working now.
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Marc » Fri Aug 21, 2009 4:47 pm

hah! with the help of my newly implemented and fixed debug visualization, I was able to align the newton height field correctly - and the high spikes in the narrowphase for newtoninvalidatecache are gone: (note that the scale of graph changed considerably because of the spikes being away. So the graphs look higher but it's the same level as before approximately)

Image

It seems as if a usercollisionmesh takes a lot of time after a cache invalidation.

There is just one thing: Because I use Z up instead of of Y up, I set the following matrix to the heightfield body:

1 0 0 0
0 0 1 0
0 1 0 0
0 0 0 1

It cleary flips the orientation. Is that a problem? It seems to work, but maybe that is just luck? Is it ok to do it like that?
Millenium Project Enterprises - Hobbyist Gamedev Group http://www.mpe-online.org
Walkover is now on Steam => http://store.steampowered.com/app/348700/
User avatar
Marc
 
Posts: 281
Joined: Sun Mar 14, 2004 4:07 pm
Location: Germany

Re: Simulation speed changes for unkown reason

Postby Julio Jerez » Fri Aug 21, 2009 5:57 pm

That is a matrix with a negative determinate; I would change the sign of one of those just to be algebraically safe.
So using the build in heightfield is better, what do you know.
Now all we need to do is to lower the average time, 6000 seems too high still,
This will happen when we fix the ellipsoid/Polygon contact calculation, hopefully tonight.

Now that you have more confident in Newton, you can probably try the collision trees,
one of the advantage over naïve triangles polygon soup queries is that teh collision trees convert the mesh into a soup of large convex faces witch speed up the queries,
an dinporove the narrow phase and the quality of the contact generation.

Many algorithms in Newton seems naive from the outside. But they are the result of many years of experience behind them.
Most people are very skeptical when they start using them, specially with all the slanderism of my name that some people had gratuitostly spread about me
in some forums, but then when they see the difference they become more believers.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests