GENERAL COMMENTS ABOUT THE STATE OF UE5 & VR DEVELOPMENT
I’m making this post to highlight a couple of things, maybe learn something from any comments, and maybe give the feedback to epic that they have said they wanted 
.
Please don’t use it an excuse to dogpile Epic or criticise the Unreal Engine with negative nonsense.
That isn’t the point; I am not criticising anyone, either at Epic (or at Meta)
And hopefully any apparent ‘saltiness’ will be taken with the humour that was intended.
But by all means, if anything I say here makes you think ‘that guy should just be doing…XYZ’, please, let me know. If I somehow missed some great tutorial, or keystone documentation which makes everything clear, point it out and link to it!
(But for the love of Boolean Algebra, don’t point me at another Blueprint VR template, please!)
Every problem my team have encountered so far might be justifiably attributed to ourselves, and a lack of experience with various tools, etc.
However, it really feels like VR development for quest with all versions of UE5 (no experience of UE4 VR) is not exactly ‘stable’, or ‘production ready’ yet?
This is in contrast to my experience with UE5 PCVR, which although it has had its issues (different shadows in each eye anyone?) seems to be improving and fixing things over time.
So, IS IT CONSIDERED PRODUCTION READY FOR VR?
Do people consider a ‘good’ choice for stand-alone VR?
Do people consider it even a ‘viable’ choice, right now (as of 5.5.3)
And if the answer is ‘yes’, are there caveats?
yes, but not for stand-alone quest for example (my most recent experience)
Teams choose unreal engine over other engines, because they want graphical fidelety.
I realise compromises need to be made for stand-alone VR, but if I wanted to turn everything off to get things working, and have something totally bland and unappealing… we could have just used Unity 
As a long time developer, I gotta say, developing with UE specifically for Meta Quest VR has been/is somewhat of a nightmare, somewhat akin to herding a bunch of cats.
Drowning in INI settings
Part of the problem is the plethora of INI file settings which seem very brittle in the exact combinations which are permitted on various devices.
With ‘standard’ PC unreal development, you turn settings on/off to achieve something, add or remove a feature/whatever.
But with mobile/VR development (specifically Quest stand-alone) if you look at those INI files the wrong way, you end in a mess with barely any idea how to get out of it.
Many of the settings, if modified, require an editor reboot and shader recompile, which makes ‘learning by discovery’ extremely expensive, and as some issues may be caused by combinations of settings, ultimately not helpful anyway.
Couple that with sometimes lacking documentation, for example, in Engine Rendering >> Mobile:
‘Mobile Local Light Setting’ tooltip says - Select which Local Light Setting to use for Mobile
It might as well have said This is a tooltip
Internet search for ‘unreal engine “Mobile Local Light Setting”’ on either Google or DuckDuckGo, and you get nothing of use.
Worse still, search for it on the official Unreal website, and you get absolutely nothing.
I worked out that I can enable it, disable it, or enable it with a buffer. (I read the dropdown choices)
Great, but what does it actually DO, and what are the ramifications of each choice?
Lightmass (CPU)
Arguably an essential part of VR development due to performance requirements, particularly on stand-alone quest devices, using lightmass has problems.
(I wont even talk about GPU lightmass, as it seems simply broken for most serious uses.)
-
Sometimes you build lighting and everything is fine, sometimes you build it and switch to vulkan preview to see everything is a glowing shade of purple or green? No idea what that is about.
-
Sometimes, you rebuild reflections and everything ‘fixes’ itself, sometimes it does not.
-
Sometimes you activate PIE and things fix themselves, sometimes not.
-
Sometimes even a tiny landscape gets weird broken texturing after building the lighting
-
You can only start a lightmass build in default rendering mode - but no similar prohibition/errors are attached to building reflection maps? Why? That seems inconsistent.
Would it be so hard, from a UI/Ergonomics view, to allow the build to be invoked from anywhere? Just automatically disable the preview and start the build…please? Why make us need another mouse move & button click to disable a preview first? -
Speaking of inconsistencies, ‘Build all Levels’ vs ‘Build lighting only’ do not work as many people would assume.
If you are trying to clear your light maps (in a vain attempt to then try to have them rebuilt properly), and you tick ‘Force no precomputed lighting’ you then need to rebuild lighting to cause the maps to be discarded.
Except ‘Build lighting’ refuses to operate once that checkbox is ticked, and you must instead click ‘Build all levels’. There may be important reasons behind this, but nobody I have spoken to can understand what they might be. It just seems inconsistent and weird. -
In the best possible outcome, why does what you see in the vulkan preview/on the quest device NOT LOOK THE SAME COLOR/LUMINOSITY as in default PC rendering?
candelas or lumens are the same light units regardless of renderer, and exponential falloff should work the same regardless of which hardware platform you are targeting, so why is Android Vulkan either way darker (in my case) or way brighter (for some others)? I would certainly expect certain qualitative differences, after all they are different renderers/shaders being used. But huge differences in the perceived light levels?
That doesn’t seem right. Plenty of people seem to try and work around that by simply ‘cranking up’ their lighting - but that’s a dirty hack and certainly not the direction we should be going in longer term.
Especially if, as many developers do, you wish to eventually target multiple platforms, something which has always been one of the inherent strengths of Unreal.
Anyway, that’s basically it.
Helpful comments please?
Stuff I missed?