Mobile VR Gaze Interface: Raycast, Dwell, Reticle Implementation

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Mobile VR Gaze Interface: Raycast, Dwell, Reticle Implementation
Medium
~3-5 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

Mobile VR without controllers — the only interaction method is gaze direction. It seems simple: look at a button and it clicks. In practice, poorly implemented gaze annoys users faster than any other UI pattern. Over the years, we have developed a stack and approaches that guarantee comfortable interaction. Our experience: 5+ years in mobile VR development, over 20 projects with gaze interface. We offer a turnkey solution: from raycast to progress indicator. We implement the basic system in 3–5 days, full system in 1–2 weeks. According to Google Cardboard documentation, gaze-based interaction is the standard input method for mobile VR without controllers.

How does raycast from the gaze center work?

Gaze is determined by the camera's view direction. The ray is cast from the camera position forward along Camera.main.transform.forward:

void FixedUpdate() {
    Ray gazeRay = new Ray(Camera.main.transform.position,
                          Camera.main.transform.forward);

    if (Physics.Raycast(gazeRay, out RaycastHit hit, maxGazeDistance, interactableLayer)) {
        var target = hit.collider.GetComponent<IGazeTarget>();
        if (target != null) {
            HandleGazeHit(target, hit.point);
        } else {
            HandleGazeMiss();
        }
    } else {
        HandleGazeMiss();
    }
}

FixedUpdate() instead of Update() — stable call frequency not tied to FPS. On weak devices with drops to 30 FPS, Update() gives uneven response. The interactableLayer is mandatory: raycasting across the entire scene is expensive, and the user should not accidentally activate invisible colliders.

How to implement reticle (gaze cursor)?

Reticle is a visual indicator of the gaze point. It is placed in world space on the surface of the object under gaze. Distance is dynamic: the reticle "sticks" to the hit point.

void UpdateReticle(Vector3 hitPoint, Vector3 hitNormal) {
    reticleTransform.position = hitPoint + hitNormal * RETICLE_OFFSET;
    reticleTransform.rotation = Quaternion.LookRotation(-hitNormal);

    // Constant apparent size in angular units
    float dist = Vector3.Distance(Camera.main.transform.position, hitPoint);
    reticleTransform.localScale = Vector3.one * dist * ANGULAR_SIZE;
}

Note: when no object is under gaze — reticle at default distance (3–5 meters). We don't hide it: the user should always see where they are looking.

Dwell activation and progress indicator

The user looks at an object for N seconds — activation occurs. Optimal dwell time: 1.2–2.0 seconds. Less than 1 second leads to accidental activations when scanning the scene, more than 2 seconds fatigues. Progress must be noticeable. A filling ring around the reticle is standard:

public class GazeDwellController : MonoBehaviour {
    [SerializeField] private float dwellTime = 1.5f;
    [SerializeField] private Image progressRing;

    private float dwellProgress = 0f;
    private IGazeTarget currentTarget;
    private bool isActivated = false;

    public void OnGazeEnter(IGazeTarget target) {
        currentTarget = target;
        dwellProgress = 0f;
        isActivated = false;
        progressRing.gameObject.SetActive(true);
    }

    public void OnGazeStay() {
        if (isActivated) return;
        dwellProgress += Time.deltaTime / dwellTime;
        progressRing.fillAmount = dwellProgress;

        if (dwellProgress >= 1f) {
            isActivated = true;
            currentTarget?.OnGazeActivate();
            StartCoroutine(ResetAfterDelay(0.5f));
        }
    }

    public void OnGazeExit() {
        currentTarget = null;
        progressRing.gameObject.SetActive(false);
        dwellProgress = 0f;
    }
}

After activation — a short cooldown before the next activation of the same object (0.5–1.0 sec). Otherwise the user cannot remove their gaze in time and the button "clicks" twice.

Hover state: feedback before activation

Note: when the user looks at an object but dwell is not yet complete, immediate visual feedback is needed. The object should react at OnGazeEnter — before the activation time elapses. Options:

  • Highlight: change material emission color
  • Scale: object slightly enlarges (0.05f is enough)
  • Animation: icon responds to gaze
  • Sound: short click when dwell starts

Without this, the user doesn't know if the application "sees" them.

Cardboard button as confirmation

The Cardboard has a physical button (magnetic trigger). We add it as an alternative activation method instead of dwell — for advanced users it is faster and more convenient:

// Cardboard SDK trigger event
void Update() {
    if (CardboardInput.GetButtonDown()) {
        TriggerCurrentGazeTarget();
    }
}

The button is not a replacement for dwell, but a supplement. Not all Cardboard cases have a working magnetic button.

What typical errors occur with gaze interaction?

Too small collider on interactive object — user "misses" the button. The collider should be 10–20% larger than the visible object. Gaze speed (angular velocity) affects accuracy: during rapid scanning, a speed threshold resets dwell. Reticle jitters due to gyroscope — Lerp with 20 ms time eliminates jitter. Use a separate layer for raycast to avoid accidental activations and save performance.

Error Solution
Too small collider Increase collider 10–20% relative to visual
Accidental activations Head angular velocity threshold when starting dwell
Reticle jitter Lerp reticle position with time ~20ms

Comparison of activation methods

Parameter Dwell activation Cardboard button
Availability on all devices Yes No (not all work)
Fatigue Medium Low
Accuracy Good High
Time adjustment Yes (1.2–2.0 s) No

