visionOS 26 - Rendering Issues related to Transparency

Summary

After updating to visionOS 26, we’ve encountered severe transparency rendering issues in RealityKit that did not exist in visionOS 2.6 and earlier. These regressions affect applications that dynamically control scene opacity (via OpacityComponent).

Our app renders ultra-realistic apartment environments in real time, where users can walk or teleport inside 3D spaces. When the user moves above a speed threshold, we apply a global transparency effect to prevent physical collisions with real-world objects.

Everything worked perfectly in visionOS 2.6 — the problems appeared only after upgrading to 26.

Scene Setup Overview

• The environment consists of multiple USDZ models (e.g., architecture, rooms, furniture).
• We manage LODs manually for performance (e.g., walls and floors always visible in full-res, while rooms swap between low/high-res versions based on user position and field of view).
• Transparency is achieved using OpacityComponent, applied dynamically when the user moves.
• Some meshes (e.g., portals to skyboxes, glass windows) use alpha materials
• We also use OcclusionMaterials to prevent things to be seen through walls when scene is transparent

Observed Behavior by Scenario

(I can share a video showing the results of each scenario if needed.)

Scenario 1 — Severe Flickering (Root Opacity)

Setup:

• OpacityComponent applied to the root entity
• NO ModelSortGroupComponent used

Symptoms:

• Strong flickering when transparency is active
• Triangles within the same mesh render at inconsistent opacity levels
• Appears as if per-triangle alpha sorting is broken

Workaround:

• Moving the OpacityComponent from the root to each individual USDZ entity removes the per-triangle flicker

Pros:

• No conflicts with portals or alpha materials

Scenario 2 — Partially Stable, But Alpha Conflicts

Setup:

• OpacityComponent applied per USDZ entity
• ModelSortGroupComponent(planarUIAlwaysBehind) applied to portal meshes
• Other entities have NO ModelSortGroupComponent

Symptoms:

• Frequent alpha blending conflicts:

  • Transparent surfaces behind other transparent surfaces flicker or disappear
  • Example: Wine glasses behind glass doors — sometimes neither is rendered, or only one
  • Even opaque meshes behind glass flicker due to depth buffer confusion
  • Alpha materials sometimes render portals or the real world behind them, ignoring other geometry entirely

Analysis:

• Appears related to internal changes in alpha sorting or depth pre-pass behavior introduced in visionOS 26

Pros:

• Most stable setup so far

Cons:

• Still unreliable when OpacityComponent is active

Scenario 3 — Layer Separation Attempt (Regression)

Setup:

• Same as Scenario 2, but:

  • Entities with alpha materials moved to separate USDZs
  • Explicit ModelSortGroupComponent order set (alpha surfaces rendered last)

Symptoms:

• Transparent surfaces behind other transparent surfaces flicker or disappear
• Depth is completely broken when there's a large transparent surface
• Alpha materials sometimes render portals or the real world behind them, ignoring other geometry entirely

Workaround Attempt:

• Re-ordering and further separating models did not solve it

Pros:

• None — this setup makes transparency unusable

Conclusion

There appears to be a regression in RealityKit’s handling of transparency and sorting in visionOS 26, particularly when:

• OpacityComponent is applied dynamically, and
• Scenes rely on multiple overlapping transparent materials.

These issues did not exist prior to 26, and the same project (no code changes) behaves correctly on previous versions.

Request

We’d appreciate any insight or confirmation from Apple engineers regarding:

• Whether alpha sorting or opacity blending behavior changed in visionOS 26
• If there are new recommended practices for combining OpacityComponent with transparent materials
• If a bug report already exists for this regression

Thanks in advance!