UE5.3: Roomscale and stationary boundaries break my Player Start! Why?
Hello, I'm having some strange problems. While I try out my test level with the Meta Quest at my workplace and in the Unreal Engine, everything works fine. Now I have created an APK file and installed it on the quest and have the following problem (see also the picture): 1. in the editor "PlayerStart" is at the position and rotation as shown in the picture (see number 1 in the picture). This also works when I test it in the engine and with Meta Quest. 2. However, if I start the level natively on the quest (at a different place in my room), then I start somewhere else in the level and not at the set "PlayerStart" (see number 2 in the picture). And my triggers etc. no longer work. If I reset the position ingame (via menu button), then the player jumps back to the spawnpoint set in the editor (see number 3 in the picture), but the triggers etc. do not work either. If I start the "game" on my workplace, then the spawn position is correct and everything else also works. The spawn point should always be the same, no matter where I start the game from. I don't know why this won't work. New Update: I have found that when I have a stationary boundary (3x3 feet), it works as it should. But as soon as I set Roomscale (or when I am standing), I have the behavior as described above. I'm trying to create a game like "Moss", for example. I have a stationary VR character (first person) where I can interact with my hands and at the same time I control a 3rd person character. And with triggers etc. I then "teleport" the VR character to a different position. This works, but not as soon as I stand or activate Roomscale. And if I'm not in the center of the stationary boundary, then the rotation and position where I "teleport" the VR character is no longer correct. Does anyone have any idea?2.4KViews2likes4CommentsMRUK scene loading inconsistently
I am working on a mixed reality game and using the MRUK to load scene data. "Load scene from device async" doesn't seem to work. Before using the MRUK, I used the OculusXrSceneActor, which worked wonderfully, but now im kind of lost. Now, using the "Spawn interior" function, it does work -- but only for my collegue. I'm not sure what is happening, could use any clue as to what is happening. For some extra info: we check for permissions and launch the capture flow (which another post said could help fix issues with "missing" scene data)Solved2.5KViews0likes4CommentsPassthrough broken in v66/67 VRPreview
With the current Quest 3 firmware v66/v67 passthrough is broken in VRPreview, it is drawn on top and occludes all 3D content (passthrough layer "underlay"). Even the Meta PTSamples project isn't working anymore. Unreal Engine version and Meta plugin version do not seem to matter, the problem appeared with both setups: UE 5.3.2 and Meta v62 UE 5.4.2 and Meta v66 Is it just me? Is it possible to revert to an old Quest firmware? Thank you942Views0likes1CommentQuest 3 Specific Build for graphical update
We've been having some issues with trying to make a Quest 3 graphical update filed and wondering what the best method of doing this would be. We want to use device profiles to control both the texture resolution and other cvars that we are changing. We want to adjust the texture resolution and shader settings on Quest 3, making a specific Quest 3 build, without adjusting the Quest 2 package size. Firstly we had an issue with it detecting a quest 3 . Here is a log taken from the game running on a quest 3 01-28 12:53:41.013: D/UE4(3199): [2024.01.28-16.53.41:013][ 0]LogAndroid: Checking 35 rules from DeviceProfile ini file. 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: Default profile: Android_Default 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: GpuFamily: Adreno (TM) 740 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: GlVersion: OpenGL ES 3.2 V@0746.0 (GIT@e0d95b0057, I5811eb47b8, 1697869180) (Date:10/20/23) 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: VulkanAvailable: true 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: VulkanVersion: 1.1.128 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: AndroidVersion: 12 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: DeviceMake: Oculus 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: DeviceModel: Quest 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: DeviceBuildNumber: SQ3A.220605.009.A1 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: UsingHoudini: false 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: Hardware: eureka 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: Chipset: unknown 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: HMDSystemName: Oculus Quest2 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogAndroid: Selected Device Profile: [Oculus_Quest2] 01-28 12:53:41.014: D/UE4(3199): [2024.01.28-16.53.41:014][ 0]LogInit: Applying CVar settings loaded from the selected device profile: [Oculus_Quest2] For some reason it seems that the headset is reporting its name as Oculus Quest2? And as such the profile which is used is the Quest2 profile. This can be solved by changing the way that it decides which profile to use, but is a bit weird. At this point we do get a build that has any runtime changes made in the CVARs, but not any compile/cook time changes. I.e. We don't get the different texture resolutions that we want to use. We want a Quest 2 build that is not impacted by the larger texture resolutions that we can do on Quest 3, but not sure the way to do that in the device profiles & build step. We could manually change our build process to inject the Quest 2/3 details rather than using the device profiles, but would prefer to use device profiels if possible. Thanks for any help2.6KViews0likes8Comments- 1.5KViews0likes3Comments
PTC v66 - Extremely slow load time on larger unreal game
Large UE games are incredibly slow to load on v66 (like 25 seconds) The same apk/obb loads in around 3 seconds on v65 and earlier. It's built against the v65 SDK. Something really weird going on with v66. I also notice sometimes OS apps are hanging/going really slow to load (like airlink) To reproduce install asgards wrath 2, First run is a bit slow but normal, compiles shaders etc. Close it Second run sits on the ... screen for 25 seconds then loads. Same for all subsequent runs. [EDIT] This appears to be to do with the app's apk signing certificate. A load of errors in the log are occurring for the 20 second wait. Certificate buffer not long enough, returning If I rebuild my app with a new certificate it then works but I can't change this on the store773Views0likes0CommentsGet lighting data from HMD
I am currently developing a mixed reality experience, and was hoping to use lighting information from the headset cameras (Quest 3) to light the scene in real time. Is this a possibility? If so, how do I do this? I am using Unreal Engine 5.3 with MetaXR and the MRUK.473Views0likes0CommentsMedia Sound audio is recorded when is set to volume 0 in the app
Hi all, I have a project I am working on, it's an apartment where I have a TV with a video running in loop. The project is made in Unreal engine 5.1, and in the TV blueprint, I set the Media Sound volume to 0 when game begins, and switch volume according to when I turn on and off the TV. I was recording the gameplay on Quest 3, and despite in the game the audio answers to the interaction, when I watch the recording, the TV audio is loud and overlay every other audio effect from my game. This is the Blueprint, and the video is the recording from the Quest 3. The sound of the video worked just fine in the app when I was playing but in the recording it's like the TV was on all the time, really annoying. Now, is it some problem with the UE settings or the Quest Device?595Views0likes0CommentsFull Body Tracking poor performance in UE5 and Air Link
Hello everyone, I would like to use the Full Body Tracking feature with the Meta Quest 3 in my Unreal Engine 5.3 project. My Meta Quest 3 is connected via Air Link, and in the final game, the game should also run in this manner (the executable file should not be on the headset). I've noticed that as soon as I activate the Full Body Tracking of the Meta Quest (e.g., directly through the function OculusXRMovementFunctionLibrary::StartBodyTrackingByJointSet or simply OculusXRMovementFunctionLibrary::StartBodyTracking, or if the tracking is activated in any other way, e.g., via Live Links "ApplyToClient"), the framerate drops directly to 20-30 FPS, even without anything else happening in my sample project (no mannequin performing movements or anything). I've observed this performance drop even in the sample project here: https://github.com/oculus-samples/Unreal-Movement Through Unreal Insights, it's apparent that the RenderThread suffers greatly under the activation of the Body Tracking Start, consuming an average of 9ms or more (which should ideally only take 1-2ms in the sample project). Now, I'm wondering if anyone else has this issue, too or is this a known issue or if the executable file must reside on the headset for Full Body Tracking to work efficiently? I highly appreciate any responses.1.1KViews1like0Comments