Hello!
Unity Editor version: 2022.3
ML2 OS version: 1.8
Unity SDK version: 2.5.0
I've been investigating methods to modify the camera FOV settings in the ML2 SDK and would like to share my findings and ask for guidance.
Through code inspection, I found that the FOV is defined in the MLDepthCamera.Intrinsics struct (UnityEngine.XR.MagicLeap namespace). However, the API documentation explicitly states it's currently read-only:
"The API only supports reading data from the depth camera. Apps cannot modify the camera settings, support for the same may be added in a future release."
I've also noticed that modifying the FOV through Unity's Camera Inspector doesn't seem to affect the actual camera view. This suggests there might be an override happening at the SDK level.
My questions are:
- Is there an alternative method to modify the camera FOV that I might have missed?
- Is FOV modification something that's planned for future SDK releases, when?
- If FOV modification isn't possible, what's the recommended approach for applications that need different viewing angles?
Thanks for your help!
To make sure I understand. You are trying to make the Unity virtual camera render a smaller FoV ? Or are you trying to change the FoV of the physical cameras on the device?
Hey
I need to achieve a wider camera FOV because the current default makes distant objects (e.g., 10m away) appear much closer (~5m), affecting depth perception.
What I Need:
- A way to increase the pass-through camera FOV for a more natural perspective.
Is Quad the only option or are there other workarounds?
Im not sure why you are running into this issue. It would be helpful if we had some repro steps.
That said, you are correct, you would need to use Unity’s APIs since the camera is tied to the headset’s display.
Hey, today’s testing results:
Virtual objects that are scaled to match real-world objects appear slightly larger than they should, creating an illusion that makes them seem bigger than they actually are. This issue can be corrected by moving closer to the object; however, this limits the ability to visualize objects beyond 5 meters, making them appear unrealistically scaled.
To test this, create a 3D model of an object that you can compare to something in your real world environment from a distance of 10 meters. Place the 3D object precisely where the real-world object is, ensuring that both are the exact same size. Then, step 10 meters away and observe how its scale appears compared to the real world object.
What should happen is that when you walk further the scale of the 3D model becomes larger than the real world object.
Thank you so much for that. A few more questions
Are you using the device with prescription lenses?
Have you ran the eye calibration through the Fit app?
If you are using OpenXR do you mind testing if specifying Reprojection improves the quality? Reprojection | MagicLeap Developer Documentation
I also wonder if this is due to the optics, or if the headset is accumulating some tracking error when you are moving 10 meters - which could result in the device thinking you moved slightly less than the exact 10 meters.
Hey,
I am not using prescription lenses.
After performing eye calibration, the problem worsened significantly—tripling in severity. It’s seems that this calibration reduced the field of view enforced by the Magic Leap 2.
I am also not using Reprojection, but that doesn’t seem to be related to the FOV or distance scale issue.
The main problem is that distant objects appear larger than they should, distorting their scale. For example, an object that should appear 5 meters away instead looks like it is only 2 meters away. This suggests that something in the rendering process is affecting perceived depth and size.
According to Magic Leap’s documentation, there are three Reprojection modes:
- Depth Mode: Uses full depth data for the best stability but comes at the highest processing cost.
- Planar From Depth: Automatically calculates a plane for balanced performance.
- Planar Manual: Allows the user to define a plane manually for stationary content.
However, none of these modes seem to resolve the scaling issue.
I haven’t tested Reprojection yet, as the documentation states that it will not fix this problem.
Finding a solution would allow us to continue using the Magic Leap 2 effectively with our clients.
Unfortunately, I have not been able to reproduce the issue. I tried to come up with additional tests like with the Magic Leap 2 Meshing API, which overlays a mesh on the physical environment. However the virtual and physical content seemed to overlay correctly without issue.