Continuous Collision crash after Newton 2.36 to 3.04 upgrade

Report any bugs here and we'll post fixes

Moderators: Sascha Willems, Thomas

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby Julio Jerez » Thu Apr 11, 2013 5:52 pm

Cool, now we are going some where,


JoeJ wrote:...
Thus there was some powering even if i turned it off for ragdoll - this causes explosion.
I modified the kine joint so that it returns after the linear rows are set -> no more explosion.
So, (maybe just angular) powering in combination with CCD leads to explosions, even if no other joints are involved, f. ex:
A passive box rests on floor, i pick up another box using joint, and if i push it against the resting box, it flys away with too much speed.
Without CCD this case is fine.
I don't think this is a problem for anyone at the moment.
Interesting is that i was not able to reproduce something like this in sandbox, even when involving kinematic joint.
I can try again If you want.

Please see if yo ucna recrete that, Matbe teher si still a but on the parcial derivative for angular joints.

if it does no explode in teh sandbox, then maybe you joint have a bug, can you replace the code of teh callback of the joint your are using
with you implementation, maybe that can recrate teh bug.

as for relase, I want to add some sort of HPC to teh engine.
I do not, afet checking so many solutions, I am not happy with (Cuda or openCL, or soem of the asshat other intel solutions)
I think that in teh end Microsoft has the best solution with AMP, more important it si all integrated into one IDE
are you using VS2012?

I will see if I can try some thongs in it, that Landa function stuff looks really cool.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby JoeJ » Thu Apr 11, 2013 6:23 pm

