You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I've conducted several tests comparing the performance of two scenes within the Built-in Render Pipeline: the "Sample Scene" and the "XR Interaction Toolkit Sample" scene. Despite both scenes having identical configurations, including the use of the same assets, 20k tris, and 20 drawcalls, there's a significant difference in performance based on the player used.
When the "Sample Scene - Built-in Render Pipeline" player is used, the performance on Quest 3 reaches 90 fps. However, switching to the "XR Interaction Toolkit Sample - Built-in Render Pipeline" player results in a reduced performance of 45 - 50 fps on Quest 3.
I've noticed that deactivating the raycast and other rig elements (such as teleport and menu button) in the "XR Interaction Toolkit Sample - Built-in Render Pipeline" player improves the frame rate by approximately 5 -15 fps. Furthermore, the most substantial drop in fps occurs when interacting with objects using hand tracking with the XRI player, which utilizes a 3D model for hands that requires a shader from Shader Graph, as opposed to the standard shader used by the other player.
Given these findings, the XRI player, especially with webXR, appears to be a less favorable option compared to the classic desert scene player. Do you have any insights into why this performance disparity exists or any recommendations on how to improve the situation? Best.
The text was updated successfully, but these errors were encountered:
I never did a deep test of performance of the XRI.
Have you tried the XRI rig in the desert scene?
The canvases in the XRI sample scene might be heavy for WebGL+WebXR.
In general, XRI uses lots of interfaces, which can also add to the performance issues.
And I'm sure there's lots to improve on WebXR Export integration.
If you can do some memory debugging and see what are the heavy parts, we can fix specific issues.
I have tested the XRI rig in the desert and the performance is lower than with the other rig. It is true that the canvas affects the performance, I am working with only one canvas, disabling all the others of XRI like the hands menu. It is curious that the performance stabilizes at 45, even if I increase the tris with 50k more, it is still 45 fps (for being half of the 90 Hz?) A pity that we can't use VSync Count in webgl.
For the memory debugging for quest 3 what do you recommend me?
If you can connect the Unity profiler, try that.
You can also use the Performance tab of Chrome DevTools and build Unity in dev mode or with --profiling-funcs.
I think running it on desktop with Quest Link would be simpler than debugging remotely, but it's possible as well.
Hi, I've conducted several tests comparing the performance of two scenes within the Built-in Render Pipeline: the "Sample Scene" and the "XR Interaction Toolkit Sample" scene. Despite both scenes having identical configurations, including the use of the same assets, 20k tris, and 20 drawcalls, there's a significant difference in performance based on the player used.
When the "Sample Scene - Built-in Render Pipeline" player is used, the performance on Quest 3 reaches 90 fps. However, switching to the "XR Interaction Toolkit Sample - Built-in Render Pipeline" player results in a reduced performance of 45 - 50 fps on Quest 3.
I've noticed that deactivating the raycast and other rig elements (such as teleport and menu button) in the "XR Interaction Toolkit Sample - Built-in Render Pipeline" player improves the frame rate by approximately 5 -15 fps. Furthermore, the most substantial drop in fps occurs when interacting with objects using hand tracking with the XRI player, which utilizes a 3D model for hands that requires a shader from Shader Graph, as opposed to the standard shader used by the other player.
Given these findings, the XRI player, especially with webXR, appears to be a less favorable option compared to the classic desert scene player. Do you have any insights into why this performance disparity exists or any recommendations on how to improve the situation? Best.
The text was updated successfully, but these errors were encountered: