ML2 OS: 1.1.0
ML Hub: ML Hub Version 2.0.8.202302102204
ML2 Unity SDK: 1.3.0
Device Stream settings: MR - 1080p - rtsps - 9:10 - UDP over Wi-Fi
It was not possible to achieve superimposition between holograms and reality while streaming ML2 content on ML Hub
Hi @filo.cino thank you for your post. It's best to post Device Stream error logs so we can better understand your issue.
Thanks for your quick reply @kdowney! I do not mean it happens in a specific confdition. I have never been able to exactly replicate the same reality-holograms superimposition I have on the glasses on the external monitor I am streaming on.
There is always the same offset due to the fact that the "extenal world" camera is not in the same place as my eyes are. Do you have thought about a software correction for the streamed holograms as for the HoloLens 2?
Specifying the stereo convergence point in Unity or the Focus point in a native app improves the camera alignment .
See the Unity guide here:
https://developer-docs.magicleap.cloud/docs/guides/unity/display/unity-stabilization-overview
And the more general guide here:
https://developer-docs.magicleap.cloud/docs/guides/best-practices/improve-visual-stability
his solution addresses the visibility issue of MagicLeap2, but it does not solve my problem.
The problem I'm currently facing is that there's a slight discrepancy between the video captured by the camera and what the user sees, due to the difference in the positions of the user's eyes and the camera. In MRTK's HoloLens2, the problem is addressed as shown in the following URL:
Is there a similar solution for MagicLeap2?
Here's a screenshot of the issue being reported. Generally speaking, the content appears shifted about 4" upward and 2" to the right of the placement observed first-hand in the headset. As an example, in the attached photo, the buttons in the photo appear centered within the orange circle when viewed spatially, in-headset, but the circle is offset by that 2"x4" mis-position in photos and video taken from the ML2. This offset is pretty consistent regardless of the scene origin, content, scale, etc. It seems to be a simple function of superposition due to the offset of the camera vs the eyeball, that could easily be fixed in the capture API logic (hint: anchor the virtual content slightly down and to the left in the recorded camera frustum to account for the camera offset)?.
Hi @cstavros,
Thank you for reaching out regarding this issue. If we were to add this feature in the capture API logic, how would you like to see it implemented?
Best,
El