I'll reproduce tomorrow. I'm pretty sure i don't have a joint bug, because the explosion happened by using only your kinematic joint also.
(I've also disabled all powering except the hinges to see if the explosion also happens if only one angular row is set - answer is yes).

I use 2012, but so far no interest in c++11, i'm afraid of incompatibilities with other platforms.
Also i was too unsatisfied / lazy to try OCL, Cuda or even OpenMP / AMP for now.
I still design Global Illumination algorithm with 1 CPU core - but hey, it's fast enough for a 32^3 SH light volume in real time :)
First i need to learn now is GPU shaders / compute to put that to practice.

What i often think about is: If soon all gaming CPUs have an 'unused' small GPU - and Consoles have it too - would that be ideal for physics?
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby JoeJ » Fri Apr 12, 2013 11:17 am

This should reproduce.
I wanted to make the 'poorBox' fly away too fast, but instead it's always the joined body who goes wrong - should not matter.
The commented creations of poorBox have similar results.

Code: Select all
#elif 1

   {
      dVector origin (0,5,0);
      NewtonBody* body = BuildBox (scene, 1.0f, origin, dVector (6,1,8));
      CustomKinematicController *kj = new CustomKinematicController (body, origin);
      dQuaternion q (dVector(1,0,0), float(PI*0.5));
      kj->SetPickMode (1);
      kj->SetTargetPosit (origin);
      kj->SetTargetRotation (q);
      kj->SetMaxLinearFriction (500);
      kj->SetMaxAngularFriction (50);
      
      //NewtonBody* poorBox = BuildBox (scene, 3.0f, dVector (0,2,4), dVector (5,2,10));
      //NewtonBody* poorBox = BuildBox (scene, 0.5f, dVector (0,2,3), dVector (3,2,3));
      //NewtonBody* poorBox = BuildBox (scene, 0.5f, dVector (0,2,0), dVector (3,2,3));
      NewtonBody* poorBox = BuildBox (scene, 0.5f, dVector (0,2,0.7f), dVector (8,3.0f,1));
     
      NewtonBodySetContinuousCollisionMode (poorBox, 1); NewtonBodySetContinuousCollisionMode (body, 1);
   }
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby Julio Jerez » Fri Apr 12, 2013 11:40 am

I pasted the code as you posted, and I see a large flat box spinning, but it is no exploding, do I have to do anything else?


I checked it in, maybe you can tell me how to make it fail
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby Julio Jerez » Fri Apr 12, 2013 11:48 am

I noticed that the jointed box gain some unnatural angular velocity, the moment it touché the second box.

It does no explode but that is definitely wrong, there most be another bug in the angular Jacobeans.
I'll see what is wrong with.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby Julio Jerez » Fri Apr 12, 2013 12:27 pm

Ok it is was I was suspecting. remember when mention that the partial derivative of a joint when the time step is zero should disregard the different in location of the tow contact points.

in the Kinematic joint I made a mistake, by making the invTime step 1.0

but the is a huge mistake, because what I am saying is that I want the correct position to change for what is at to the target position in zero time.
this kinematic joint is a special joint tat try to convert different in position to change in velocity, by for the a non zero time is required.

one quick solution is not to submit any road or column, (I check that in as a hack and it work)
later I will see if there is a better solution that freeze the body in place instead of let in free.

sic and test so you can see what I mean.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby JoeJ » Fri Apr 12, 2013 12:44 pm

I'm in a hurry now and will do the sync later.
But just to let you now, i have a #define in my app to return immeadeatly from all powered joints in timestep <= 0.
I've enabled that and the explosions gone away. Quickly testeng this does not seem to have negative impact on simulation.
I'll lookeng closer later...
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby JoeJ » Fri Apr 12, 2013 1:07 pm

I see, i've got you right as you did the same in kinematic joint.
This seems to fix everything - i can smash the powered ragdoll around and nothing bad happens.
I was always experimenting with this because i thought if timestep = 0, there is no time to do anything.
Up to now it never prevented bugs, but now anything is well.
All i do in my app works as expected with that.
How is it with the unpowered parts of the joints (point to point, limits) ?
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby Julio Jerez » Fri Apr 12, 2013 1:28 pm

JoeJ wrote:But just to let you now, i have a #define in my app to return immeadeatly from all powered joints in timestep <= 0.
I've enabled that and the explosions gone away. Quickly testeng this does not seem to have negative impact on simulation.
I'll lookeng closer later...

yes that's always an option, but a more refined solution is to emit rowst that correct velocity difference and ignore relative posistion differences. In the case of te Kinematic joint, it makes sence to skip submition of any row, bacause teh kinematic joint is all about resolving relative position differences.
later I will formized the kenematioc joint, and go over the rest of teh other joints again to see if I missed anything.

On this
JoeJ wrote:How is it with the unpowered parts of the joints (point to point, limits) ?

what do you mean here.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby JoeJ » Fri Apr 12, 2013 4:27 pm

I'll sum up again - correct me if there's something wrong.

A row that corrects velocity would be for example a point to point constraint like in ball and socket (that's what i mean with unpowered).
We should add that row as usual, also if given timestep is zero (also timestep is not used to calculate the parameters for such rows)

A row that corrects relative position differences (a powered row), which requires calculation of some wanted acceleration using timestep,
should NOT be added, if timestep is zero.


And just for some background info...
Zero timstep is given to joint callback only if CCD is used, because only in this situation you use impulsive collisions.
And an impulsive collision differs from the usual case, because it changes velocity directly,
while usual collisions change forces, even if they are not resting contact.

Is that all right?
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby Julio Jerez » Fri Apr 12, 2013 5:12 pm

You got it all correct, yes.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby JoeJ » Sat Apr 13, 2013 5:01 pm

I'm afraid there's on little assert left :)

Code: Select all
#ifdef _DEBUG   
      {
         dgVector e0 (m_hullDiff[1] - m_hullDiff[0]);
         dgVector e1 (m_hullDiff[2] - m_hullDiff[0]);
         dgVector e2 (m_hullDiff[3] - m_hullDiff[0]);
         dgVector n (e1 * e2);
         dgFloat32 volume = e0 % n;
         _ASSERTE (volume < dgFloat32 (0.0f));
      }
      #endif


in CalculateIntersectingPlane

It happens very rarely (don't know why) and i've turned CCD off.
User avatar
JoeJ
 
Posts: 1453
Joined: Tue Dec 21, 2010 6:18 pm

Re: Continuous Collision crash after Newton 2.36 to 3.04 upg

Postby Julio Jerez » Sun Apr 14, 2013 9:57 am

Awesome!
yes that one is very rare, it happens when tow shapes are touching face to face, point the face, or edge to edge, etc., but they do not penetrate each other.
in the case the Gilbert algorithm fail generation unreliable data.
This is what I was not using that method in core 100 and 200.
My method is more robust, but slower.
The code there detect when the Gilbert fail, and I simple build a simple new simple using my method as a fallback solution.
Now the primary method of core 200 becomes the fallback solution for calculation the best separation plane of two convex shape

It is fixed now and checked in
thanks for that, and keep then coming

sync to SVN
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Previous

Return to Bugs and Fixes

Who is online

Users browsing this forum: No registered users and 8 guests

cron