Summary
When a WebSpatial page is opened in volume mode, an Ornament attached to the bottom area of the volume may occasionally show a rendering-order artifact when the user's gaze targets the volume floor.
The issue was first observed with WebSpatial Ornament, but it does not appear to be Ornament-specific. A similar artifact can also appear with SpatialDiv / Spatialized2DElement content.
From the WebSpatial implementation side:
- Ornament on visionOS is mapped to native SwiftUI
.ornament(attachmentAnchor: .scene(...), contentAlignment: ...).
- Bottom Ornament anchors such as
bottom, bottomLeading, bottomTrailing, and related bottom-area anchors are mapped to native UnitPoint3D bottom positions.
- SpatialDiv uses the Spatialized2DElement path, which is separate from Ornament, but can show a similar artifact.
- This suggests the issue may be related to native visionOS volume compositing, depth, or layer ordering around the volume floor, rather than an Ornament-only positioning issue.
Environment
- Platform: Apple Vision Pro / visionOS
- Window style: volume /
.windowStyle(.volumetric)
- SDK: WebSpatial SDK
- Affected content:
- Ornament with bottom-area
attachmentAnchor
- SpatialDiv / Spatialized2DElement
Steps to Reproduce
-
Open a WebSpatial page in volume mode.
-
Create an Ornament attached to the bottom area of the volume, for example:
<Ornament
attachmentAnchor="bottom"
contentAlignment="back"
width={240}
height={140}
>
<div>Ornament content</div>
</Ornament>
-
Keep the gaze away from the volume floor.
-
Observe that the Ornament renders normally.
-
Move the gaze target onto the volume floor / bottom plane.
-
Intermittently, a hidden black line or clipping boundary becomes visible, and the rendering layer order appears incorrect.
-
Repeat with SpatialDiv / Spatialized2DElement content. A similar artifact can also appear there.
Actual Result
When the gaze targets the volume floor, the compositor may render the volume geometry and 2D spatial content in an incorrect order.
Observed symptoms:
- A hidden black line or boundary becomes visible.
- The Ornament content appears partially behind, clipped by, or incorrectly composited with the volume.
- The artifact is gaze-dependent and may disappear when the gaze moves away from the volume floor.
- A similar issue can also appear with SpatialDiv / Spatialized2DElement, so the behavior is not limited to Ornament.
Expected Result
Changing the gaze target to the volume floor should not affect the rendering order of bottom-attached 2D spatial content.
The Ornament or SpatialDiv content should remain visually stable and should not expose hidden compositor boundaries, black lines, clipping artifacts, or incorrect z-ordering.
Screenshots
The attached screenshots show the issue in sequence:
| # |
Description |
Screenshot |
| 1 |
Normal state: gaze is not targeting the volume floor; Ornament renders correctly. |
 |
| 2 |
Gaze targets the volume floor; a hidden black line appears and the layer order becomes incorrect. |
 |
| 3 |
Another frame of the same Ornament issue while looking at the floor. |
 |
| 4 |
Similar artifact reproduced with SpatialDiv / Spatialized2DElement. |
 |
Notes
This does not look specific to the WebSpatial Ornament implementation.
On visionOS, Ornament uses native SwiftUI .ornament(...), while SpatialDiv / Spatialized2DElement uses a separate spatialized 2D element path. Since both can show a similar artifact in a volumetric window, the issue likely relates to native visionOS rendering or compositing behavior for 2D spatial content near the bottom plane of a volume.
Summary
When a WebSpatial page is opened in volume mode, an Ornament attached to the bottom area of the volume may occasionally show a rendering-order artifact when the user's gaze targets the volume floor.
The issue was first observed with WebSpatial Ornament, but it does not appear to be Ornament-specific. A similar artifact can also appear with SpatialDiv / Spatialized2DElement content.
From the WebSpatial implementation side:
.ornament(attachmentAnchor: .scene(...), contentAlignment: ...).bottom,bottomLeading,bottomTrailing, and related bottom-area anchors are mapped to nativeUnitPoint3Dbottom positions.Environment
.windowStyle(.volumetric)attachmentAnchorSteps to Reproduce
Open a WebSpatial page in volume mode.
Create an Ornament attached to the bottom area of the volume, for example:
Keep the gaze away from the volume floor.
Observe that the Ornament renders normally.
Move the gaze target onto the volume floor / bottom plane.
Intermittently, a hidden black line or clipping boundary becomes visible, and the rendering layer order appears incorrect.
Repeat with SpatialDiv / Spatialized2DElement content. A similar artifact can also appear there.
Actual Result
When the gaze targets the volume floor, the compositor may render the volume geometry and 2D spatial content in an incorrect order.
Observed symptoms:
Expected Result
Changing the gaze target to the volume floor should not affect the rendering order of bottom-attached 2D spatial content.
The Ornament or SpatialDiv content should remain visually stable and should not expose hidden compositor boundaries, black lines, clipping artifacts, or incorrect z-ordering.
Screenshots
The attached screenshots show the issue in sequence:
Notes
This does not look specific to the WebSpatial Ornament implementation.
On visionOS, Ornament uses native SwiftUI
.ornament(...), while SpatialDiv / Spatialized2DElement uses a separate spatialized 2D element path. Since both can show a similar artifact in a volumetric window, the issue likely relates to native visionOS rendering or compositing behavior for 2D spatial content near the bottom plane of a volume.