Eye Tracking in Godot¶

Status: emerging
Last updated: 2026-05-31
Sources: Godot Openxr Vendors Eye Tracking, Godot Meta Toolkit Eye Tracking, Godot Eye Tracking Minor Tools Digest, Godot Eye Tracking Gaps And Missing Integrations, Godot Openxr Eye Gaze Interaction Extension
Tags: [godot, eye-tracking, openxr, vr, xr, plugin, gdextension]

Summary¶

Eye tracking in Godot 4 is functional but narrow. Two actively maintained plugins cover the supported path: godot_openxr_vendors exposes the standard OpenXR gaze extension across vendors, and the W4 Games Godot Meta Toolkit adds Meta-specific per-eye and openness data on Quest hardware (GodotVR contributors, 2026; W4 Games, 2026). Beyond combined gaze direction, the ecosystem thins quickly: there are no native plugins for research-grade trackers such as Tobii Pro, Pupil Labs, or SR Research EyeLink, and webcam options are prototype quality (Anonymous, 2026a; Anonymous, 2026b). For research requiring calibrated, high-frequency, timestamped gaze data, Godot requires custom bridge engineering that has no published validation.

Body¶

Context¶

This article merges five sources on the state of eye tracking in Godot 4: the godot_openxr_vendors repository documentation (GodotVR contributors, 2026), the W4 Games Godot Meta Toolkit documentation (W4 Games, 2026), the OpenXR XR_EXT_eye_gaze_interaction specification (Khronos Group, 2026), and two unverified web-search digests — one on minor tools and legacy plugins (Anonymous, 2026b) and one on gaps and custom bridge approaches (Anonymous, 2026a). They are technical feature digests covering, respectively, the supported plugins, the richer Meta path, the underlying standard, the fringe of community and legacy tooling, and the missing research-grade integrations. Within this knowledge base this is the Godot arm of the per-engine eye-tracking survey: it builds on the shared baseline in Openxr Eye Gaze Interaction, notes SRanipal's archived Godot path detailed in Sranipal Sdk, runs parallel to Unity Eye Tracking and Unreal Eye Tracking, and supplies the data-depth and research-reliability evidence that places Godot last in Eye Tracking Engine Comparison. Each point below is attributed to its source so it is clear where the statement comes from.

Key Points¶

The supported core of Godot eye tracking rests on the OpenXR standard rather than vendor SDKs. GodotVR contributors (2026) document godot_openxr_vendors (v5.0.1-stable as of May 2026), a community GDExtension that wraps vendor OpenXR extensions for GDScript and C#; for eye tracking it exposes the cross-vendor XR_EXT_eye_gaze_interaction extension through an OpenXREyeGazeInteraction node, surfacing combined gaze as a 6-DOF pose on /user/eyes_ext/input/gaze_ext/pose (§ What It Does; § Eye Tracking API in GDScript). Because this is the same extension described in Openxr Eye Gaze Interaction, Godot's baseline capabilities and limits match the cross-engine floor: combined gaze direction at headset frame rate, with no per-eye, pupil, blink, or raw samples. The Khronos Group (2026) specification confirms that Godot 4's own OpenXR module supports the action-map system and can register eye gaze as a pose action, with the plugin filling in full exposure (§ How It Works in Godot 4).

A second plugin adds the only native path to richer data on consumer hardware. W4 Games (2026) document the Godot Meta Toolkit, a GDExtension for Godot 4.3+, which exposes Meta-specific OpenXR extensions through a MetaXREyeTracker node, providing per-eye gaze poses (via XR_FB_eye_tracking_social), per-eye openness (0.0–1.0), eye widen/squeeze blendshapes for avatar animation, and gaze confidence (§ Eye Tracking Features). The division of labour between the two plugins matters for code design: for gaze interaction on Meta hardware either plugin works, but per-eye data, openness, or avatar blendshapes require the Meta Toolkit (W4 Games, 2026) (§ Distinction from godot_openxr_vendors). GodotVR contributors (2026) reinforce a related distinction — Quest Pro gaze interaction uses the standard XR_EXT_eye_gaze_interaction, while XR_FB_eye_tracking_social is for avatar facial blendshapes only, so cross-platform gaze code should target the standard extension (§ Eye Tracking API in GDScript).

Supported hardware tracks OpenXR runtime coverage rather than the plugin itself. GodotVR contributors (2026) report that, through godot_openxr_vendors, Meta Quest Pro and Quest 3 are confirmed working, Samsung Galaxy XR and generic Android XR are supported in the vendor layer, Varjo XR-4 should work through its OpenXR runtime, and Pico 4 Enterprise is only partial because permission handling is not wired up in Pico's Godot layer (§ Supported Hardware (Eye Tracking)). Both GodotVR contributors (2026) and W4 Games (2026) note that the plugins require a runtime permission grant on Android/Meta devices, that calibration is handled by the headset OS rather than the plugin, and that neither provides built-in fixation or saccade detection (§ Known Limitations; § Limitations).

