AR Tracking Stability Testing Under Different Lighting Conditions

AR Tracking Stability Testing Under Different Lighting Conditions A user places a virtual object on a table, but it floats in the air — this isn't a bug, it's tracking loss due to lighting. We encounter this on nearly every second project. Sunlight at a 15° angle, 100 Hz fluorescent flicker, dark

Our competencies

Other studio services

Frequently Asked Questions

Latest works

  • image_games_mortal_motors_495_0.webp
    Game development for Mortal Motors
    1504
  • image_games_a_turnbased_strategy_game_set_in_a_fantasy_setting_with_fire_and_sword_603_0.webp
    A turn-based strategy game set in a fantasy setting, With Fire and Sword
    1006
  • image_games_second_team_604_0.webp
    Game development for the company Second term
    635
  • image_games_phoenix_ii_606_0.webp
    3D animation - teaser for the game Phoenix 2.
    716
  • image_training-quizzes_kids_shopping_quiz_614_0.webp
    Educational quiz for kids "Shopping in a store"
    95

AR Tracking Stability Testing Under Different Lighting Conditions

A user places a virtual object on a table, but it floats in the air — this isn't a bug, it's tracking loss due to lighting. We encounter this on nearly every second project. Sunlight at a 15° angle, 100 Hz fluorescent flicker, dark room with spot LED — each scenario breaks tracking in its own way. With over 30 projects involving positional tracking, we can predict these scenarios and eliminate them before release. Contact us for a detailed audit of your project.

Causes of Tracking Loss Under Poor Lighting

Visual inertial odometry (VIO) algorithms, which power ARCore and ARKit, rely on feature points — distinct points in the frame — to estimate camera position. Below approximately 50 lux, the number of reliable feature points drops sharply, and the system compensates using IMU data. This works until IMU drift accumulates. In practice, after 3–4 seconds in poor light, the anchor drifts by 5–8 cm. In gaming, this is catastrophic: the object appears to hover instead of sitting on the surface.

Overexposure is also critical: direct sunlight creates zones with saturated pixels where feature extraction fails. ARKit reports this via ARCamera.TrackingState with reason .insufficientFeatures, ARCore via TrackingFailureReason.INSUFFICIENT_LIGHT. The thresholds differ, but both allow showing a user warning.

Fluorescent lamps are a separate pain point. At 50/60 Hz, they create flicker that the sensor registers as periodic exposure variations. Visually it's almost imperceptible, but the algorithm sees feature points "breathing" between frames and interprets this as camera movement. According to Apple documentation, ARKit uses VIO and detects insufficient lighting via ARCamera.TrackingState.

How We Test Different Lighting Types

Our standard test matrix covers three axes:

  • Light level: dark room (~10-30 lux), office (~300-500 lux), cloudy outdoor (~1000-5000 lux), direct sunlight (>50,000 lux).
  • Light source type: point (LED), linear (fluorescent tube), diffuse (clouds), mixed (window + ceiling).
  • Dynamics: static, moving shadows, day/night transition, flickering light.

For each scenario, we record: time to tracking loss, maximum ARAnchor drift over 60 seconds, number of .limited events, recovery time.

Tools: custom overlay in Unity AR Foundation displaying session state in real time, recording via ReplayKit (iOS) or MediaProjection (Android).

Lighting Condition Expected Tracking Behavior Typical Failure Scenario
< 50 lux Frequent .limited (insufficientFeatures) Within 5-10 seconds in 90% of cases
50-300 lux Unstable, depends on surface texture When camera moves
300-5000 lux Working range Loss due to overexposure
> 20,000 lux (direct sunlight) Saturated frame, complete loss Immediate
More on methodologyTesting is performed on real devices with different cameras (latest iPhone and Galaxy models). We use dimmable LED panels for precise light level setting and a spectrometer for verification.

Comparison of ARCore and ARKit Under Low Light

At a lighting level of 30 lux — typical for a dimly lit room — we tested both platforms. After 4 seconds of tracking, ARKit reported .limited with .insufficientFeatures, while ARCore continued tracking for 8 seconds before also going limited, but with notable anchor drift. This means ARKit enters limited state 1.7x faster than ARCore under low light. In our projects, we use these differences to tailor the user experience and fallback logic.

Parameter ARCore ARKit
Threshold for .limited transition ~30 lux ~50 lux (1.7x higher)
Reaction to flicker Holds tracking longer (2x on average) More frequent .limited
IMU usage when feature points lost Aggressive displacement filtering Quick notification via .insufficientFeatures

Handling Tracking Loss in Sunlight

When tracking is unstable in a specific lighting range, it's a UX task. A few techniques:

  • Enabling ARWorldTrackingConfiguration.environmentTexturing helps ARKit better understand the environment but increases memory usage. On iPhone 12 and newer, it's justified.
  • For poor light — force plane detection with ARPlaneDetectionMode and anchor to planes instead of feature points. More stable.
  • On Android — setting Config.FocusMode.FIXED reduces blurred frames during fast motion in low light.

Improper illumination assessment can cost extra weeks of QA and up to 20% of budget for rework. With our testing, you can save up to 40% of budget on the optimization phase — typically $5,000 for a single platform.

How to Conduct AR Tracking Testing: Step-by-Step Plan

  1. Define requirements: target platforms, OS versions, device models, typical usage conditions, acceptable anchor drift.
  2. Set up test environment: adjustable lights, curtains, set of targets with different textures.
  3. Run the scenario matrix, recording metrics: time to tracking loss, ARAnchor drift, .limited events.
  4. Analyze results: determine critical lighting thresholds for each platform.
  5. Adjust AR session configuration and UX state handling accordingly.

Deliverables

Our deliverables include:

  • Documentation: Test results with drift graphs and threshold tables.
  • Access: Custom Unity overlay for real-time tracking state monitoring.
  • Training: Team training on best practices and code review.
  • Support: Ongoing support for up to 30 days after handover.

All deliverables are tailored to your platform (iOS/Android) and device set. Our certified Unity developers (over 5 years of experience) guarantee tracking stability improvements. Pricing starts at $2,000 for a single platform and $3,500 for dual platform.

Our Process

We start by collecting requirements: target platforms, OS versions, device models, typical usage conditions, acceptable anchor drift. We then set up the test environment: adjustable lights, curtains, textured targets. We run the scenario matrix, capture metrics, and produce a report with thresholds and recommendations. If needed, we adjust AR session configuration or add UX handling for critical states.

Timelines: from 2-3 days for a single platform to 2-3 weeks for full coverage with iterations. Cost is determined after analysis — request a consultation and we will evaluate your project within one day. Full-cycle service.