FaceAttribute and NewtonCollisionCollide

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

FaceAttribute and NewtonCollisionCollide

Postby Yezide » Thu Mar 08, 2012 5:36 pm

Is there anyway to get the hold of of the faceattribute when checking a collision using NewtonCollisionCollide?

What I want to do is to check collision between the player collider and a heightmap and need to know the attribute of the face where the collision happens.

For normal collsions handled by Newton I simply use NewtonMaterialGetContactFaceAttribute(), but when I check the collision myself, I cannot call that function.

Any way to do this?

Thanks in advance!
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Julio Jerez » Thu Mar 08, 2012 7:03 pm

There is a way, I do not remember now, but I used in the wiki torials, when making a unified material system.
I will check it to night and come back wit the answer.

are you using the newton 300?
I new functionality I am adding for the nex check in in core 300 in the not only you will be able to get the shape ID, it will also provid the abilty to ge the normal of the adjenct face.
This is specially good for stuff like player controller, where knowing the concacity or convexity of an edge can be useful.

Anyway I will respond tonight.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: FaceAttribute and NewtonCollisionCollide

Postby Yezide » Fri Mar 09, 2012 2:49 am

I am currently using 200 since there were issues with 300 of there not being any collisions (see previous post: viewtopic.php?f=11&t=6894), but it seems like that is fixed?

A new feature seems nice indeed! Tht way it is easier to handle some collision responses.

Thanks for the quick reply!
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Julio Jerez » Fri Mar 09, 2012 12:01 pm

Oh I see what you mean now, NewtonCollisionCollide doe no report the the id of the faces.
bascially teh fuintion need an extra pointe to the face atribute as an argument.

Let us do this, I am goin to add that extra parameter to both core 300, and core 200 and I will check it a new alpha2 of core 300 thsi weekend.
the you can sync to SVN and get core 200.

I am adding huge performance optimization to core 300, specially for meh collision.
now mesh collsion in impul senstive, as oppose to core 200 that only few funtions where imputr sensitive.


for example a sphere/polgon collsion in core 200 and 300 has a time complexity of 1

A campusle is core 200 will have a tiem complexity of 2, plus the tiem tha takle to buidl teh minkusn diff, whji in must case ttally dominate teh collsion test.
in core 300 the complexit is 2 most of the time, with the exception of edge cases that are diffcult to solve geometrically.
basically all convex shapes collision vs faces are proportional to teh number of contact, rather than to the number of points of the Mink sum, whihc can be expensive for round shapes and convex with many points.
This also translate to a much higher quality contact generation.
These change make the aberage collision with terrain literally twice as fast than it was in core 200.

This weekend I will complete the last function that I need condition the collison tree for these new collision method, and I will also complete the Terrain demo,
and I will add the funtion NewtonCollisionCollide with teh new parameter and I add a new alpha to teh downloado. maybe you check it out.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: FaceAttribute and NewtonCollisionCollide

Postby Yezide » Fri Mar 09, 2012 12:21 pm

Great stuff! Thanks!

Will update the svn on Monday and try out 300 while I am it. Will get back and say how it worked.
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Yezide » Wed Mar 14, 2012 8:31 am

Any update on this?

No super rush for my part, but just wanted to check so it is not already on the svn.
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Julio Jerez » Wed Mar 14, 2012 11:25 am

It is taking a little longer, because I was in the middle of the implementation of collision instance.

Over the weekend I re-enabled the height field collision because, you mention that you were using the Height field collision, so that take higher priority, that getting collision collide function.
now I need to complete at least one path for the implementation of instance.
I got that almost fixed. I am using the Box as test case it is almost ready.

In a day or tow I should be able the to enable collision collide with the extra parameters.

These pre steps are important because in Newton three I am placing a big emplaces in the quality of contact generation with polygonal mesh.

In Newton 200 the way this was handle was the each polygon had an extra set in indices to the normal
of the adjacent face to the edge.
then after the contact was calculated, in a post process phase the contact were projected to the Voronoi region of the face.
This works most of the time, but it has many problems.
-when a contact was calculated it is imposable to determine if the contact was a edge, face of vertex contact.
The contact is not always generated from the face features, it is possible to have a contact that is located on the face and yet that contact can be an edge or vertex contact, so rotating it will cause a bad physical respond.
-It can be very slow since face are prosess one at a time all using an expensive Mincousky difference between a face and a convex shape. what happen is that convergence face result in a poor converge o the minkousky solver.

