Why Your (Oculus Quest) Performance Sucks for Unreal Engine 4

[@humancodeable4753]

Awesome Content. Keep up the great work. It´s very inspiring to see other developers create Content for Unreal and VR, especially for the Quest 🤓

[@hallarazad]

Hey, Thanks for the video. Can you please explain how to enable MSAA for Quest? I have tried everything but failed so far

[@vegitoblue2187]

very situational but I guess it will be pretty handy for pickups for example

[@Peterlnewton]

This is exactly why I recorded this video actually. Imagine all those pickups, just...rotating waiting to be picked up. Now imagine everytime it rotates, it updates the nav, bounds, overlap, etc. Everything is situational without question.

[@vegitoblue2187]

@@Peterlnewton You have a pont there 😁

[@olive-vrta]

Clickbait title and very questionable suggestions. For anyone new to Unreal watching this: don't preoptimize to this degree. Static mesh rotations are cheap. They're more expensive than GPU, sure, but still cheap and unavoidable if you need physics. Once you get deeper into your game you can profile to see if it is actually a problem, but more than likely you will have other more serious bottlenecks.

[@Peterlnewton]

The bottleneck which is the focus of this video is related to the CPU need to issue commands to the GPU. These tiled rendering devices bottleneck is typically the CPU (render thread) bound because the GPU cannot begin to render immediately. Why? Oculus Quest has a tiled rendering deferred gpu and these devices have a 'early-z' pass of sorts which optimizes opaque fragmentation of pixels. Which means on a software level, the render thread must submit all commands before GPU is able to start. Which means if the render thread is bottlenecked, the GPU starts late, and the app is unable to finish within the target frametime. You can have the tiled gpu render immediate, but you lose the aforementioned hardware optimization. There is an option of moving the issuing of commands to a dedicated RHI thread, but that is outside the scope of this conversation.

[@TheJeffries7]

This guy is comparing an instance material to a blueprint with a for loop on tick. To any new beginners...you'll get a ton more performance in general if you try and use tick as little as possible. Yes using a shader for rotation is going to save performance but it has the drawback for new developers of making it more difficult to calculate anything based on rotation/position as you have to get a data out of the shader. I agree 100%, premature optimisation is the root of all evil.

[@Peterlnewton]

@@TheJeffries7 What you're saying is true, but I am not suggesting everyone is *required* to rotate their meshes on the GPU. Only pointing out that is much more expensive to rotate a mesh on the GPU than it is the CPU. When you decide to use this technique, you must plan for it. I don't know your project, I can't tell you when it is right to use. I can only report the facts of the point in which I am making.

[@BenJamin-mq8eb]

so if you want to rotate an object.. like a turntable.. how do you do it with the best performance? GPU is better than CPU?

[@Peterlnewton]

If you don't need things like physics, yes. GPU is better.

[@BenJamin-mq8eb]

@@Peterlnewton okay, but how can you force the engine to say: hey, just use for the rotation the GPU power instead of the CPU?

[@Peterlnewton]

@@BenJamin-mq8eb rotating the vertecies in the material as demonstrated in this video. The coordination between the GPU and CPU is the tricky part. The difference between the GPU and CPU doing the work, is where the instructions are put. One example, instructions put: In Blueprint, work is done on CPU; In Material, work is done on GPU. (Note: CPU work is required to inform the GPU of work it should do. )