What's included in the work

  • Documentation of gaze system architecture
  • Source code: raycast, reticle, dwell controller, hover state
  • Integration with Cardboard SDK and alternative triggers
  • Testing on devices (iOS/Android) with different Cardboard versions
  • Support for 2 weeks after delivery

Process of work

  1. Analysis of interactive elements: object types, interaction scenarios.
  2. Implement raycast system with proper layers and colliders.
  3. Reticle in world space with constant apparent size.
  4. Dwell controller with progress indicator, hover state, cooldown.
  5. Cardboard button as alternative trigger.
  6. Comfort testing: dwell time, button sizes, feedback.

Timeline estimates

Basic gaze interaction system with reticle and dwell — 3–5 days. Full-fledged system with multiple types of interactive objects, animations, sound, and configurable parameters — 1–2 weeks.

We guarantee comfortable interaction. Certified Unity and Android/iOS developers. Contact us to discuss your project — we will implement a gaze interface for your mobile VR application.

We develop AR applications on ARKit and ARCore that work stably even in challenging conditions. Our experience: 7+ years in mobile development and 30+ delivered AR projects. Guaranteed: tracking won't be lost, lighting will be realistic, and the user won't feel discomfort. Certified Apple and Google developers.

Why does tracking get lost and how to fix it?

ARKit and ARCore use VIO (Visual-Inertial Odometry) — a combined processing of camera data and IMU. Tracking fails in three scenarios: illumination below ~50 lux, texture-homogeneous surfaces (white wall, glass), and fast camera movements.

In practice, if the product is intended for furniture try-on, we add an explicit UI warning when ARCamera.TrackingState.limited(.insufficientFeatures). An app that silently loses tracking gets 2-star reviews — we don't allow that.

Plane detection is configured via ARWorldTrackingConfiguration.planeDetection = [.horizontal, .vertical]. Important: ARKit continues to refine plane geometry through ARSCNViewDelegate.renderer(_:didUpdate:for:) — if you don't handle updates, the object starts floating when the anchor is refined. Our team solves this at the architecture stage, not during testing.

AR Foundation: cross-platform with nuances

Unity AR Foundation is an abstraction layer over ARKit and ARCore. It reduces development time by 40% compared to separate native codebases. But some features (e.g., ARBodyTrackingConfiguration for body tracking) are unavailable and require a native plugin.

For React Native and Flutter, direct AR Foundation is missing. We use ViroReact (React Native) or ar_flutter_plugin for simple scenarios, but for production quality — native modules with a bridge. Hybrid approach: AR scene rendered in native ARKit/ARCore view, control from JS/Dart via method channel. Included in our standard delivery.

Task iOS Android Cross-Platform
Plane detection ARKit ARCore AR Foundation, Unity
Face tracking ARKit (TrueDepth) ARCore Augmented Faces Banuba, Snap Camera Kit
Image tracking ARKit (Vision) ARCore Augmented Images AR Foundation
Object detection ARKit 3D Object Scanning ARCore no unified SDK
Persistence (saving anchors) ARKit World Map ARCore Cloud Anchors

Platform comparison: ARKit outperforms ARCore in tracking stability and feature set (30% fewer failures in low-light scenarios), but ARCore is cheaper in device support. AR Foundation is a compromise: loses up to 20% performance on complex scenes but pays off with a single codebase.

Try-on: product fitting via AR

Fitting glasses, jewelry, cosmetics — a separate class of tasks. Here, face tracking is needed, not plane detection.

ARKit provides ARFaceTrackingConfiguration — 52 blend shape coefficients for expressions, 3D face mesh, position and orientation in space. Works only on devices with TrueDepth camera (iPhone with Face ID).

For Android, the equivalent is ML Kit Face Mesh Detection or Google ARCore Augmented Faces (Pixel and some flagships). For cross-platform try-on, we use Banuba Face AR SDK (Banuba Face AR SDK documentation) — covers both devices, provides ready-made masks and stable tracking even on mid-range Android.

Try-on quality critically depends on 3D product models. Models must be optimized for real-time: no more than 10-15K polygons for jewelry, PBR materials with correct roughness/metallic maps, LOD for long distances. Within our engagement, we provide ready-made optimization guides.

How to achieve realistic lighting in AR?

ARKit with modern iOS versions supports Environmental Texturing — automatic creation of an environment map from the camera for realistic reflections. Enabled via ARWorldTrackingConfiguration.environmentTexturing = .automatic. Without it, metallic and glass materials look plastic.

ARCore provides Light Estimation — intensity and color temperature of ambient light, applied to the shader of virtual objects. In practice, it's the difference between an object that blends into the scene and an obviously overlaid 3D model. We guarantee that the final image doesn't betray virtuality.

What's included

  • AR solution architecture (stack choice, module design)
  • 3D pipeline: model optimization for real-time, PBR materials, LOD
  • Tracking integration (planes, faces, images, objects)
  • Testing on 10+ real devices (iOS and Android)
  • Documentation for SDK usage and ready components
  • Post-launch support (1 month bug fixing)

Timeline and estimation

Simple AR scene with placing one 3D model on a plane — 1-2 weeks. Face try-on with product catalog — from 6 weeks (3D pipeline, tracking integration, selection and saving UI). Full AR shopping with cloud anchors and multiplayer — from 3 months. We'll estimate your project in 1 day — contact us to discuss your AR idea.