- renderer and physics aren't synced in any way, physics shouldn't be tied to frame rate, but running as 2 separate threads with no synchronization means you might read garbage at some points if you render while the physics thread is updating.

- physics using this_thread::sleep_for is not accurate and can sleep for longer than the specified time, assuming the period to be 1/60 isn't correct. The delta time needs to be measured.

- using VK_PRESENT_MODE_FIFO_KHR or VK_PRESENT_MODE_MAILBOX_KHR force vsync, but vsync can be anything. With the physics system being locked to 60, you'll notice a stutter on non-mulitiple vsyncs like 144hz. There aren't many solutions I know for this, but the main ones I know of are interpolation and extrapolation of the physics state based on the framerate. I would bump the physics update rate to 120hz to match rocket league and then experiment from there.

- Using both Eigen and GLM is overkill in this case, both are slow, but if sticking with one I would use switch solely glm.

- More of a nitpick, but I would separate out all the code at least between rendering and physics to their own independent files. The vulkan api on it's own adds a lot of clutter, moving that to it's own file should make the project easier to navigate and explorer.

There are more things, like how hard coded that shaders are, but I assume the vulkan renderer will be improved past just being from the vulkan-tutorial, so advice for that can't really be given till the renderer has been updated.

P.S. Sorry if any of this sounds harsh, it's not my intention. I've just done a lot of work involving games, game engines and renderers. And I'm seeing a lot of the problems I made when I first started. I wish you the best of luck with your project.

https://github.com/EricLengyel/Terathon-Math-Library