Problem with 3d impulse and collisions


by 1101
Tags: collisions, impulse
1101
1101 is offline
#19
Jun27-10, 07:46 PM
P: 23
Okay so I changed it so that the torque is calculated independently. Basically the first cube's torque is the cross product of the vector from the point of intersection to its center of mass with the positive force and the other is the cross product of the vector from the point of intersection with it's own center of mass and the negative force. Still the same...


Just to be super clear here's whats happening. If the cubes are lined up and strike each other the velocity of the one that is doing the striking is transferred to the one that's staying still. If the cubes are not lined up and strike each other the velocity is transferred and both cubes will spin a little bit. But if the cubes are placed close to each other and one of them starts spinning it will spin through the other one. I even scaled one of the cubes 50x and it will literally engulf the other one as it spins (i thought for a while that maybe the spheres that make them weren't really touching or something). I should also mention I can see the spheres that compose them and can clearly see them intersecting when I spin them. Another problem is that if I start spinning a cube and then make it collide with the other, they will react in the same way as if the cube had struck it in the same location without any spin.
K^2
K^2 is offline
#20
Jun27-10, 07:58 PM
Sci Advisor
P: 2,470
When it rotates through, does it push off the other cube at all? Or just passes through freely?
1101
1101 is offline
#21
Jun27-10, 08:33 PM
P: 23
It passes through it freely. It does not move it even the tiniest bit. I can rotate the cube so fast that it appears to not move at all and still it will not budge. I think I know why too. It's because with sphere's collision point and the direction of force are always going to be the same (so the cross product between the two, which would give torque, is going to be 0).

I think I really need to somehow incorporate friction into the torque though I'm still trying to figure out how.
K^2
K^2 is offline
#22
Jun27-10, 08:49 PM
Sci Advisor
P: 2,470
No, that's not it. The direction of force is along sphere-sphere center line. The cross product is with a vector going to cube center. These directions will not be the same, generally in cube-cube collision.

Besides, even if torque was zero, there should still be a force pushing them apart in this collision.

First thing I'd do is check your spheres. Do they have correct coordinates assigned to them? It would help if you can render these along with the cube to see what's going on.

And I'll re-check the code and see if there is anything off.

Edit:
rax = ((rt1*xt1 + rt2*xt2)/(rt1 + rt2));
Should be:
rax = ((rt2*xt1 + rt1*xt2)/(rt1 + rt2));
Because the center will be closer to the smaller sphere. But I'm guessing you use spheres of equal radius, which won't make a difference here.
K^2
K^2 is offline
#23
Jun27-10, 09:00 PM
Sci Advisor
P: 2,470
Ok, here is another one. This will mess up the forces, allowing spheres to pass through each other under certain conditions.

                x_normal = xt2 - xt1;
                y_normal = yt2 - yt1;
                z_normal = zt2 - zt1;
                x_OVERLAP = abs(xt1 - xt2) - rt1 - rt2;
                y_OVERLAP = abs(yt1 - yt2) - rt1 - rt2;
                z_OVERLAP = abs(zt1 - zt2) - rt1 - rt2;
                M = sqrt(x_normal*x_normal + y_normal*y_normal + z_normal*z_normal);
                xf = -x_OVERLAP*x_normal/M;      x_FORCE += xf;
                yf = -y_OVERLAP*y_normal/M;      y_FORCE += yf;
                zf = -z_OVERLAP*z_normal/M;      z_FORCE += zf;
You can't decompose overlap in this manner. You should have something like:

                OVERLAP = r1+r2 - sqrt(sqr(xt1-xt2)+sqr(yt1-yt2)+sqr(zt1-zt2));
                //...
                xf = -OVERLAP*x_normal/M;      x_FORCE += xf;
                yf = -OVERLAP*y_normal/M;      y_FORCE += yf;
                zf = -OVERLAP*z_normal/M;      z_FORCE += zf;
The sign error is my own fault, I think. I think I had it the wrong way earlier too.
1101
1101 is offline
#24
Jun27-10, 11:33 PM
P: 23
I made those changes (tnx btw) but it's still rotating through it. I know the spheres are being placed right because I am rendering them (I can swap between seeing the cube model or seeing the sphere's that compose it). They all look to be correctly placed and the way I'm drawing them wouldn't work if they weren't. I know that the cube is not rotating at all (even the tiniest bit) because I am drawing the inertia tensor matrix of both cubes on the screen. When I rotate one cube it's tensor changes but the other doesn't despite colliding. Also even if I am calculating the tensor wrong (I don't think I am) it always has at least three non zero values in the matrix so some kind of rotation should occur upon collision (even if it is incorrect). I've checked several times now through all the code in the game (at this point there isn't a whole lot) and can find nothing that would interfere with the interactions of the cubes in a way that wouldn't be very obvious.

I'm thinking the problem has to be in how I'm calculating the collision normal, the point of the collision, and or the overlap but can't see anything wrong with any of them.

I mentioned before that I might need some kind of friction in place but realized that you were right, the direction of force is from the center of each sphere but the normal is the direction from the point of collision to the center of the cube. This would result in a nonzero cross product for all but 1 of the spheres.

What really bothers me is that I can see the sphere's overlapping and the presence of any type of overlap shouldn't be tolerated. But for some reason in the lack of linear velocity nothing happens, despite the fact that linear velocity isn't even a factor in the collision response.
K^2
K^2 is offline
#25
Jun28-10, 02:22 AM
Sci Advisor
P: 2,470
Oooooo. I think I found it. Coordinates of the spheres. These are just fixed relative to cube, right? So when you take xt1 = x + SCALER*L(LIST_1,0); this is going to give you the same number regardless of orientation of the cube, isn't it? When you render the spheres, you probably just call a transform, so you still make calls to render spheres as if no rotation happened, and the rotation matrix in place takes care of it. But not in physics. So your spheres end up moving on the screen, but not from perspective of simulation.

You need to add a transform that depends on current orientation matrix. So the xt1 will depend on all 3 of the sphere's coordinates, and same goes for yt1 and zt1.

Unless I'm completely wrong and your SPHERE_LIST is already adjusted for rotation, but then you'd probably have origins shifted too, so I'm guessing that's not the case.

Plus, it explains perfectly why there is no collision unless cubes move.
1101
1101 is offline
#26
Jun28-10, 06:52 PM
P: 23
OMFG, thank you so much. It's finally working now.

When you render the spheres, you probably just call a transform, so you still make calls to render spheres as if no rotation happened, and the rotation matrix in place takes care of it. But not in physics. So your spheres end up moving on the screen, but not from perspective of simulation.
btw amazing deductive reasoning there.


Register to reply

Related Discussions
collisions lab-bullet problem Introductory Physics Homework 4
Impulse, elastic collisions and Inelastic... Introductory Physics Homework 14
Momentum, Impulse, and Collisions Introductory Physics Homework 2
Physics Hwk Problem:Collisions Introductory Physics Homework 2
Collisions problem (How should I approach it) Introductory Physics Homework 3