Quest 3 POW level stuck at 3, Passthrough + Depth API
So I have this small Quest 3 App, basically a penalty shooter, using Passthrough + Depth API + Shadows + Vulkan (as requirement for Depth) For the 3D elements I have the goal, goal keeper gloves on the user controllers, a mascot character that shoots, and behind him a simple "screen" on a simple steel structure, this screen actually just has a couple textures to update the game progress. I also have a couple sound effects. When I launch it on Q3, with OVR settings I can see the power level of GPU&CPU is always at 3..... Also the scene starts with depth api off, there I have 72 fps, if I turn on soft occlusion drops to 30-50 fps.... What I dont get is I have another VR game, that has way more 3D elements, textures, interactions, a rig on the user, and CPU pow is at 5 and GPU at 4..... Why am I not getting higher power level on my Mixed Reality little game? here's the settings im using on the MR game, on the VR one its pretty much the same. I will send this MR game to AppLab and I'm worried it could get rejected by the performance, if there's any Meta staff reading this, game starts with Depth off, and on the start menu there's a toggle to enable it, would this help with the app review ? thanks!
Unity ASW URP Fork doesn't work with RenderTextures / Lit Shader
I'm using the Meta URP fork for ASW support (Unity 2022.3). I also have functionality in my game for taking an instant photo onto a RenderTexture. However when I do this the images I get seem to be showing the motion vectors and nothing else. Its definitely due to the fork as identical setup (Vulkan / Standalone build) worked perfectly before the switch over. PCVR / DX11 works fine either way. Is there any way to strip the motion data out of these or a way to force that particular camera to not do the motion vector pass? Also reported here with images: https://github.com/Oculus-VR/Unity-Graphics/issues/34Unity ASW URP Fork doesn't work with RenderTextures / Lit Shader
I'm using the Meta URP fork for ASW support (Unity 2022.3). I also have functionality in my game for taking an instant photo onto a RenderTexture. However when I do this the images I get seem to be showing the motion vectors and nothing else. Its definitely due to the fork as identical setup (Vulkan / Standalone build) worked perfectly before the switch over. PCVR / DX11 works fine either way. Is there any way to strip the motion data out of these or a way to force that particular camera to not do the motion vector pass? Also reported here with images: https://github.com/Oculus-VR/Unity-Graphics/issues/34 Sorry for repeat convo (put in the wrong board to start with)
Sampled Pixels from Render Target Being Clamped in Package Build
Hello, using Unreal Engine to make a VR project and in the VR Preview everything is working as expected, but my RTF RGBA16f render target which I am using to encode local position data in the pixels (which can be negative or greater than 1.0) are being clamped when sampled on the package build to 0-1; but not in the VR Preview or PIE modes. It seems like there's some subtle difference between Directx12 and Vulkan regarding the texture formats? What can be done to resolve the issue? It's pretty important and would be a massive inconvenience to refactor things to be normalized in a 0-1 range. It is preferable to be able to preserve and sample the raw values as originally encoded.
Standalone Vulkan in headset not working correctly - Huge Flickering, Incorrect frames
Hello, I'm working on a game with The Mirror (https://www.themirror.space/) , we've spoken to support at Godot Engine and they have mentioned that the Quest 3 has a Vulkan issue where the headset flickers intensely. We are experiencing this issue but only on the meta quest 3, on Mac, Windows, Linux and the quest 2 we don't have the same rendering problem. I have made a video of the issue please see the video https://www.youtube.com/watch?v=gd4NBKl0Gro The team at Godot Engine have tried to resolve this problem before for quite a lot of users but haven't been able to locate the source of the issue apart from it seems to be driver related for the adreno 740 in the meta quest 3. I am not a driver/rendering expert and would appreciate any help with this issue. The API is using Vulkan 1.0 and Vulkan 1.1, it has Vulkan 1.2 available too. I can provide full source code. Thanks, Gordon MacPhersonQuest 3 Vulkan Drivers Unreliable and Broken - Snapdragon 8 Gen 2
We're having random frame corruption in the meta quest 3. We've successfully reproduced in RenderDoc for meta quest 3 https://www.youtube.com/watch?v=yA2IgZbUIMg The frame capture is here for render doc meta fork 63.3 (forked from v1.32) https://drive.google.com/file/d/12V9ZBZHsleYibw7s8Xj6ZO_ZJsgfPILy/view?usp=sharing Can we please get support from meta or snapdragon here? We've had snapdragon keep referring us to Meta for help with this, This is also reproduceable on the One Plus 13 which shares the same base hardware Snapdragon 8 however it is generation 3 not generation 2.
Unreal Engine light baking in external editor vs. light buildin in editor for Quest
I have been trying to convert some simple projects to Oculus Quest packages. I am relatively familiar with how light building in Unreal Engine works, but the result looks so different in Vulkan preview mode and on the deployed version that I am wondering if I am doing something wrong. Generally, after baking the lights and switching to Vulkan preview mode, everything looks desaturated and lacks contrast. As a test, I used Blender to bake the direct and indirect light of a scene onto all models, to then use this texture for an unlit material in UE. I was blown away by the quality, which stays almost the same on Vulkan. I do understand that baking lights in the texture using an external editor will look good but will also have several limitations in terms of dynamic lights and shadow casting. What I really do not understand, is why baking lights in UE with production quality settings keep ending up in a massively downgraded Vulkan conversion. Am I doing anything wrong? Do you have any suggestion on the best practices, also related to external software baking? I am using UE4.27.2, vanilla branch from the Epic Games Launcher.
OpenGL crashes on Unity 2022.3
I have an application that crashes on start (Unity 2022.3) when built using OpenGL graphics API, switching to Vulkan stops the crashes, but we cannot switch due to requirements. I have narrowed it down to the OVRHandPrefab. If I remove the use of prefab from my rig, the crashes on start stop happening as well (in OpenGL). I am attaching a picture of the Android Logcat crash. Any ideas or solutions?
