Hi there!

So in my last thread i realized, that I had introduced a problematic bug in form af a bad basis change of the inverse inertia tensor. That got fixed. But my engine is still behaving oddly. It's mostly based off the Ian Millington Cyclone engine, but with my own modifications especially in terms of creating the contact manifold.

Currently we only have one object (the OBB) which collides with static AABBs. The videos show the actual contact points (white squares) and their normals (yellow lines). I do have problems with several parts of the algorithm

The object currently has the following INVERSE inertia tensor:

inverseTensorIntertia = {	0.09f,0.0f,0.0f,
							0.0f,0.28f,0.0f,
							0.0f,0.0f,0.12f }; 

When I only apply the position and orientation corrections it looks like this (seems to be working):

Whenever I enable the velocity correction, the object spins slowly even though no forces should be applied but gravity:

Further more if I apply a bit of force to the object (outside the center of mass) still not using friction, I end up with endless rotations:

Whenever I do apply the friction contact impulse calculation, everything lives it's own life:

If you want to “scroll” through the code it's here:

If anyone can help me just get in the right direction, I'd love it. I've added some debug visuals since the last time, so everything should be easier to get.

It looks to me to be a problem with the location of the center of mass, which causes the collision to behave in a non-realistic way. I would double check that the center of mass is at the correct position, and that any COM→contact point vectors are in the right coordinate system. It may also be an issue with the inertia tensor, if you don't account for the COM correctly using parallel axis theorem.

@Aressera Thank you for the pointers! I'll experiment tomorrow! :-)

@Aressera

The red square in the middle is the center of mass, and it follows the object around. I'll probably check the vector from the contact point to the center. The vector should be in world space, right?

Since the contact points seem to be correctly computed and the center of mass seems to be correctly computed (for ease it's the center of the object) i decided to check out whether the math behind the WorldTransformMatrix was incorrect. But it wasn't.

The way I rotate the inertiatensor by the WorldTransformMatrix doesn't seem to be where it's wrong either… Hmm.. But it does really seem that rotations/torque are being calculated badly.. So far I haven't found the culprit

I'm a bit at a loss. I discovered an error in the computation of the angular correction in the position/penetration resolution part of the solver, but it didn't fix the endless impulse buildup.

(frictionless mode)

I've gone through the code. Last thing I'll try is to update the relative contact position (to COM) between the penetration solver and the velocity solver

My guess is that the bug is in the collision resolution.

On the last video, the box spins along its long axis. Integration respecting inertia looks right.
But when a corner hits the ground, even without friction, the impact should counteract the spinning. But it looks like the opposite: The impact accelerates the spin.
Looks like a wrong sign, wrong order of cross products, or something like that.

Maybe it helps to compare with anther resource beside the book. I had used this back the day: https://chrishecker.com/Rigid_Body_Dynamics​

@JoeJ I think you're right.

To simplify the whole thing i chose a cube instead, and set the inverse inertia tensor diagonals to that of a sphere (0.5 & 0.5 & 0.5).

And without friction the cube still behaves weirdly and accumlutes some velocity

I'm getting more and more certain, that's it's a combination of the torque part of the impulse calculation in relation to perhaps the iterative solving method.

Notice how the box rotates without any forces to apply, but only to a certain degree, then it stops. It's only processing two contactpoints out of the four before the solver thinks there are no changes to the impulses for the last two contacts.

That last rotation part seems to be related to the position correction.

I think I'll try the more simple method in the Game Physics Cookbook and see what results i get.