to solve that problem they solution is base on this observation.

-if an edge of a face of a polygonal mesh is form a concave edge then that edge will never generate a contact. Take for example sphere rolling on terrain, if the sphere in rolling on valley,
or a flat plato, the each time in goes for one face to the next the sphere will generate to unique contact, one of each face.
Theses contact are independent of each other and soul not be post processed.
these is not a property of the convex shape, it apply to any convex shape.
if this is true, these means that if we know that the polygon meet that condition, then the can only be Face contacts, therefore the can be calculated by clipping the silhouette
of the convex shape against the outline of the face. and the normal is the face normal.
The process bypass the entire minkousky solve and more importantly it bypasses when it really count, and also generate much better contacts.
Also this apply to all shape as oppsed to core 200 were only few shape has special case contact solver.
This past is all completed now.

-The second observation, which is what I am going to do next week, if an edge is part of two convex face
the concact can be face or edge, but there soul never be contact duplication on each face.
For this the adjacency information will indicate if the edge is convex, as oppose to before that indicate the normal of the other face.

when this is the case now the engine will run a preprocess and making vertex list index list ste of convex caps,
this convex cap are trimmed around the umbra (the project of the shadow of the convex shape) and then send to the minkosky contact solver solver.
The solve will calculate unique contact that will not require any post process conditioning.

This will also have the added benefit that the minskoski solver will have fast converge sine it will be operation on two convex shapes.
In general a steepest descend minkousky solver will have faster converge as the face of the shape are more convex.

the other point is, that collison with polygonal mesh in general should be much faster, and the reason for this is that, in more than 99% of the case the edge of a polygonal mesh are concave,
so the contact solve will be running a simple clipping routine.
what the edges form a converge face, the minkouski solver will be call lees time since face will form a convex cap, and the converge will be faster.
the only addition to the mist is the preprocessing face that will convex the array of face into an array of convex caps, and concave caps.
It will also need a rule to deal with face that are both convex and concave. but this is a matter of separating then.

The reason I mention this is because the user defined collision doe not have the provision for specified adjacency, I will do that later.


I will post here in a day or two when the coolsiion collide is ready for you to try.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: FaceAttribute and NewtonCollisionCollide

Postby Julio Jerez » Fri Mar 16, 2012 1:36 pm

just and update.
I am close to get this going but not quite.
I engaged in making the collison primites an instance object, and I have being making the change gradually. before I try to make it all at once and It was a huge failure. I did not realiced what a big task that was.
now I am doing litle but little, but now I hit the point when the rest of all chnage has to change data type, and that isa big lump of changes that can not be half working. It either all work or it does not.

I have a working version and I beleive I can check it it tomorrow it afte I re enbale all on the demo in teh SDK unit test.
anyway the collision colllide shpoudl be in this monday.

Collision instance is a big, big feature on core 300, and I want to get it over with.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: FaceAttribute and NewtonCollisionCollide

Postby Yezide » Mon Mar 19, 2012 2:44 am

Not sure I understand all the fine details, but it sounds good :)

Will be nice to try out.

A question: How much memory does the collision of a heightmap with sides X take?
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Julio Jerez » Mon Mar 19, 2012 11:35 am

On the terrain, or on any othe collision primitives, other thant the memory used to build the primitives. teh temp mempry use bu the contact solve are all local variable.
I beleive the stack is 32 K for teh mick solver.
The engione bradphase uses a large pool of memory to place the contact are the are calculate par but pair.and that buffer is automatilly expanded
by doubling the size each time the buff reach teh limit, this done but calss dgArray,
thes contact define the initil buffer size when a new intactnce of the world is craeted

#define DG_INITIAL_ISLAND_SIZE (1024 * 4)
#define DG_INITIAL_BODIES_SIZE (1024 * 4)
#define DG_INITIAL_JOINTS_SIZE (1024 * 4)
#define DG_INITIAL_JACOBIAN_SIZE (1024 * 16)
#define DG_INITIAL_CONTACT_SIZE (1024 * 32)

