Looking for some advice on implementing a first person shooter style camera in a 3d engine. I have a working solution, but I'm starting to think I may have implemented this in a weird way. Currently, I am utilizing a fixed timestep loop and interpolating my camera translation/ rotation / scale.

The translation seems fine, but it's the rotation that's bothering me. It seems that fixed timestep updates and interpolation of rotations yields an unnatural feel when rotating via the mouse. You can feel when you drag the mouse to look around, that something's off like there's either a delay, or that the screen's not exactly where you'd think it would be. The lower you set the fixed timestep, the more apparent this becomes.

My first thought to resolve this was to simply update the camera outside of the fixed timestep loop, however the dilemma I'm facing is that the game this engine will be utilized for requires that all updates happen within the fixed loop so inputs can produce the exact same results across multiple clients.

With that said, how do other games / engines handle this situation (counter strike would be a good example as the mouse input feels very immediate, but the game is processing within a fixed timestep loop)?

I suppose one solution could be to update the camera outside the fixed timestep loop, then track the fixed translation / rotation, using those values for the logical updates, then check every so often that the camera's translation / rotation is not way off from the actual logical translation / rotation…?

Open to any / all suggestions. Just trying to figure out what the best way is to handle this situation.

@mattstone2728 When I say fixed timestep I'm referring to the practice of having a logical loop inside of your render loop which executes at a fixed interval. I believe I have resolved this issue. I moved the camera rotation logic into the render loop so the orientation would always be 1:1 with the user's mouse input. I then have a logical representation of the orientation and position which is updated in the logical loop. The camera's position is set to the interpolation of the previous and current logical position. Appears to be functioning quite smoothly at the moment. We'll see if I run into any unknown unknowns down the road ?

@mattstone2728 Sure! I may just be explaining it weird. Basically it's an implementation of the famous Fix Your Timestep! article. If you want to check out my source you can find it here: https://github.com/vellocet3d/vellocet3d The following project demonstrates using that library and is where the camera controller logic is located: https://github.com/vellocet3d/examples

@mattstone2728 Glad to help! I updated my links as well. If you're browsing through my source keep in mind this is the first “engine” / “framework” I've put together so there maybe oddities here and there. With that being said I have been attempting to make everything as straight forward and easy to read/understand as possible. Currently adding an ellipsoid collider, after that I will do a refactor and draft some thorough documentation.