This week I wanted to start to have the crosse (the stick in lacrosse) be attached to the camera as well as be able to rotate based on player input. I think I’ve finally managed to succeed with that; however, it took me a long time to do so, and it needs a lot of tweaking.

It took me such a long time because when I started to work on the crosse script, a component I could just add to the crosse game object, there were multiple problems with the way I was doing things. One of the problems was my transform class. What I wanted to do was set the parent transform of the crosse to the camera, so that when the camera moved, the crosse would update automatically. I had a problem with the transform class though.

In my transform class, I had a Translate, RotateAxis<>, SetRotation, SetPosition, and SetScale functions that would change the local matrix of that object right when you called it. I wasn’t really a fan of how this was going, so what I decided to do was scratch all that and just change the XMFLOAT3 representing position, rotation, and scale when those functions were called. Then later on when GetWorld is called, it would use those XMFLOAT3’s to calculate a matrix that reflected that position, rotation, and scale.

I like this approach a lot better for the most part (there might be some flaws with it in the future), but there was a problem. My camera component would rotate around the origin, which sucks because it wasn’t at origin. This has the effect of orbiting around the origin when I wanted it to rotate where it was. I came to realize this was due to the order in which I multipled my translation, rotation, and scale matrices in the GetWorld function. The order is important because matrix multiplication isn’t commutative.

I originally had Translate * Rotation * Scale, which is no good; instead, I wanted Scale * Rotation * Translation which would result in the rotation rotating at origin, then the translation happening afterwards. For some reason, the scale is all jacked up if I make it happen after the translation, so I put it before the rotation.

Another little thing I had to do with the transform inside my GetWorld function was to switch the order I would multiply by the parent matrix. Before I had parent->GetWorld() * tempWorld, but when I switched it, I got a better result. This scares me a bit because my RTA teacher was the one who told me to do it parent * tempWorld, but it seems to work better when I flip it.

With the transform class working better, I then worked on the input for the crosse. I have it where if you’re clicking the left mouse button, you won’t move the camera with your mouse; instead, you’ll rotate the crosse on its z-axis. I also have a constraint on it, so you cannot rotate it more than 45 degrees or less than 45 degrees. There’s still something wrong with the way the crosse rotates, and I cannot put my finger on it. But this next week I will try to fix that then maybe try to start working on throwing the ball and catching it.