Anti Aliasing In Unity with URP
Hiya! So I'm having issues with Antialiasing in Unity on a Quest project, it doesn't seem to matter if I have my project set up based on the Oculus documentation or not: https://developer.oculus.com/documentation/unity/unity-conf-settings/ Things are still looking pretty chunky, maybe I'm not understanding how to manually set the MSAA level, in my understanding it's the pipeline asset that has to be set to 4x MSAA Project Setup: Unity 2021.3.11f1 Unity XR System w/Oculus XR Plugin GLES not Vulkan Doesn't seem to matter if I'm in Multiview or Multipass. FXAA does... something, but its just blurry. I've read that for certain setups you have to disable antialiasing in the camera, only enabling it in the pipeline settings, this didn't have the desired effect for me. Finally, questions: How essential is the Integration Package to MSAA functioning correctly on the quest? Am I required to use an Oculus camera rig instead of the Unity XR Rig for Antialiasing to function correctly? Also if anybody can share with me screenshots of a working URP+MSAA Unity setup configuration I would be very grateful.
"OpenGL supports only the default graphics adapter."
For some reason I can no longer run the OculusRoomTiny sample program anymore because I keep getting this pop up "OpenGL supports only the default graphics adapter." It's being triggered by this code shown below in main.cpp: if (Compare(luid, GetDefaultAdapterLuid())) // If luid that the Rift is on is not the default adapter LUID... { VALIDATE(false, "OpenGL supports only the default graphics adapter."); } and static ovrGraphicsLuid GetDefaultAdapterLuid() { ovrGraphicsLuid luid = ovrGraphicsLuid(); #if defined(_WIN32) IDXGIFactory* factory = nullptr; if (SUCCEEDED(CreateDXGIFactory(IID_PPV_ARGS(&factory)))) { IDXGIAdapter* adapter = nullptr; if (SUCCEEDED(factory->EnumAdapters(0, &adapter))) { DXGI_ADAPTER_DESC desc; adapter->GetDesc(&desc); memcpy(&luid, &desc.AdapterLuid, sizeof(luid)); adapter->Release(); } factory->Release(); } #endif return luid; } I've never had this issue before, haven't changed any code, reinstalled the SDK, and I still get the same problem - did something happen to my headset - why isn't the luid the same? I'm using the DK2 and SDK 1.9.0 When I comment out the VALIDATE statement, the program runs, but the oculus just gets stuck in the "please wait" screen forever. Thanks for your help in advance
How Can I Turn Off the "Frames Per Second" Overlay on My Quest 3?
Every time I turn on my Quest 3, there is an unwanted "Frames Per Second" overlay that pops up, and stays on my screen no matter what I do; and I really want to turn it off! See the attached picture that I mocked-up as an example of what I keep seeing so you'll understand what I'm dealing with. Please Help if you can! Thank You in Advance!
Accessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.Building NE9: A Runtime and App for AI-Driven Interactive 3D and XR Worlds
Hey everyone, I wanted to share what I’m currently building and open it up for discussion. I’m developing NE9, also known as NastyEngine 9. It’s a modular, real-time runtime designed to integrate AI systems, 3D environments, and interactive applications into a single live pipeline. Alongside NE9, I’m building a companion app that interfaces directly with the runtime. The goal is to use it as a control and integration layer where scene logic, agents, and interaction can be composed and updated live instead of being locked into a traditional editor workflow. The core idea is to treat AI, rendering, networking, and interaction as runtime-orchestrated systems rather than isolated tools. This approach makes it easier to experiment, iterate, and eventually extend into XR and VR environments. This is an active build and the architecture is evolving quickly. I’ll be sharing progress, experiments, and lessons learned as things continue to come together. This screenshot shows where we are right now in the development process. This was our first full session using Meta Quest 3 connected to our desktop via USB, running the Meta desktop app as our development workspace. We were viewing and working directly with our existing tools inside the headset to get a real sense of scale, comfort, and workflow. It was our first serious hands-on development session this way, and getting our feet wet was a lot of fun. Even just working from the desktop inside the headset made it clear that this is a platform we’re excited to build for. We’re looking forward to transitioning from desktop-based development into deeper Horizon and native XR workflows as NE9 continues to evolve. If you’d like to connect, feel free to check out my LinkedIn. Thanks for stopping by, and I’m excited to see what we can build together. https://www.linkedin.com/in/daniel-harris-0745b8374/WebGPU Compute into WebXR on Quest
Anyone know the expected date for Meta Quest's WebGPU-WebXR layer? i just purchased a MetaQuest 3, to complement my Quest 2, for WebXR development *with* WebGPU ( Compute-Shader only Voxel/SDF engine ) and found Meta-Browser's doesn't support WebGPU-WebXR, a 'Chromium 134' stable feature. Suprising since Quest 3 is a "Flagship of XR" device ( in terms of sales/popularity/development ). Reference check here: https://immersive-web.github.io/webxr-samples/webgpu/ i've web-searched extensively yet not found a workaround/flag to set or anything to do other than the suggestion to build a WebGPU copy into WebGL context ( wasting bandwidth/VRAM on copying the XR canvas? ) Am i missing anything? Thx---XR Headtracking breaks in build on Meta Quest 3 after headset goes to sleep
1. What happened Recently, we have begun encoutnering an error with our builds of a VR App for the Meta Quest 3 headset. Every now and then, after having our App open on the headset and setting it aside, where it then goes into sleep mode, an unexpected effect will be permenantly applied to the session. When you press the Meta home button on the right controller to bring up the overlay menu, the camera in Unity loses tracking of the headset. The camera gets put into the floor of the scene and the picture does not move along as you move your head around in VR. When you unpause again tracking is regained, but from then on, pausing causes this graphical error consistently. We are uncertain when it began but it is likely related one or both of these changes our project recently went through: - Updating our Unity with the new security patch (We went from Unity 6000.0.51f1 to Unity 6000.0.58f2) - Recent updates to the Meta Quest 3 headset The most likely suspect is the Meta Quest 3 update, as the error is reproducible on older builds made before the security patch. It is additionally not possible on Meta Quest 2 headsets, which supports this idea. We will also be reporting this issue to Meta, as it is unclear if this is an issue that should be solved in Unity's XR systems or in Meta's software. 2. How can we reproduce it using the example you attached I have attached a project built clean from scratch, following Meta's guide found here: https://developers.meta.com/horizon/documentation/unity/unity-project-setup/ Using the attached project, here's a step by step guide how to reach this bug: 1. Make a build for Android with the attached project 2. Load the APK onto a Meta Quest 3 headset 3. Open the app and verify head and hand tracking are working in the scene 4. Set aside the headset for around 30 seconds (this has been the most consistent timing for us to reproduce this bug) 5. Put the headset back on and verify that everything is still working as expected (move your head and hands, pause using the Meta Home Button, etc.) 6. Set aside the headset again for another 30 seconds 7. Put it one once again 8. You should now see that, when you bring up the Meta overlay menu with the Meta Home Button, the camera in Unity gets stuck in the floor and loses tracking. When you unpause, tracking is regained. But from then on, tracking is lost every time you bring up the Meta overlay menu. Additional info: - The bug goes away again if you do another round of setting the headset aside for 30 seconds. Doing so will give you a none buggy session again. Presumably more 30 second cycles will continue to switch between having the error and not having it Link to repo with the test project: https://github.com/PeterrificHC/XRSleepPauseErrorHow to occlude objects at a far distance?
I have a big virtual environment with some pillars. Currently, the AR objects are being rendered over the pillars. I would like a way to occlude the objects where the physical pillars are so that the virtual objects appear to be behind the pillars. In the HoloLens and Magic Leap, I would simply include the virtual pillars and put a matte black material on them. The headset would render the black objects (the virtual pillars) as passthrough, and occlude any virtual object behind them, thereby making the virtual objects appear to be behind the physical pillars. How do I do something similar with the Quest 3? When I research this topic, the solution seems to be use Depth API, but my virtual environment is much too large for that solution. How do I get a virtual object to appear behind a physical object that is far away? Thanks.
