Pioneer dev forum

It would be nice to have head tracking for Pioneer.

Open source Opentrack project support multiple inputs, from simple paper tracker Aruco, (I use it with Flightgear and it works great!) to Pointracker DIY hat clip with LEDs.

What Pioneer needs is a UDP socket to receive pitch, yaw, roll, and x-y-z offsets. Here's example from Flightgear protocol:
https://github.com/opentrack/opentrack/ ... fg.cpp#L25

Or some sort of generic (I guess) UDP protocol:
https://github.com/opentrack/opentrack/ ... tn.cpp#L26

So, simply six doubles...

I believe these values should be added on top of these changed by mouse/numpad, so that you can switch to rear camera and then take a look around freely using head tracker.

I see there is Early Oculus Rift support project, not sure how this would conflict.

Anyway, I guess this would need:

• Networking library (if Pioneer does not use something already) as a dependency.
  I would suggest boost::asio as Networking TS what is based on asio is coming into C++ standard already.
• Some sort of ExternalTrackingSource infrastructure.
  So that cockpit view could access rotations and translations from whatever external source currently active. No need to "marry" Opentrack, there could be other implementations, although Opentrack is flexible enough by supporting multiple input sources itself.

So, any comments? If I would find time on this task myself, what Pioneer-specific guidance and tips could you give for this issue?

I could only help with git, github, opening PRs and such, if you're not comfortable with that. Fluffyfreak knows the C++ code, and has an oculus rift branch, which sounds like it's a bit in the same domain.

I am about design decidions, not git/github, but I guess concrete questions will come in time if I ever start this.

Now that Oculus repository seems is inactive since 2014...

I suspect most of us don't have much experience with head tracking thingies. At least I'm in the dark regarding it. Only tried it once in E:D without much success, but that was more down to my crappy camera and poor lighting.

This might be interesting anyhow: Server agent

I've used one a couple of times, I don't get on with them personally but there's good/interesting use cases for them at least as a more practical alternative to VR.

@Talkless I also wrote the LibOVR branch :) It was an interesting experiment but always a low priority one for. It really was an experiment, lots of hacking and trying ideas out. It would never have been merged as it was hacked into just barely working as a way of seeing what might be needed to be done. The other reason I stopped was that back in 2014 the Occulus API was frequently going through breaking changes and I didn't want to have to keep rewriting everything until it had settled down.
Now however it is much more stable, however I might prefer to support something like OpenVR instead to get access to a wider range of VR devices.

As for code hints, I guess that you'd want to adapt the `MoveableCameraController` so you could start looking at how the mouse look works in `PlayerShipController::StaticUpdate` which will lead you to `InternalCameraController::RotateLeft` and go from there.
Any kind of head tracking is going to want to disable the mouse look of course so it will need to override that when it is active.

Thanks @FluffyFreak for hits!

Preliminary support of headtracking via joystick axis input has been implemented in PR #4536. I want to get headtracking input via FlightGear UDP protocol working as well, but that will require some additional design work to build an asynchronous method of passing updates into the engine's input system, or simply bypassing the Input system entirely and building a completely bespoke system for it..

Bypassing the input system sounds best to me, go direct into the cameras like I did with the OVR stuff.

After some thought, I'll likely implement an off-thread UDP socket handler that gets queried at the appropriate point by the Input system for the current headtracking state. From there, each headtracking connection (only one to start) gets it's own data structure in the Input system that can be queried at will. Additionally, a VR implementation could register it's own connection for the HMD tracker and handle pumping updates based upon it's own logic.