I’ve been putting together a component based system that needs to run on Quest 2 and in 4.27. I created and implemented the system into the VR Template scene and, after the expected error hunt, was able to run it perfectly over virtual desktop win the editor’s VR preview mode.
Functionally everything works.
When I build, it’s successful 100% of the time.
When I run it on the headset, it begins to load with a black screen, then crashes to the menu before completing.
Now, hours later, I’m dozens of builds deep trying to find the cause of the issue without a single error message to go by. I’ve deleted out every single node from the component’s blueprint, and it still wouldn’t run. I kept deleting chunks until I had deleted the functions (all empty) as well and it finally loaded into the map on a headset. When I try starting over and deleting the functions first, it remains broken.
Is there a better way to identify the cause of crashes during the loading of an app?
While I didn’t exactly find a better way to diagnose the problem beyond moving faster and faster through the same build/sideload/run/uninstall loop, I was able to solve my problem.
I had assigned a variable type to an object reference of a custom blueprint. It worked fine in editor, yet somehow was not allowed on the target platform. Frustratingly, this incompatibility was true regardless of whether the variable was assigned. Even with every single node and function on my blueprints deleted and all my remaining variables renamed, the crash persisted. It wasn’t until I started deleting sets of variables and then deleting individual variables that I was able to single it out.
Moral of the story: everything is illegal, especially variables.
When you launch on a device such as a Quest or an Android Phone, you can open the “Device Output Log” and you’ll see what’s happening on the device. Great way to spot print strings that you’ve added in realtime, or scrolling/searching through the log after the play session.
Is there a comparable feature when running from a packaged build? I hadn’'t familiarized myself with Launching as I was trying the most accurate compatibility scenario as possible.
I start out by covering some of the basics with the Vulkan preview mode in editor. Gets me something like the real colors at least and generally covers some of the feature compatibilities. Then I stream the editor to VR over virtual desktop to test the intended function. The last check is to build it and confirm the fundamentals are working at all.
Launching seems like a kind of a lightweight version of building with added feedback during that crucial startup.
I was able to quickly break the blueprint in order to test Launch with the Device Output Log open. That particular log showed nothing, probably because the application never finished loading. It goes to the loading dots over a black screen, then crashes. The output log, however, did give me some fresh warnings and errors to sift through if I ever wanted to maybe find the problem. They sound unrelated (the variable in question references a point light) but maybe if I dug deep enough I’d find it.
These are the extracted warnings and errors (in order but skipping duplicates and other lines):
LogImageWrapper: Warning: PNG Warning: iCCP: known incorrect sRGB profile
LogImageWrapper: Warning: PNG Warning: iCCP: cHRM chunk does not match sRGB
LogMaterial: Error: Loading a material resource None with an invalid ShaderMap!
LogMaterial: Error: Tried to access an uncooked shader map ID in a cooked application
LogMaterial: Warning: [AssetLog] /Game/UltraDynamicSky/Materials/Material_Instances/DLWE_Brushes/Ripple_Brush.Ripple_Brush: Failed to compile Material Instance with Base DLWE_Brush for platform SF_VULKAN_ES31_ANDROID, Default Material will be used in game.
LogMaterial: Warning: Invalid shader map ID caching shaders for ‘DLWE_Brush’, will use default material.
Yep. There are a few features that predictably won’t work, like volumetric clouds and auroras, but overall it runs smoothly and predictably. It’s more usable for my pipeline than the default SkyAtmosphere pipeline because it displays the result on a mesh skybox which was the fix I found earlier for making SkyAtmosphere actually show up correctly.
Whatever material isn’t carrying through doesn’t seem to be visibly apparent. For now it’s seemingly harmless.
None of the log messages seem to match the variable type issue I ran into, so technically I still don’t have a way to track it down without brute force deduction. I’ve already found and fixed it in my case, so this is purely my learning a few extra logging methods.