Problem with 3d impulse and collisions

K^2

I don't know if this is a cause of your problem or not, but I haven't found any other issues yet.

Forces are equal-and-opposite on the two boxes. So you can compute force on both in one go. But that's not true for torques. The torques are only equal-and-opposite around common origin. But torque around center of mass of one cube will not be equal to minus the torque around the center of the other, because you just changed the origin around which torque is measured. It's a relative quantity.

Anyways, a better way to handle this, and it might be a good idea in case you decide to have more objects later, is to make this call for each cube, and compute forces and torques for current cube only.

Alternatively, you can try to figure out the torque on the second cube within your code, but you'll need to create x/y/z_torque2 from rax/y/z crossed with -x/y/z_FORCE, where rax/y/z are redefined relative to other.x/y/z.

I can only venture a guess that at your chosen location, the torque around first cube's center is zero, but not around second cube's, and that might be the reason they rotate through each other.

But it might be something else. I'll take another look through the code to see if I find anything else.

1101

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

When it rotates through, does it push off the other cube at all? Or just passes through freely?

1101

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

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:

Code:

rax = ((rt1*xt1 + rt2*xt2)/(rt1 + rt2));

Should be:

Code:

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

Ok, here is another one. This will mess up the forces, allowing spheres to pass through each other under certain conditions.

Code:

                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:

Code:

                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

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

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

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.

Similar Threads for: Problem with 3d impulse and collisions
Thread	Forum	Replies
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

K^2 Recognitions: Science Advisor	When it rotates through, does it push off the other cube at all? Or just passes through freely?