FeepingCreature

Worked fine here with VorpX when I last tried it. Note: VorpX is only needed for stereoscopic rendering. Just turn off headtracking in the VorpX settings. (Set HT sensitivity to 0.)

I've been playing with the DK2 plugin a bit more, and there seems to be an issue with looking directly down, where the camera flips wildly even if the headtracker is using quaternions. I suspect some part of KSP converts to Euler angles and back, or something like that? LinuxTrack looks reasonably supportable, but I don't have any device that works with that, so I can't test it. You could try to mod it in yourself - KerbTrack is open source, and it's pretty easy to add new plugins. (The source code is nice and understandable.) Maybe also file an enhancement request to try and get the devs to expose quaternions instead.

If you think this is immersive, try it with kerbtrack and an Oculus Rift...

Good to know it works for you! That's strange though - I don't need FreeTrackClient.dll here. Either FreeTrackClient or the OVR PosRotWrapper should not be needed, depending on which tracker you're selecting. (Neither should be needed if you're using the Unity TrackIR tracker.)

Not sure what feature you mean? KerbTrack should be active by default. Maybe search ksp.log for KerbTrack: entries to see what goes wrong?

Yeah you need TrackIRUnity.dll in the GameData/KerbTrack folder. I think the TrackIRTracker has a fixed dependency on that DLL because the DLL is one of the fancy C# ones, not a native one (the native ones are loaded on-demand). So it'd fail to load the class even though it never actually uses the class? That'd be my guess, at least. I'm not sure why that DLL doesn't seem to be included in the current release. If I remove it, my setup breaks even though I'm explicitly using the OculusRift tracker. By the way, I updated my local fork of KerbTrack to support the interface changes in the OculusRift tracker (thanks pizzaoverhead!) so you can now * recenter by pressing [home] (by default) and also * use quaternions for the head rotation (so you can look straight up/down without getting gimbal lock issues.) Download here! Also includes the missing mystery DLL. I have no idea if this violates some license - if you think it does, sue me. (Or just tell me.)

Really, most of the work was in figuring out that I needed a C stub to communicate with the Oculus lib. The actual interface was nigh-trivial, good work on the abstraction @pizza. (Also: could you add a "reset orientation" function/key to the ITracker interface?) The Oculus SDK really makes this task easy. And all the hard graphics stuff is handled by VorpX. Now the next big step up would be getting the plugin to render KSP via the Oculus SDK completely so we can do away with the dependence on VorpX. But somebody more experienced with Unity will have to do that one.

Hi! I've modified KerbTrack to include support for the Oculus Rift DK2. Note that it does not project the screen correctly! So VorpX or a similar injector is still required. Download here. Feedback appreciated!

I think KSP should transition to deferred shading with float targets (HDR). These are my reasons: * I think to some extent people have become used to KSP's poor lighting model, to the extent that they consider it normal. * With deferred shading, KSP could support large numbers of small light sources more easily (small part lights become effectively free; that is, down to the cost of a (transparent) quad draw with the surface of the area affected by the light source!) Plus, any light source that throws in a thin-ish cone can be done relatively cheap as well, since you just need to draw the cone. * Planetary landings at dawn/sunset look seriously weird. The ground is way too dark. This is, of course, because the ground is lit with boring "angle of incidence dot normal" lighting, when realistically our eyes would adjust to the low-light conditions. Fixing this does not, in principle, require HDR, since cheap tonemapping can be easily approximated, but it looks better with HDR and also requires less finetuning. * Most of the slowdown comes from physics/CPU side. Let's give the GPU something to do. Even Intel cards can run deferred shading nowadays.

From the fact that quickload does not reset your Controller state I assume that you do not approve of the way Quicksave/Quickload currently functions. Be that as it may, it is in the game and as such it would be nice if you could support it as it is. Maybe add an option to "restore state on quickload"? Thanks.