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 methodology
Testing 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.environmentTexturinghelps ARKit better understand the environment but increases memory usage. On iPhone 12 and newer, it's justified. - For poor light — force plane detection with
ARPlaneDetectionModeand anchor to planes instead of feature points. More stable. - On Android — setting
Config.FocusMode.FIXEDreduces 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
- Define requirements: target platforms, OS versions, device models, typical usage conditions, acceptable anchor drift.
- Set up test environment: adjustable lights, curtains, set of targets with different textures.
- Run the scenario matrix, recording metrics: time to tracking loss, ARAnchor drift,
.limitedevents. - Analyze results: determine critical lighting thresholds for each platform.
- 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.






