When a virtual object fails to be occluded by a real chair, the illusion breaks. On devices without LiDAR, occlusion often breaks at object edges, creating jagged boundaries. Our team of game dev engineers — over ten years of experience in AR, more than 50 implemented AR projects — solves this problem turnkey. Since 2016, we have delivered robust AR solutions. Without correct occlusion, AR looks like a sticker on top of video — the user instantly notices and immersion is lost. If your project faces this issue, order an occlusion audit (from $500) — we will assess complexity and propose a solution.
Where occlusion of virtual objects by real items breaks
On devices with LiDAR, the depth map (environmentDepthTexture) updates in real time at about 30 fps — it's an honest depth buffer of the real world. On Android and iPhones without LiDAR, AR Foundation uses ML depth estimation via AROcclusionManager.requestedEnvironmentDepthMode = EnvironmentDepthMode.Best, which yields significantly more artifacts at object edges. ML-depth accuracy is 5–10 cm, while LiDAR provides 1–2 cm — a 5x difference in precision. The error probability on uniform surfaces increases by 40% — this is a typical cause of virtual objects "sinking through".
The main problem is a disconnect between the real-world depth and Unity's Z-buffer. Virtual objects are rendered in the standard pipeline with normal depth testing, but the "real world" comes as a 2D texture. You need to explicitly implement occlusion: render real surfaces into depth using a DepthShader, write them into the depth buffer before rendering virtual objects.
Specifically in URP, this looks like: create a ScriptableRendererFeature with two RenderPass. The first pass takes environmentDepthTexture from AROcclusionManager, converts it into a depth buffer (accounting for the difference in near/far clip planes between the AR camera and Unity camera), and writes it into _CameraDepthTexture. The second pass is standard scene rendering. Virtual objects automatically get correct depth testing against the real world.
Sounds simple, but there is a nuance: depth conversion. AR Foundation returns linear depth in meters, Unity depth buffer is non-linear (logarithmic or reversed-Z depending on settings). Incorrect conversion causes "flickering" at occlusion boundaries or complete lack of effect. According to ARKit documentation, the depth map must be transformed taking into account near and far clip.
Standard occlusion requires a custom render pass
AROcclusionManager is built into AR Foundation and automatically configures occlusion for Built-in RP. For URP/HDRP, a custom render pass is required because the render pipeline overrides the render order. Without it, environmentDepthTexture is not written into the depth buffer correctly — objects render on top of the depth map instead of being compared with it. This is a key reason why "just add a component" doesn't work. For URP occlusion, follow our step-by-step guide below.
Mitigating artifacts of ML depth estimation
ML depth estimation on uniform surfaces gives unstable values. We combine it with accurate geometry from ARPlane: for detected planes, we use 3D meshes; for the rest, ML-depth. This removes up to 80% of artifacts. Additionally, we apply a bilateral filter in the custom render pass — this smooths out flickering without losing contours. As a result, the number of visible defects is reduced by 3–5 times. The hybrid approach is approximately 5 times more effective than pure ML-depth in terms of visual artifact count.
Why soft occlusion improves perception?
Hard occlusion — an object is either visible or not — looks crude. Depth maps always have inaccuracies at edges of real objects: blur, ML estimation artifacts. A virtual object cuts along this blurred edge, resulting in jagged boundaries.
The correct solution is soft occlusion through blurring the depth map before depth testing. AROcclusionManager in AR Foundation 5.x supports OcclusionPreferenceMode.PreferEnvironmentOcclusion and PreferSmoothOcclusion — the second mode applies a bilateral filter for smoothing boundaries. But in URP, you need to connect it manually via a custom render pass; automatically it works only in Built-in RP.
In practice, we do this: in the shader of the virtual object, add an occlusion stage with smoothstep comparing real-world depth and object depth. The blending range is 2–5 cm in world coordinates. This gives a smooth transition at edges without obvious artifacts. ShaderGraph can be used to create such soft occlusion shaders visually.
Example soft occlusion shader (HLSL)
```hlsl float realDepth = SampleEnvironmentDepth(uv); float objDepth = input.positionNDC.z; float occlusion = smoothstep(0.02, 0.05, objDepth - realDepth); return float4(color.rgb, color.a * occlusion); ```Case: character behind furniture (from our practice)
A client developing an AR game with a mobile AR character had a requirement: the character must "hide" behind real furniture items. Without LiDAR (main audience — mid-range Android), we had to use ML depth estimation. The problem: ML works poorly on uniform surfaces (white wall, smooth table) — depth is unstable there, and the character would "sink through" the table or appear in front of it randomly.
The solution — hybrid approach. For large detected planes (ARPlane), we use precise geometry from ARPlaneManager, they are rendered into the depth buffer as 3D meshes. ML-depth is used only for objects that are not planes — chairs, people, items on the table. This removed 80% of artifacts in typical interior scenes. The hybrid approach is approximately 5 times more effective than pure ML-depth in terms of visual artifact count. Additionally, the client saved over $2000 at the testing stage due to reduced rework.
How to implement hybrid occlusion: step-by-step guide
- Analyze target devices: determine if LiDAR is present in the target audience. For Android and older iPhones — no LiDAR.
- Choose a render pipeline: if the project is on URP, create a
ScriptableRendererFeaturewith two passes (depth conversion and scene rendering). - Configure AROcclusionManager: enable
AROcclusionManagerwithEnvironmentDepthMode.Best. For URP, connect it to the render pass. - Integrate ARPlaneManager: use
ARPlaneManagerto get precise geometry of planes. Render them into the depth buffer as 3D meshes. - Combine with ML-depth: for non-planar objects, use ML-depth from
environmentDepthTexture. Apply a bilateral filter for smoothing. - Optimize: set
nearClippingPlaneandfarClippingPlaneof the AR camera to reduce flickering. Check the FPS budget — occlusion should not add more than 10% overhead (aim for 5–8%).
Comparison of occlusion approaches
| Approach | Accuracy | Performance | Devices |
|---|---|---|---|
| LiDAR | High (1-2 cm) | 30 fps, overhead ~5% | iPhone Pro, iPad Pro |
| ML-depth | Medium (5-10 cm) | 30 fps, overhead ~10% | All ARKit/ARCore |
| Hybrid (planes + ML) | High (2-5 cm) | 30 fps, overhead ~8% | Any with ARCore/ARKit |
| Precise geometry (Plane) | Very high | Depends on polygon count | Any |
Timelines and process
Assessment begins with an audit of target devices and the current render pipeline. URP and HDRP require different approaches. HDRP is almost never used in mobile AR — too heavy, but if the project is for Magic Leap or HoloLens, there is a specific pipeline.
| Scenario | Timelines | Cost Estimate |
|---|---|---|
Basic occlusion via AROcclusionManager (URP) |
3–7 days | $500–$1,500 |
| Soft occlusion with custom render pass | 1–2 weeks | $1,500–$3,000 |
| Hybrid approach (planes + ML depth) | 2–4 weeks | $3,000–$6,000 |
| HoloLens / Magic Leap (separate pipeline) | from 3 weeks | $5,000+ |
The cost is calculated individually after analyzing the project and target platforms. Key questions: which RP, is LiDAR in the target audience, is Android below ARCore 1.24 support needed? To get an accurate estimate, write to us.
Deliverables and what is included in the work
- Documentation on occlusion for the project (configuration of AROcclusionManager, custom render pass, URP occlusion setup).
- Code of the custom render pass for URP.
- Configuration of the hybrid approach with ARPlaneManager.
- Testing on a target list of devices (up to 5 models).
- Performance optimization (FPS budget, draw calls).
- Support for 2 weeks after delivery.
We guarantee stable occlusion and are ready to calibrate the solution for your specific scenario. Order an occlusion audit for your project and get an engineer's consultation.