Today was a cleanup and alignment day for OXI. I focused on getting the Unity layer to speak in native Unity types and tightening the provider ↔ receiver loop so I can drop components in a scene and see results immediately.

I started with housekeeping. I standardized folders across core and Unity: Interfaces, Classes, and Enums where it makes sense. Core stays engine-agnostic. Unity gets all the MonoBehaviours, inspectors, and adapters. This makes it obvious where new code should live and keeps the dependency flow clean.

With that in place, I refactored receivers. PoseReceiver is now TransformPoseReceiver, and I added RigidbodyPoseReceiver. Both apply local space only, which matches how I actually rig scenes. Transform uses localPosition and localRotation. Rigidbody queues updates for FixedUpdate and applies with MovePosition and MoveRotation after converting from local to world. This gives me stable physics without extra toggle clutter.

I also built a Unity-only provider path. I created InputActionPoseProvider that reads either a single pose binding or separate position and rotation actions and publishes a UnityEngine.Pose. It derives from my existing MonoBehaviourDataProvider, so I can wire it directly into the receivers with the usual provider field. This removed a type mismatch I hit earlier and let me keep the OXI core types on standby without forcing them into today’s scene wiring.

To speed up testing, I generated a ready-to-import OXI_XR.inputactions asset with maps for HMD, LeftController, and RightController. HMD exposes position and rotation. Controllers expose device and aim poses, buttons, triggers, grip, and thumbstick. With that asset and the new provider, I can hook up a camera and two controller objects in a few clicks.

I pruned some stray code while I was there. I removed the unused OXI path-based receiver and sidelined the device-based XRNode pose provider. They were early scaffolding that no longer fits the direction.

The result is a lean Unity layer that works on components alone. XRSession and XRUser remain in core as orchestration pieces for later, but the scene does not require them today. That flexibility is the point. I can author quickly in Unity, and when I need role routing or deterministic ticking, I will host the core session with a small behaviour.

Next up: add a matching velocity provider for linear and angular velocity, then consider a lightweight XRSessionBehaviour once I am ready to centralize role wiring.