Quest 2 performance issues

[fossil plinth]

Been working on this for a while now but can't seem to figure out why I can't improve it.

Short description: We have a pretty complex model that we're making a training simulation for. Some parts are static and some need to move.

Here's the profiler at the moment. Based on the guidelines for quest I thought that it was going to be ok but evidently not. I'm getting around 35-40 FPS at this point in the profiler

[rotund sluice]

so it seems that the render thread is the bottleneck

how complex is this model ? Like how many parts? Are they skinned ?

[fossil plinth]

Here's the stats in editor with everything in the model enabled

[rotund sluice]

Well the editor will have wildly different performance from the Quest. The profilling is from device right ?

[fossil plinth]

It's hundreds of parts, so part of what I've been doing is going through with the Mesh Baker plugin to bake things down

[fossil plinth]

From device yes

[rotund sluice]

how many different mesh renderers is this model ?

[fossil plinth]

To your previous question there are a couple of skinned meshes but very few

But it's a lot of renderers

[rotund sluice]

how much is a lot ? 😄

what the render thread does is it submits data from all those renderers to the gpu

so the more renderers there are the more work it has to do. I'm guessing you are using URP's normal rendering path, no BRG or anything

[fossil plinth]

Vanilla URP yes

I can't really count them cause it's a big hierarchy 🤔

Wait maybe on the asset

Just above 1000 different meshes to begin, and then I've baked the majority of them together in groups so it's less than that in the scene

However mesh baker by default just disables the renderers on the source assets, so I have a lot of those lying around. But I don't think that should incur a cost?

[rotund sluice]

if they are off they should not no

[fossil plinth]

So I see Gfx.WaitForGfxCommandsFromMainThread and then Gfx.WaitForRenderThread and then again Gfx.WaitForGfxCommandsFromMainThread

[rotund sluice]

yep, my take is that the amount of mesh renderers is too damn high for the poor Quest 2 cpu

also are you doing anything to break the SRP batching ?

that might cause it to submit more request than necesesarry

Can you do occlusion culling for the non-moving parts ?

[fossil plinth]

I've already implemented my own culling system for disabling irrelevant objects

[fossil plinth]

The 'total object count' that isn't enabled in this snapshot is 1,650, which I honestly didn't think would be a problem...

[mint depot]

It seems like something you could reasonably test, at least.

[rotund sluice]

Disabled mesh renderers definitely dont count towards the draw command submissions. Another thing might be if the transform hierarchy of moving parts is very complex that might cause the render thread to have to recalc a bunch of matricies

Another idea I have is simplifying the mesh data itself. Maybe you dont need normals or tangents or full precision for the position

If this is the bottleneck recalculating the normals in the vertex stage might be faster than pushing them from the cpu

I recently came across this video https://youtu.be/5zlfJW2VGLM?si=R-QpRf4Nk7Mb6pth that explains mesh optimisation techniques pretty well. Most wont be suitable to your case but it might spark some inspiration