those are all of memory buffer uise bu the engine, In teh pass thre was only one buffer that was use ove and ove on each phase, however after mutiothreading, and continues collsion, the buffer have to be independeng
this because continue collision can call the collision system if it stapme that a step ois too large to be predicted. so resusing the contact buffer for jacobians creat memory conflicts.
the same going for asicronouse threading, from a call back anyone can call a collide function and that can casue problems. Using the 5 inpendent buffers is much simple, elegant and bug free.
that for the phyiscs.
as for the collision primitive, the heighfiled creates a buffer of floats for the elevation, and one of byte for the cell attribute.

Even with all 5 buffer, teh engien is actually very, very frugal when using memory, you can track all o fteh memary use bu the engine using these funtions
int NewtonGetMemoryUsed ();
void NewtonSetMemorySystem (NewtonAllocMemory malloc, NewtonFreeMemory mfree);


last sunday I checked in the fisrt working version of the engine using instance base collision.
I coudl no write teh new version of collision collide, all teh old version for that matter because being in teh middle of that chnage made it impossible.
but now that all teh basic funtionality of teh collision is in, I can re open the collision collide funtion again.
that soudl bo take too long to write since it is wrapper over the exact same function teh engine uses for collision internally.

what I suggest is that you start making teh migration to core 300, ther are many many good reason for that,
however since this check in newton 300 is not longer compatible with 200. so it is no longe a drop in change.
the reason for thsi is that collision are no longe reference objects, now they are instance of anothe collision.

download the SVN demo and run the test so that you can see what I mean. and sometime tonight I will get that funtion ready.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: FaceAttribute and NewtonCollisionCollide

Postby Yezide » Wed Mar 21, 2012 12:24 pm

Tried 300 now and all is working good except for NewtonCollisionCollide which I see is not implemented yet.

I will be using NewtonCollisionCollideContinue meanwhile so the game still works :) (guessing that should work but just be slower)
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Yezide » Wed Mar 21, 2012 1:18 pm

Testing it some more I got some other issues:

- Loading serialized data does not work (seeing now that it is commented out, will this be fixed soon you think? I need it for the map format to work).

- Collision response is more bouncy than in Newton 200, is there some additional param I must set, or this is just something that is not yet implemented?

Apart fro that and the collision collide it woks nicely though, but I will have to go back to 200 until the above is fixed.
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Julio Jerez » Wed Mar 21, 2012 1:37 pm

Yezide wrote:Testing it some more I got some other issues:
- Loading serialized data does not work (seeing now that it is commented out, will this be fixed soon you think? I need it for the map format to work).

yes that is very broken now because o fteh collison instance.

Yezide wrote:- Collision response is more bouncy than in Newton 200, is there some additional param I must set, or this is just something that is not yet implemented?
that does not sound good, they is a bug in the solver that on occasion add energy to the collision responce.
I kept saying I am going to debuget it, and fix it but Ther are so many issue that I kepp delegation that.
It is possible to show a vidio of the behavior in core300, and the same behavior with core 200.
that can give me an idea of what to look for.
also what shape are you using?

Yezide wrote:Apart fro that and the collision collide it woks nicely though, but I will have to go back to 200 until the above is fixed.

I start teh implementation of teh collsioncollide this morning, I added the unit test, and changed the prototype,
but I have not un commnet teh funtion an dmade teh changes so tah it work with intances, inetad of collisions.
I would no uing the collision clllide continues, because if it is commnet it will not work.
bascially is is probably casting and instance to a collision, an for some reason sometime the call works, and some time it just crashes really bad.
I think I will have collison collide ready tomorow morning.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: FaceAttribute and NewtonCollisionCollide

Postby Yezide » Wed Mar 21, 2012 1:53 pm

Another thing I encountered:
- When doing a ray cast sometimes the ray hits a body that I have not created myself. It had collision type 12 and identity matrix for transform.

Will get you that video.
User avatar
Yezide
 
Posts: 173
Joined: Tue Oct 18, 2005 4:31 am

Re: FaceAttribute and NewtonCollisionCollide

Postby Julio Jerez » Wed Mar 21, 2012 2:09 pm

Oh that is the NULL collision.
The engine use a sentinel body with a NULL collision, this simplify many algorithm but it need check in some places so that it is not pass back to the cient app in a call back.
when the changed to instance teh body doe no get teh pointe to teh collsion, insteead it crate a new intance.
So I am guessing the the broadphase it checking if the body collision is equal to sentinel intance and it will not be.
I will chck it out tonight.
Julio Jerez
Moderator
Moderator
 
Posts: 12426
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 0 guests