Rotation problem in game engine

[adamjmacky]

Hey,

I am making a simple game engine for a university computer graphics course, and I'm running into a (simple?) problem with rotations of boxes. I am using bounding box collisions, where a vertex of the box which enters another box receives a force to push it away.

At the end of each frame, I have 8 force vectors for each box (one for each vertex) to apply to the velocity and position of the box. I could simply apply all forces to the center of the box, and this works fine. But, the boxes wouldn't rotate. I would like them to rotate depending on the location of the forces (which will always be in the 8 corners).

To achieve this, I am trying to get a torque from the force, and use that as the angular acceleration. Then, the angular acceleration is used to increment the angular velocity, which is then used to increment the rotation of the box.

force[8] = force vectors for each corner of the box
vertex[8] = vector from the center of the box to each corner
alpha = angular acceleration (i-component = angle about i-axis)
omega = angular velocity
rot = rotation of the box
pos = position of the box
vel = linear velocity of the box
dt = 0.01 timestep

// find torque and set alpha
for each vertex (i)
torque = force X vertex
alpha -= torque <-- why negative? positive doesn't work at all

vel += force[all] * dt / mass
pos += vel * dt
omega += alpha * dt / (mass*10)
rot += omega * dt

I don't want to have to worry about moment of inertia, since its constant for a box. When I run this, it seems that sometimes the box will rotate properly, while other times the box will spin out of control. I think the problem might be that some of the torques are too strong - am I forgetting something?

Is there a problem with my method? Remember, I'm just trying to get something simple that will run stable for collisions, not a perfectly accurate physics simulation.

 

[cesiumfrog]

I tried doing something similar once.. but if it's just boxes bouncing into one another, I'd recommend trying to use conservation of energy and angular momentum to determine the changes in rotation.

In the same manner, one uses conservation laws to determine how billiard balls respond after collision, rather than trying to integrate a force (since, unless your boxes are slightly squishy like in real life, your forces should all be infinite).

 

[adamjmacky]

I nailed the problem down to the following:

In my engine, the rotation of an object is defined by 3 scalars: angle of rotation about the X axis, Y axis, and Z axis. To display the object, the rotations are applied in order:

glRotatef(rot[X], 1, 0, 0);
glRotatef(rot[Y], 0, 1, 0);
glRotatef(rot[Z], 0, 0, 1);

The problem is that [alpha] describes a rotation about one arbitrary axis, but [omega] and [rot] relate to three rotations designed to be executed in sequence. How can I transform the rotation to the second form?

I found a method online which supposedly does this: performing a rotation about an arbitrary axis by transforming the axis to one of x, y, or z, and then rotating. It didn't work for me, and I think it is because the method is designed to rotate a point - not an acceleration or velocity (if that makes any sense?). Or maybe this method is unrelated to my problem.

Also, I could probably (not tested) store the entire rotation matrix for the object and just apply the rotation each time a force is found, since glRotatef can accept an arbitrary axis. I don't know how I can store the velocity if I do it this way, though (another matrix?). Transforming the single rotation into three would probably be the best way to do it.

Please help if you can. After I solve this little problem, I'm finished with all the features of my engine.

 

[axawire]

you wrote:
torque = force X vertex

Assuming X means cross product.

but Torque=r X F which does not equal F X r

Torque should be a vector and it is this vector you would rotate about. But be careful as forces/torques are only there during a collision (unless the cubes are moving in a field that acts on them).

But as cesiumfrog said you should use conservation of energy, momentum and angular momentum to guarantee your program follows real life physics, otherwise you could end up with cubes accelerating out of control.