Translation Push

When I started on translation, I realized the same code should work.  The opposite delta movement with the inverted future transform, then the old transform to get a swept box collision for the player’s box.

It didn’t work, and when I looked at the values I realized I had it backwards.  That’s why I needed matrices for the negative rotation I was applying, the future / past stuff was backwards.  I switched those around and now I can move and rotate in all 3 axis.

Also the hacky back adjust is to counter the contraction / expansion of an axial box shape as it is rotated.  I figured out a good value to use for that, and that stage is only collided against the model I’m testing, so you don’t get pinched into a wall or anything.

Here’s a vid of me fooling around with a door that is turning in all 3 axis with a movement:

You can see the problems with pre-computed lighting on something that moves and rotates as well.

Also there is a bug that manifests when a model is moving very slow.  If you push against it as the velocity approaches zero, you can push through it.

Pushing bmodels

I decided to tackle the tricky rotating push first, attempting to find a way to flip the problem around into a player box vs bsp trace which I already had reliable code for.

After much experimentation and drawing the boxes, I came up with a reliable way to do it, though there is a bit of a hack that needs a lot of testing.

• Get a transform and inverted transform for the new rotation, but in the opposite direction
• Transform worldspace player box into the backwards rotated modelspace
• Transform again by the old model to world matrix
• Rotate the model forward
• Use the backrotated box as a start, with the old position as end to sweep against the newly rotated model
• Often the start point is in solid, so hackily adjusting the start back along the motion vector is usually needed
• Push the player by the delta of old position and the spot returned from the collision

It is sort of a strange frame of reference kind of problem.  You sort of transform by the inverted future, then by the past to get a box for past to future collision.

BModel Collision

Rotating bmodel collision is quite tricksy!

I got stuck on this one for many hours, and ended up trying a bunch of different ways.  As I keep an inverted model matrix around, I figured the best way would be to transform the ray into modelspace and do the collisions from there.  That’s a start, but I ended up having my player’s box poke way into the side vs some rotations.  It was never consistent.

A simple door tilted in X a bit

The above bmodel is a simple box, tilted a bit, and if I squeezed under it and collided with the edge, I’d have to poke really far in to actually collide with anything.

I realized that the player collision box doesn’t properly rotate when the endpoints of the ray are transformed into model space.  I decided to grab the box corners, transform those into model space (which would be properly rotated), and then take the axial extents of that.  Doing that and drawing it gets you this (though my collision box is messed up, but you can see the general shape):

 

It’s poking in!  And the initial boundary overlap tests succeed, but I still get no collision down in the bsp traversal.

After a lot of frustration and drawing boxes and rays, It eventually dawned on me that my player’s bounding box is not centered!  I use a 16 width by 56 height box centered at the feet.  This was my problem, as the transform into model space often made the box oddly off by a bit that I couldn’t explain.  It was at it’s worst when the bmodel was upside down.  I could walk entirely by on the bottom.

So the basic algorithm I’m using is:

• Transform player boundbox corners into model space
• Axial bound the corners to form a good modelspace bounds
• Recenter the new box on the origin
• Transform ray into model space
• Sweep the box through the model bsp as normal

Now I can collide with models at any arbitrary rotation.  Next step is to enable moving the models with collision.