@Dirk Gregorius,

how do others handle rotational friction?

My objects are locked to rotate around the Y axis but they are spinning like crazy & won't stop

The update to the velocity (using Euler integration) is typically something like this:

angular_velocity = old_angular_velocity + angular_acceleration * dt

You can introduce friction by this simple tweak:

angular_velocity = (1 - something_smallish) * old_angular_velocity + angular_acceleration * dt

That's would be my first attempt. See if that behaves the way you want.

@alvaro,

something like this would be sufficient

but I'd rather define the angular deceleration, times it by the inertia tensor & that would give torque

I could minus torque * dt from the angular momentum then get the angular velocity

4 hours ago, Cacks said:

I could minus torque * dt from the angular momentum then get the angular velocity

angular_velocity = angular_momentum.magnitude/(angular_momentum.dir*InertionTesnsor*angular_momentum.dir)

@Fulcrum.013,

angular_velocity = inverse_inertia_tensor * angular_momentum

better approach

angular_velocity.x = dot(body.inertionlaxe.x,angular_momentum)  / Ix;

angular_velocity.y = dot(body.inertionlaxe.y,angular_momentum)  / Iy;

angular_velocity.z = dot(body.inertionlaxe.z,angular_momentum)  / Iz;

then construct rotation matrix and rotate body locally, respectively to main inertions axes coordinate system.  

total angular momentum is sum of angular momentums for general inertion axes of body. total angular momentum is conservative respectively to global basis.  but general inertion axes are local axes of body, so when body rotates, peojection of total angular momentum vector to body's general inertion axes are fluctuating, that cause angular velocities drift. In case total angular momentum vector have direction that close to middle inertion axe direction, fluctuations magnitude grows rapidly.

I've tried simulating angular friction by defining an angular deceleration but my code is giving odd results

My math must be wrong?
 

Vector3<float> newAngMo(obj->getAngularMomentum() + obj->getTorque() * seconds);
Vector3<float> newAngVel(obj->getInverseInertiaTensor().transform(newAngMo));

if (newAngVel.isNotZeroVector()) {
	Vector3<float> frictionDecel(-newAngVel.normalisedVersion() * Math<float>::PI);
	Vector3<float> frictionTorque(Movement::torque(obj->getInertiaTensor(), frictionDecel));
	Vector3<float> frictionAngMo(frictionTorque * seconds);
	Vector3<float> postFrictionAngMo(newAngMo + frictionAngMo);
	Vector3<float> postFrictionAngVel(obj->getInverseInertiaTensor().transform(postFrictionAngMo));

	if (postFrictionAngVel.isZeroVector() || newAngVel.normalisedVersion().dotProduct(postFrictionAngVel.normalisedVersion()) < 0.0f) {  
		newAngMo = Vector3<float>();                                                                                                                                     		newAngVel = Vector3<float>();
	} else {
		newAngMo = postFrictionAngMo;
		newAngVel = postFrictionAngVel;
	}
}
                
obj->setAngularMomentum(newAngMo);
obj->setAngularVelocity(newAngVel);

13 minutes ago, Cacks said:

I've tried simulating angular friction by defining an angular deceleration but my code is giving odd results

Friction is same force like any other force, so have to use same math to aplly it to body as any other force. In common case it affect both angular momentum  and linear momentum of body. So it have to be added like as any oher forces using law of suming forces and torques. Only exclusion is a sliding rotatoins, bearing rotaions, e.t.c where exists infiinite points of friction contacts at time, that  have opposite linear impulse. 

Keeping track of angular momentum instead of velocity is technically more correct, but since you're doing numeric integration, both are going to give "wrong" results, and updating angular velocity instead is much easier and more stable. You won't be able to reproduce some peculiar motions like these without a more robust integration method anyway.

1 hour ago, d07RiV said:

and updating angular velocity instead is much easier and more stable.

Is really? To handle a collisions velocities have to be recalculatet to momentums and then than back. To apply non-central forces velocities have to be recalculated to momentums and then back. To track rocket thrust velocities have to be recalculated to momentums and than back. Looks like it much easier to store a momentums and recalculate it to velocities just when we need to update position, and use chached velocities until momentums changed again.

1 hour ago, d07RiV said:

You won't be able to reproduce some peculiar motions like these without a more robust integration method anyway.

Its depends from simulation steps per body's turn.

https://www.youtube.com/watch?v=kXwS-3Uy3WI

Also it anycase will be able to produce effects like this https://www.youtube.com/watch?v=hwlwfJMAvYw