I'm looking to create a threaded engine with 3 threads; one for OS input events which I store in a buffer between every tick, one for game logic and the third for rendering. I'm aiming at a constant tick rate with variable frame rate, and the renderer interpolating game states if the tick rate is lower.

Which thread should handle camera rotations e.t.c? I imagine if the tick frequency is lower than the render frequency, then interpreting mouse input and rotating the camera in the game thread would cause camera stuttering and lag, but if the tick frequency is the same or higher then it should be fine? Just wondering what the standard is, and whether I'm overlooking a way to create something independent of tick and frame rates with minimal lag.

I'm also looking to support the Oculus Rift, but I imagine camera control with it will require the same solution for reducing lag as with a mouse.

The input-handling should generally be faster than the rendering and the game logic, as both are probably influenced by the input you get. Depending if the camera-movement are part of your game logic or not, you might want to pass the input through the game-logic thread first or hand it over directly to the rendering.

There is no such thing as a standard here, as it is a design question that depends on a lot of factors. However, in my experience people often start to use too many threads to soon, which will complicate the whole application quite a bit as you need synchronization-mechanisms that work without any performance-impacts. So a small game without too complex processing in it might be better off with one optimized and fast thread than with three threads that block each other frequently.

Thanks for the replies guys. My game won't rely on mouse control as first person shooters do so I'll send it through to my logic thread for handling, and I'll probably handle headtracking directly in the rendering thread.

I'm interested in how fast twitch first person shooters handle this though, do they generally have the logic thread running at >= the frequency of the render thread, or does the render thread handle mouse input and the logic thread read it's latest values e.t.c? What would be the way you handled it?

Also I've got my input event buffer working so I'll stick with it. I'm later looking at making this OS agnostic so having my own event buffer is nice, and this is mainly for learning so why not challenged myself more than I need to :)