XR Workflows

XR workflows are for projects that need headset input and interaction. The listener → gate → executor shape is unchanged; the bricks source their data from XR trackers and drive the XROrigin3D rig. XR bricks are Pro tier. The set is deliberately consolidated — one brick per concern instead of dozens — so a full VR loop stays readable.

Note

XR bricks build and wire like any other GDLink brick, but headset-specific behavior is validated manually on hardware as a release step. Test on your target device before shipping.

Starting a session

XR Session owns the session lifecycle — initialization, shutdown, world scale, orientation reset, interface switching, and hardware feature toggles. Nothing else calls XRInterface::initialize(), so most XR graphs begin here. The canonical init wiring:

Always -> State Gate(state 0 = "needs init") -> XR Session(Initialize) -> State(remove 0)

Reading the player

There are three input listeners, each consolidating what used to be many bricks:

XR Input — one brick for every controller across Quest, Vive, Index, and others: buttons, triggers, grips, joysticks, and pose. Select the source via mode; irrelevant properties auto-hide. XR Tracking — spatial, skeletal, and biometric state. The tracking_source mode picks the domain: hand gestures, skeletal joints, facial expression, body pose, or boundary/object proximity. XR Ray — spatial raycasting from a controller or HMD for pointer interaction and teleport targeting, in straight-line or parabolic-arc mode, exposing hit point, normal, and collider.

XR Input(source=RightTrigger, On Press) -> AND -> XR Interaction(grab)
XR Ray(source=RightHand, mode=Arc)      -> AND -> XR Movement(teleport)

Filtering with the XR gate

XR Gate is a pure boolean filter for XR conditions — gesture recognition and tracking confidence — with no state mutation or spatial queries (those moved into the executors below as built-in pre-validation).

Moving and interacting

XR Movement is the XR analog of Motion3D — it moves the XROrigin3D for every locomotion paradigm: teleport, smooth slide, snap/continuous turn, climb, and flight, with comfort vignette tied to velocity. Teleport’s slope/fit/collision checks are built in.

XR Interaction handles hand-to-object and hand-to-UI: grabbing, throwing, poking, UI pointing, and AR anchors, with grab weight/lock/distance validation absorbed as pre-checks.

XR Haptic triggers controller vibration — a standalone brick for performance, since haptics fire in tight loops during grab feedback, UI hover, and impacts.

XR Input(grip, While Held) -> AND -> XR Interaction(grab, hand=Left)
Collision(group=Wall)      -> AND -> XR Haptic(pattern=Bump, hand=Left)

Embodiment and mixed reality

XR Avatar drives skeletal and blend-shape data from trackers onto visual meshes — hand-skeleton animation, full-body IK, and facial expression — all following the same read-tracker, write-target pattern.

XR Passthrough controls mixed-reality passthrough: camera-feed overlay, alpha blending, and edge enhancement for blended AR/MR scenes.

Putting it together — a basic VR loop

Always                      -> State Gate(needs init) -> XR Session(Initialize) -> State(remove)
XR Tracking(Hand skeleton)  -> AND -> XR Avatar(hands)
XR Input(grip, While Held)  -> AND -> XR Interaction(grab)
XR Ray(Arc) + XR Input(A)   -> AND -> XR Movement(teleport)

Initialize once, mirror the hands, grab on grip, teleport on a ray — a complete interaction loop with five bricks.

Where to go next

• The full Logic Reference for every XR brick

• The 3D guide — XR builds on the same Node3D movement and sensing bricks

• The Debugging guide for proving XR graphs before putting on the headset