Your quaternion harvesting looks odd to me but if your spaceship expects a

**glm::vec4** with the

**unnormalized** axis as the

**xyz** part and the angle of rotation (in radians) for the

**w** part then... I guess it is ok.

Code: Select all

```
static glm::vec4 Rotation;
auto q = worldTrans.getRotation();
btVector3 v = q.getAxis();
Rotation.x = v.x();
Rotation.y = v.y();
Rotation.z = v.z();
Rotation.w = q.getAngle();
spaceship->MotionStateSetRotation(Rotation);
```

Meanwhile, this code looks kinda redundant with the one above... in that it appears to be trying to set the rotation of the spaceship again but this time using Euler angles. With a broad opinionated stroke I always advise people to stay away from Euler angles (and degrees) when possible but the only alternative is to have a deeper understanding of rotational math and I'm aware not everyone wants to spend the effort required to fully understand it.

Code: Select all

```
static btScalar yaw;
static btScalar pitch;
static btScalar roll;
worldTrans.getBasis().getEulerZYX(roll, pitch, yaw, 1);
yaw = glm::degrees(yaw);
pitch = glm::degrees(pitch);
roll = glm::degrees(roll);
spaceship->MotionStateSetYawPitchRoll(yaw, pitch, roll);
```

I don't have a good feel for what your glitch actually looks like, or what the stream of quaternions with embedded glitches look like so I can only speculate:

**(1)** Bullet uses a fancy math trick for its rotation extrapolation that I don't actually understand so I wonder if there is a bug therein that is causing the problem... but you say you also saw glitchy behavior when harvesting the rotation directly from the Body so maybe this is not the problem.

**(2)** Do your glitches only show up at low angular speeds? Or are they visible even at high speeds? If only at low speeds then I wonder if angular damping is causing it --> try zeroing all angular damping on the spaceship.

**(3)** Are these really big glitches or are they only visible because you have a rigid camera offset to the spaceship? That is... really small angular glitches might not be very noticeable from a stable camera watching a rotating object... but a camera that rigidly rotates with the object at a big offset might "magnify" small glitches purely by nature of the camera's long lever arm. In this case maybe you would need to use smoothed camera motion rather than using the raw data.

**(4)** If your render frame rate is aliasing with the simulation then perhaps you only see the glitches when the simulation takes two substeps instead of just one. You could use rotation math to measure the angle of movement between each frame and look for patterns in that data that correlate with number of substeps. Perhaps knowledge gained from that measurement would reveal a solution/workaround. It occurs to me... if you happen to be using an

**applyForce()** method to steer your spaceship and you are NOT using it in every substep via an

**Action** then I wouldn't be surprised by a rotation glitch whenever the simulation takes two substeps in one step.