Approach for fastest graphics on mobile (Go/Quest)?

I'm thinking about making a little game development system for VR, including Go/Quest, which are essentially mobile devices. This has a few performance implications:

1. I get to build the general graphics approach however I want, even if that somewhat limits flexibility; e.g., I could ensure that all objects use the same material, I could render with DrawInstanced, etc.
2. But I don't get to control how many objects there are, how they are arranged, or what crazy things the users might be doing with them; nor do I get to bake anything at all, as the whole environment will be built at runtime.
3. It is very very important that I maintain 60 (or better yet, 72) fps, even on mobile hardware.

Under these circumstances, what would you suggest for the general graphics approach? Should I keep everything one material? Manually combine rarely-moving objects into a single mesh? Should I bother drawing with DrawInstanced? Should I be looking at LWRP?

Mostly I'm trying to avoid smacking myself on the forehead a year from now and saying "You idiot, if you'd only done X, you could have done Y, and performance would be Z times better!"

Thanks for any suggestions!

 

Using instancing is always preferable for large numbers of dynamic objects. If your target devices are going to support gles 3 go for it! Don't know if there are any VR devices that don't support it, but still...

New projects in Unity should probably go with a scriptable pipeline anyways for better future(unless srp somehow collapses on itself next year). You can even roll a curstom RP of your own if you're not happy with the ones presented - my little experiments have been fairly promising for mobile. At least for my limited needs I was able to get a custom solution to render faster than the built-in system, but in your case I guess you can't cut as many corners.

One benefit of using SRP would be that you can get away with variants of a material by using the SRP batcher https://docs.unity3d.com/Manual/SRPBatcher.html but that would mean bumping the requirements to gles 3.1.

I don't thing you're completely out of static batching options here. Can't you let the user decide which objects should be static? The API exposes the bells and whistles used for geometry batching, so you could do it all in your code. Maybe have a separate thread doing the combining and swapping in the result once it's ready? You're probably going to write an intermediate scene format to store the results of your users' work anyways, so you could save object batches there aswell. Never tried baking lights like that though.

Offtopic1: in your blog you've mentioned inputting code being cumbersome in VR. How about constructing flowcharts, similar to how UE does it? Maybe not the fastest way to get results, but could be more accessible to the less technically literate and no typing required.

Offtopic2: not to sound like a poopface, but is MiniScript essentially a VM running on top of another VM(mono) in this case? Like in that javascript joke that was going around several years ago about offsetting growing hardware performance by nesting framerowks within framerowks

 

Thanks for the feedback! I haven't dug into the scriptable renderering pipeline yet, but it sounds like I should.

Yes, unless you count IL2CPP as eliminating one of those layers. It's a performance/ease-of-use trade-off.

Of course I could go with Unreal instead, so then it's only one VM for sure... but I'm more comfortable with Unity.

 

One of the best talk on that matter, period

Look Ma, No Jutter! Optimizing Performance Across Oculus Mobile - Unite LA

You can always find further trick to optimized down (Lightmap Gbuffer seems like a good candidate to bake lighting real time, or just async, or additively add lighting).