Skip to content

Instantly share code, notes, and snippets.

@mackandelius
Last active May 23, 2024 20:34
Show Gist options
  • Save mackandelius/27de0b0e2067fdab12d9e2f864a05d89 to your computer and use it in GitHub Desktop.
Save mackandelius/27de0b0e2067fdab12d9e2f864a05d89 to your computer and use it in GitHub Desktop.
Oculus Rift CV1 as Full body tracking

(This is a guide that I can in the future link to because I spend far too much time writing this over and over again.)

Summary:

Reusing your old Rift or a second hand Rift for Full Body Tracking (FBT) is a good and cheap solution for FBT. With three touch controllers (legs and hip) it is akin to Vive trackers in tracking quality, while being superior with its AA batteries, which allows you theoretically infinite battery life. (PLEASE USE RECHARGEABLE AA BATTERIES)

Required Hardware:

  1. A full kit Oculus Rift CV1 (Rift headset, 2 sensors, 2 touch controllers). We need the headset plugged in and active as it contains the wireless stuff requred for the controllers, it is basically our wireless dongle in this case.
  2. Any other VR headset, except a Rift S or another Rift, to be your primary, on head, VR headset.

Optional Hardware:

  1. A third touch controller to be your hip tracker (using the VR object functionality that the Rift CV1 has)
  2. A third sensor (more can be added, but diminishing returns and potential USB bandwidth issues make three sensors the ideal amount)

Required Software:

Here comes a choice, you either use Driver4VR or OculusTouchLink.

1a. Driver4VR (D4VR) is generalist hybrid tracking app that does Rift CV1 FBT as well. Its CV1 FBT is very simple to setup and use, but it costs money (available on Steam). And comparing the tracking quality between D4VR and Touchlink leaves some to be desired, not a bad solution though, because of how easy it is.

1b. Amethyst with CV1 plugin, Amethyst is the evolution of K2VR (what you'd use to use a Kinect for FBT), but it also has plugin support, so one of the contributors to OculusTouchLink developed a plugin for it. You get the performance of OculusTouchLink, ease of setup and a very nice interface.

1c. OculusTouchLink is a github project that originally was made for using the CV1 touch controllers with any other headset. Later forks of the project added the abillity to make use of it as a FBT system instead. Performance wise it is the best we have right now, its only downside being its more complicated setup.

--

2 . OpenVR-Spacecalibrator to sync your Rift and other headset's playspaces together. https://github.com/pushrax/OpenVR-SpaceCalibrator/releases/tag/v1.4. If using Driver4VR then you could use its calibration instead, but results vary. In my experience SpaceCalibrator does a better job.

2b . Quest headsets require the use of either Virtual Desktop or ALVR because the Oculus software can only handle a single Oculus headset. Virtual Desktop and ALVR also possess a essential feature (that Link and Airlink lacks) called Stage Tracking. This will allow you to keep your spacecalibrator sync for many hours and even between play sessions, assuming you only ever setup a single guardian. If your Quest requests you make another guardian then first try covering then uncovering the cameras with your hands. Worst case, where you can't make it remember, you will have to set it all up (guardian and calibration). Firstly start by setting a temporary guardian and then go into your Quests settings to clear the guardian cache and set a new guardian. Not clearing the guardian cache would leave your Quest with 2 guardians and if it ever suddenly remembers the first one then your calibration will be off, again.

--

3 . Some way of keeping your Rift from going to sleep:

3a. A way called the sensor glitch is shown in the Driver4VR tutorial video listed below, which uses a bug with the setup screen to turn off sleeping, causes lowered tracking quality for all but the "primary" controller (last controller you pushed a button on), it is still usable but you will have to judge if it is good enough for you.

3b. The best way, in my very biased opinion (because I am one of the contributors), is a program called ODTKRA (Oculus Debug Tool Keep Rift Alive) https://github.com/DeltaNeverUsed/ODTKRA ODTKRA makes use of a button in the Oculus Debug Tool, "bypass proximity sensor", which turns off sleeping for 10 minutes, which makes the tracking quality as good as it normally is. To keep this lasting forever it flips that switch on and off again every 10 minutes, to not get into the technical, it is basically a macro (a script that presses buttons in a certain order) that ONLY affect the Debug tool and it functions with the Debug tool minimzed.

3c. If using Amethyst with the CV1 plugin, then there is a toggle inside its settings that enables ODTKRA functionality (Personal experience is that is crashes Amethyst right now though, may be a my machine problem.)

Setup video tutorials for each program:

Driver4VR: https://www.youtube.com/watch?v=gwuQrF8-R-4

There is no video for Amethyst with the CV1 plugin yet so here are the links for what you will need: https://github.com/KimihikoAkayasaki/plugin_TouchLink https://k2vr.tech/

OculusTouchLink: https://www.youtube.com/watch?v=zXJ48XRoYkc

Mounting ideas:

Go to the Driver4VR discord channel in #oculus-rift-body to see more examples.

For hip this is how I mount it: https://cdn.discordapp.com/attachments/884702889220636673/974420685877289000/20220512_231937.jpg

For feet I have mounted it in two ways, with soft shoes and without: https://cdn.discordapp.com/attachments/884702889220636673/930149118347735070/20210922_201626.jpg [TODO TAKE PHOTO OF CURRENT ELASTIC BAND]

Optional optimization stuff:

The installation of https://github.com/ItsKaitlyn03/OculusKiller or by replacing the OculusDash.exe with either a notepad document saved as a .exe file or by renaming ODTKRA to OculusDash.exe will turn off the Oculus Dash, which is the primary cause of performance overhead with this FBT solution


By default the touch controllers will enter sleep after a short time of immobility, which freezes tracking. Exiting sleep requires that a button is pressed, unless you turn off sleep mode entirely using a debug command. This debug command is permanent, until turned off, which means it will last between reboots, so you only have to do it once.

Go to Oculus\Support\oculus-diagnostic, the same folder where OculusDebugTool.exe exists, in there another program called OculusDebugToolCLI.exe exists, this is a commandline tool that while underdeveloped, does include a few options that the regular debug tool does not.

To turn off sleep, type in, "server: Touch.DisableSleep true" and press enter, that is all you have to do. To turn it off type in the same command but replace true with false.

Warning, in my testing heavily increased standby battery drain has been observed when sleeping is turned off, could be related to if any button or joystick is being active, but be aware and if you want to preserve batteries, then remove them after playing.


Random problems.

  • If tracking stops entirely and all devices in the Oculus software are orange then you will need to unplug the headset's USB and restart the Oculus software, easiest way is using Oculus Tray Tool as then it can be done with a single, easy to reach, button. I have no idea why this happens, but it is very random and doesn't seem to affect everyone.

    • Addendum, you don't entirely need to restart the software entirely, just exit out of TouchLink (or with Amethyst, clicking the disconnect button) and then unplugging and replugging the headset.
  • If tracking starts randomly jumping all over the place, then the only solution seems to be setting up the headset again, you can fortunately skip the the setup (although you might need to do the setup up until it asks you to put the headset on your head and then go back).

  • Rarely the tracking may decide to offset itself, this will either be permanent, or just temporary, so wait a minute or two before redoing space calibration. My theory is that this bug is caused by the algorithm meant to handle fixing the tracking in case one of the sensors are moved, without screwing up the entire playspace, it is probably also the reason behind the problem above where tracking entirely freaks out.

@Mentheus
Copy link

You missed a dot in your CLI-Command:
"server: Touch.DisableSleep true"

@mackandelius
Copy link
Author

You missed a dot in your CLI-Command: "server: Touch.DisableSleep true"

Thank you, changed it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment