4.5.1.stable.official [f62fdbde1]
I have created a very basic scene with Godot on my Quest 3.
The scene starts, but I have a performance what feels like 1 frame per MINUTE.
I`ve used it in April and it worked fine.
Could this be a problem with HorizonOS v83.1034?
I already deinstalled and reinstalled Godot on my Quest 3…no change 
Any hints what I could check or change?
Thanks in advance.
Best,
MiLe
e
I believe there is a livelier community of XR people over on the Godot Discord. You might try the group there.
im having the exact same issue, were you able to resolve it?
I know I’m late to the party, but just curious about this issue. Did you find a resolution? For me I hadn’t noticed much changes to FPS when the new OS hit.
When you’re developing your game are you displaying metrics in a hud or other means? I have various games in dev currently and always have my debug virtual terminal in game so I can see if FPS drops or memory spikes, etc. It has helped when I make a change and performance goes into the terlet.
Additionally, I’m on a forked version of Godot 4.4.1. I’ve also made a lot of fixes, not to the Engine per se, but to XR tools. One small recent example was that XR tools caused framerates to spike when climbing if your body collides with whatever your climbing. I changed it so that the body safely does NOT collide when climbing and then resumes collisions subsequently. There are a bunch of other things as well which caused weird spiking.
What does your simple scene look like? And are you using a lot of wicked high res materials? Over time I’ve learned that there are a myriad of things which cause FPS to turn into poop: rain/snow with high poly meshes, nonperformant gpu particles, badly configured subviewports, too many zombies, too many lights!, too much shading, bad use of trimesh, not being careful about what happens in process and physics_process, etc.
This is a good thread to read through: Performance considerations for stand alone XR
Some of that is already a little dated as currently the mobile renderer has caught up and if properly configured, can match or even outperform the compatibility renderer.
Also things change drastically whether you focus on PCVR or on standalone hardware. It is easy to tank performance by using features not meant for TBDR GPUs and some are on by default (like glow). And this is not limited to Godot, many high quality VR games targeting standalone hardware either use very customized rendering pipelines or make heavy use of baked lighting with very limited dynamic lighting, because the hardware just can’t hack it.
Physics is an area where it is easy to loose performance as well especially as you have limited CPU cycles to spend on it. Jolt is definitely better optimised than what Godot offers out of the box, but also using triangle based collision shapes is very expensive, so you can win a lot of performance by good use of collision primitives. The demos in XR Tools were developed for desktops and is not using Jolt, and thus are not optimised here. But that is an issue with the demo, and limited resources to improve the demo, not XR Tools itself.
Godots animation system is another example, it’s focused on giving you as much flexibility as possible to do advanced combined animation on your hero character. That is the use case it’s meant for and where it shines.
It’s not suitable, nor meant to be used, when you have a mob of enemies and will kill your performance if you apply it to dozens of characters. Google “Vertex Animation Textures” for a technique to bake animations where you can create large animated mobs of enemies. There are several extensions to bake animations to textures within Blender, and plugins for Godot to add the needed functionality to your project.
It’s all about knowing your tools, knowing the environment you’re working in, and choosing the right approaches to achieve your goals.