OVRInteractionComprehensiveRig: Keeping Hands Active While Controllers Are Available
The problem was a VR experience where hands had to stay as the main interaction model, but controllers still needed to exist for a few explicit actions. I did not want picking up a controller to make the hands disappear or disable the hand interactors.
The useful setup ended up being two separate pieces: enable simultaneous hands and controllers at the camera rig level, then make the interaction rig stop treating controller state as the thing that decides whether hand interactors are active.
Camera Rig Settings
In the Meta XR project settings, the important values were:
Hand Tracking Support:Controllers And HandsSimultaneous Hands And Controllers Enabled: enabledLaunch Simultaneous H&C On Startup: enabled

This makes the runtime allow both input sources. Without this part, the rig cleanup does not matter much because the platform is still allowed to switch modes in a way that hides the hands.
Interaction Rig Cleanup
The second part was inside OVRInteractionComprehensiveRig.
For this project, controllers were not meant to become a full interaction system. They were only fallback inputs for specific buttons or actions. Because of that, I removed the controller interactor groups and kept only the hand-focused interactors.
The important part was also removing the ActivationStateGroup dependencies from the remaining hand interactor groups. Those activation gates were useful for the default comprehensive rig, but in this setup they made hand interactions depend on controller/hand mode decisions that I did not want.

The final version kept the hand interactors active all the time:
HandPokeInteractorHandGrabInteractorTouchHandGrabInteractorDistanceHandGrabInteractorHandRayInteractor
That kept hand tracking visible and functional while the controllers remained available for narrow input cases.
What This Avoided
The default rig is useful when controllers and hands are both treated as full interaction modes. That was not the behavior I wanted here.
This avoided a mode switch where grabbing or using a controller could make the hand-driven experience feel like it had been replaced by a controller-driven one. The controllers still existed, but they did not own the interaction rig.
Reuse Notes
I would reuse this pattern when:
- Hands are the primary interaction model.
- Controllers are only needed for a few button-driven actions.
- The project should not expose full controller grabbing, ray, or poke interaction.
I would not use it unchanged if the project later needs complete controller interaction again. In that case, the removed controller interactor groups and ActivationStateGroup setup need to be reviewed instead of assuming this stripped rig is still the right base.
Have a question about this note?
Share the note where it fits. X opens with a question draft; LinkedIn shares the article link.