Glitches on iOS with AR Camera Image Rendering (URP 17 render graph)

Unity Engine
, , , , ,
1

Environment:

  • Unity Version: 6000.0.25f1
  • URP Version: com.unity.render-pipelines.universal@17.0.3
  • AR Foundation: com.unity.xr.arfoundation@6.0.3
  • ARKit: com.unity.xr.arkit@6.0.3
  • ARCore: com.unity.xr.arcore@6.0.3

How to Reproduce the Issue:

  1. Open the attached project with any version of Unity6
  2. Build and install the app on an iOS device, then run it.
  3. Click the “Image Texture Toggle” to start rendering the camera image to the render texture on the object.

Description of the Issue:

Hi,

I’m working on an AR app using AR Foundation to render the camera image to an object surface(because why not). However, when running the app on an iOS device, I’m encountering visual glitches, including purple fragments and a translucent rectangle that appear when the camera feed is rendered to the texture.

Interestingly, the issue only occurs on iOS devices. The demo works perfectly on Android without any modifications. When I set the render texture to texture.enableRandomWrite, the purple glitches disappear, but this is not an ideal solution, and the translucent rectangle persists.

I’ve tried several potential fixes based on the official RenderGraph samples, such as using a BlitPass or CopyPass, but none of them resolve the issue.

Expected Behavior: The camera image should render correctly to the object’s surface without visual glitches or artifacts.

Actual Behavior: On iOS devices, purple glitches and a translucent rectangle appear on the rendered texture.

Additional Information:

  • The issue seems specific to iOS devices, as the demo runs fine on Android.
  • Setting texture.enableRandomWrite removes the purple glitches but does not fix the translucent rectangle.
  • I’ve explored solutions based on RenderGraph official samples, but they don’t seem to help.

Unity Version: 6000.0.25f1
URP Version: 17.0.3
Platform: iOS
Device: iPhone 14 Pro

Thank you for any advice or insights!

glitches
glitches786×1704 38.2 KB

test_image_render.zip (829.6 KB)

1 Like
2

Unity Stuff prefers Bug Reporting via Unity Bug Reporter.

In addition to this message, attach the Reference of Bug Report from Unity’s Jira that you will receive using Unity Bug Reporter.

3

Thanks for the advice. I’ve reported with Unity Bug Reporter.

The case number is IN-88342.

1 Like
4

Thank you for filing a bug report - our QA will look into it.

1 Like
5

This issue can be observed in EasyAR Sense Unity Plugin 4.6.4 (patch version to support Unity 6) and the latest 4.7 pre-release version when URP 17 render graph is enabled in Unity 6. (Render graph was not supported in older EasyAR versions.)

EasyAR Sense Unity Plugin 4.6.4 was released today, and we have directed our users to this thread and the same issue in issue tracker for further updates in our documents if they are looking for a solution.

As supplementary, I would like to describe a little more about why and how render texture of physical camera image is used in EasyAR.

When an AR system is working, there are always requirements from developers to retrieve physical camera images, for either display (GPU) or extra algorithms (CPU). EasyAR uses similar (not exactly the same) procedure to render images from camera devices to screen as AR Foundation. A ScriptableRendererFeature is used when rendering using URP. EasyAR provides a feature to acquire image memory on CPU (not in the same way provided by AR Foundation), and together a feature for users to retrieve physical camera image textures to use the image in some application scenarios.

The developer may use the texture, for example, in EasyAR Coloring3D sample to display camera images on their models. This is usually used in AR enhanced painting books for children. When end users scan the painting book with their phones during or after painting, they can see what they draw in 3D through the phone, and the texture of the 3D model is lively captured from the phone. There may be other usages for the texture, as AR is a quite creative area.

We will keep track of this issue, and any other solutions or workarounds are welcome.