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.
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.
Niagara particle colors broken in vulcan quest
Heyo, running into a weird issue where particle color just doesn't work on quest using vulkan On Vulkan Quest, using niagara: The node Particle Color in the material always returns blue rather than the colour that is set in niagara like it should do This doesn't happen in opengl or on PC Anybody ran into this before?
When is MetaXR OpenGL ES 3.2 Support Slated to occur? If ever?
Looking at the docs it seems like OpenGL ES3.1 is reported to be supported. But UE5 and 5.1 use ES 3.2. Having just tested MetaXR plugin with UE5.0 and enabling ES3.1 I found a brief but very vital warning stating "LogHMD: Warning: OpenGL is not currently supported by OculusXRHMD plugin". UE5 and 5.1 out of the box with OpenXR I don't belief share that information and simply crash when enabling ES 3.2. So essentially, is the aim to depreciate OpenGL ES 3.2 support? Will it continue to be supported until Vulkan reaches feature parity at least? Any news regarding this would be very helpful for VR Video Playback in Unreal and probably in general.UE5.1 6K Video Vulkan Performance Issues
Since 4.27 if you try and play a 6K video with Vulkan there is a big performance drop unusable. In 4.27 I managed to get our app to run with OpenGL but in 5.1 I haven’t managed to do that using OpenXR. My understanding is to use Vulkan as much as possible but atm this is not possible. What advice is there for 6K video playback on Vulkan in 5.1. or getting OpenGL to not crash in 5.1?
Absolute World Position in Material Error? - Unreal + Quest
I'm developing for Quest using Unreal with Vulkan. Project setttings are using mobile settings. No HDR, no post-processing, forward rendering, etc. I have a material which adds some fake lighting by calculating the distance from a flashlight object which uses a blueprint to pass the position into the material. This material works correctly on Rift, PSVR and PC-based VR platforms. It does not work correctly on Quest. What is happening is the light position appears in two different positions depending on the eye. In the left eye it appears that an object is lit but in the right eye it appears that the material is lit as if the object is moved a small distance to the right. This creates a mis-match between the two eyes. The material uses an Absolute World Position node plus it does a bunch of other calculations for light direction, etc. I suspect that the Oculus HMD code in Unreal is offsetting the meshes for the right eye differently for Quest than it does for the Rift. If anyone has experience with this or similar issues related to Quest I would appreciate your help. Thanks!CSM + FFR + Vulkan on 4.23.0 = glitches on Quest
Testing Vulkan on some projects. In one project I have; - a stationary Directional light + cascaded shadows enabled -> needed due to moving machines. - a static Skylight For perfomance, some level of FFR is needed.It all works fine on the Quest when Vulkan is not enabled. Enable Vulkan and many glitches appear in the cascaded shadows. Anyone noticed the same? Just reported @ Epic. Waiting to see if they can confirm as a bug. Tested on the latest 4.23.0 OC branch.
