GraphicRaycaster not working in build on Quest with MRTK

We’re adding Cesium to an existing app, initializing it at runtime by instantiating a prefab containing a CesiumGeoreference and Cesium3dTileset. When we do, our Canvas UIs are no longer being hit by raycasts. The odd thing about this is it works fine in the editor and Canvas UIs work fine in the build up until we instantiate Cesium. Raycasting a BoxCollider also works fine in all cases.

One suspect was a very distant clipping plane, but we’ve tested a build with our usual clipping plane settings and the issue persists.

Does this sound familiar to anyone?

Unity 2022.3.16f1, Cesium v1.7.1, MRTK

My colleague found a workaround. TL;DR: It seems to be an issue unique to our project related to Cesium Credits and our project using the old Unity Input System with MRTK and the new Input System installed.

I followed these steps in this post
Cesium Credits · Issue #333 · CesiumGS/cesium-unity · GitHub
to make our own copies of the credits UI
Then I targeted a Render Texture inside the Panel Settings
I then just applied that texture to a Plane I added into the scene for testing.
I also made the “picking mode = Ignore” in the Visual Elements for both “PopupCredits” and “OnScreenCredits” this is to turn off the click events on the UI.
I toggled on “showCreditsOnScreen” to true on the Tileset so that the Full credits are displayed instead of the link button to open the “PopupCredits” which no longer has a click event.

Not sure how much of what I did was necessary I do know the removal of the credits completely isn’t necessary as that was a last ditch effort on my part just in case the stuff above didn’t work.

I can see based on their code that if we weren’t using the new Input system(i.e. it not in the project) it would revert to the old system which probably works with MRTK out of the box but we are a special case where 99% of our stuff is old input system but we have the new input system active in project as well for small things and my new input system scripts that are WIP (eventually we would want to go full new input system but with this discovery looks like it would require an MRTK3 upgrade or MRTK removal)


Thank you for sharing the details of the workaround you found!