Outside these two plugins, the ecosystem is mostly reference, prototype, or legacy material. Anonymous (2026b) catalogue these: the Sleiphan project is a Godot 4.3 reference scene (not a reusable addon) demonstrating XR_EXT_eye_gaze_interaction on Quest Pro (§ Sleiphan / Godot Eye Tracking Working Example); AgniGames' Asset Library "Blink Detection" addon is a Windows-only, prototype-quality webcam blink detector with no gaze direction (§ AgniGames Blink Detection (Webcam Eye Tracking)); and GDMP wraps Google MediaPipe to estimate landmark-based gaze from a webcam at roughly 30 fps and ~5–10° accuracy, far below the ~0.5–1° of hardware trackers (§ GDMP — MediaPipe GDExtension for Godot 4). The same digest finds the legacy options non-viable: the FAU-Inf2 godot-vive-pro-eye GDNative plugin is archived and Godot 3-only, the SRanipal SDK it wrapped is itself deprecated (§ FAU-Inf2 / godot-vive-pro-eye (Legacy/Archived); see Sranipal Sdk), and the BID-UAM EyeTribe integration targets hardware discontinued in 2017 (§ BID-UAM EyeTribe GDExtension (Discontinued Hardware)); V-Sekai maintains a fork with experimental OpenXR eye tracking, and the mbucchia OpenXR API layer (archived 2024) could once bridge VIVE/WMR eye tracking on SteamVR (§ V-Sekai and Other Forks).

The decisive gaps are for research-grade trackers, where no native Godot plugin exists at all. Anonymous (2026a) report that, as of May 2026, there is no Godot plugin for Tobii Pro (Spectrum, Fusion, Glasses 3) or Tobii consumer devices, Pupil Labs (Core/Neon), SR Research EyeLink, Gazepoint GP3, or Tobii Dynavox (§ Major Missing Integrations (No Godot Plugin Exists)). The same digest proposes three custom bridge patterns to close the gap: a direct C++ GDExtension wrapping a manufacturer SDK (best performance, highest engineering cost); a socket bridge where a Python or Node side-process forwards SDK data over UDP/WebSocket as per-frame packets (claimed ~1 ms UDP overhead, most flexible); and HTTP/REST polling for devices like Pupil Neon and Gazepoint that expose REST APIs (claimed 10–50 ms per cycle, suitable only for non-real-time logging) (§ Custom Bridge Approaches). Its "best current option" for laboratory use is a Tobii Pro SDK Python-plus-socket bridge claimed to reach ~8 ms end-to-end latency, but it stresses that no drop-in solution exists for running Godot as a research stimulus engine with timestamped, calibrated, high-frequency gaze data and stimulus event markers — a capability available out of the box in PsychoPy with Tobii or EyeLink (Anonymous, 2026a) (§ Research-Grade Use in Godot: Practical Assessment). These quantitative latency figures and the absence-of-tooling claims come from a single unverified digest and are treated as emerging.

Conclusion¶

Across the five sources the picture is consistent: Godot 4 has a working but narrow eye-tracking path. The two maintained plugins (GodotVR contributors, 2026; W4 Games, 2026) cover combined gaze everywhere and per-eye plus openness on Meta hardware, but stop short of pupil, blink-by-OpenXR, or high-frequency raw data. Beyond them the ecosystem thins to prototypes and dead legacy plugins (Anonymous, 2026b), and no native research-grade tracker integration exists at all (Anonymous, 2026a). For research requiring calibrated, high-frequency, timestamped gaze data, Godot demands custom bridge engineering whose claimed latencies and absent-tooling assessment rest on a single unverified digest and remain emerging.

References¶

Anonymous (2026a) Eye Tracking in Godot — Gaps, Missing Integrations and Custom Bridge Approaches (Web Search Digest). Research digest, virtual-environments-kb RAW (Accessed: 31 May 2026). godotEyeTrackingGaps2026

Anonymous (2026b) Eye Tracking in Godot — Minor Tools, Community Projects and Legacy Plugins (Web Search Digest). Research digest, virtual-environments-kb RAW (Accessed: 31 May 2026). godotEyeTrackingDigest2026

GodotVR contributors (2026) godot_openxr_vendors — Eye Tracking Support in Godot via OpenXR. GitHub repository. Available at: https://github.com/GodotVR/godot_openxr_vendors (Accessed: 31 May 2026). godotVR2026openxr

Khronos Group (2026) XR_EXT_eye_gaze_interaction — OpenXR Specification. Available at: https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XR_EXT_eye_gaze_interaction (Accessed: 31 May 2026). khronos2026eyegaze

W4 Games (2026) Godot Meta Toolkit — Meta Quest Eye Tracking Plugin for Godot 4. GitHub repository. Available at: https://github.com/godot-sdk-integrations/godot-meta-toolkit (Accessed: 31 May 2026). w4games2026metatoolkit

Open Questions¶

Has any published study used Godot as an eye-tracking stimulus platform? The comparison digest reports none found as of May 2026 (see Eye Tracking Engine Comparison).
Are the claimed bridge latencies (~8 ms Tobii socket, ~1 ms UDP, 10–50 ms REST) reproducible? They originate from a single unverified digest (Anonymous, 2026a).
Will the partial Pico 4 Enterprise permission handling in the Godot vendor layer be completed?