-
Notifications
You must be signed in to change notification settings - Fork 3
Home
Welcome to Futurewei Technologies OpenXR-SDK wiki!
This repository is an open-source project to improve VR Glass, 6DoF immersive web and PC VR experience and development.
Please follow OpenXR-SDK announcements here - https://twitter.com/FwOpenxr
Date: TBD
Time: TBD
Venue:
Minutes:
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/37
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/36
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/35
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/34
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/33
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/32
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/30
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/8
Date: CET 2022-03-11 / CST 2022-03-11
Time: CET 9:00AM / CST 4:00PM
Venue: https://welink.zhumu.com/j/180357491
Minutes:
Date: CET 2021-11-25 / CST 2021-11-25
Time: CET 9:00AM / CST 4:00PM
Venue: https://welink.zhumu.com/j/180549643
Minutes:
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/22
- Developer has fixed several of the listed issues.
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/20
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/19
- Developer: when you connect the headset we would like HarmonyOS to choose the microphone from the headset as the default device. Is that the responsibility of your team or a different team? Currently, the microphone is still the mobile phone one so the volume is low. Doing this in Gecko is difficult because it doesn't have device selection but this might be something the HarmonyOS team or the SDK team can do. It makes sense that you default to the microphone of the device, as the mobile phone can be far away. SDK team: we will investigate that.
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/17
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/15
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/12
- Developer: we will implement everything for Oculus Quest 2, and then you can use our implementation as a test case for the OpenXR SDK. You can use our app as a test case. SDK Team: This is in the to-do list, but it might take some months.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/11
- SDK team - please add maximum priority to this issue so we can focus on that.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/9
- Developer: We can close this issue because we are already doing the things described there, and the only pending bits are tracked in other issues. We will close the issue later.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/8
- Developer: Please publish the profile in the link that is in the issue, so that it is available for the developers. SDK team: The profile is on its way, and we checked-in in the demo, but it also depends on the manager to determine when to release our latest SDK (we don't know when). Ok with publishing profile in this issue.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/5
- Developer clarified the requirements and provided workarounds is not the correct solution. SDK team: unfortunately we cannot provide an answer. We will discuss with colleagues and managers and if we have any other information we will update the issue for you.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/3
- Developer is waiting for the fix and uses a workaround still for now. SDK team: could take 1-2 months to fix this in the SDK.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/2
- SDK team: that seems like an easy issue. In one week it should be fixed. We will update in the issue.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/1
- Developer was able to use XR_TYPE_ACTION_STATE_VECTOR2F but only with a single XR action set. It works that way, but there is a bug when trying to create different XR action sets, only one works. SDK team: will check and update progress in the issue.
- Other issues:
- #2 is the most important. #11 would be the second one. #5 would be the 3rd one.
- Developer: Right now it is working well for #5, although it is a workaround. The other two (#2, #11) have more impact. At some point, we would like to remove the workarounds, but this doesn't have an impact for the users.
CANCELED
Date: CET 2021-11-24 / CST 2021-11-24
Time: CET 9:00AM / CST 4:00PM
Venue: https://welink.zhumu.com/j/151894041 \
CANCELED
Date: CET 2021-11-23 / CST 2021-11-23
Time: CET 9:00AM / CST 4:00PM
Venue: https://welink.zhumu.com/j/152628116
CANCELED
Date: CET 2021-11-19 / CST 2021-11-19
Time: CET 9:00AM / CST 4:00PM
Venue: https://welink.zhumu.com/j/172684723
Date: CET 2021-11-05 / CST 2021-11-05
Time: CET 9:00AM / CST 4:00PM
Venue: https://futurewei.zoom.us/j/93902131841?pwd=OVJiTjlDU3R1THJiYVZsVGROQmZMUT09
Agendas:
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/1
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/2
- SDK team replies they are still looking into it.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/3
- Develoepr confirms that the buttons are working now using the new OpenXR mapping paths. The only issue is that left/right controllers are still reverted and FxR is still using a workaround for that. SDK team mentioned it's working in the demo. Develoepr: it could be related to the subaction path issue too.
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/5
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/17
- SDK team explains that is going to be fixed with "Fix the bug of 6dof helmet posture transmission", which was later than other tasks in the plan. Conversation about the priority of the task, and decision to make that task the highest priority, SDK team will update the issue and the estimated times of the plan. Developer explains the progress of the trackpad implementation and mentions some of the issues found:
- XR_TYPE_ACTION_STATE_VECTOR2F was not working and had to make extra code. SDK team mentioned to try a different path " /user/hand/left/input/trackpad/value" to use the Vector2F.
- Developer mentioned the values should be between -1.0 and 1.0 instead of 0.0 to 1.0 based on the OpenXR standard. Not urgent since using a workaround is easy to make the conversion.
- SDK team confirmed the trackpad error range is 0.05, and we need to ignore scrolling values less than that
- Developer mentioned an issue about only the first controller queries getting correct values for the trackpad. SDK team replied that it's working in the 6DOF demo for both controllers. Developer mentioned that a difference could be that FxR is using different actions with a single subactionpath and the demo is using single actions with multiple subactionpaths. Agreed on testing the demo and confirming if using subactionpaths works
- SDK team explains that is going to be fixed with "Fix the bug of 6dof helmet posture transmission", which was later than other tasks in the plan. Conversation about the priority of the task, and decision to make that task the highest priority, SDK team will update the issue and the estimated times of the plan. Developer explains the progress of the trackpad implementation and mentions some of the issues found:
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/19
- Developer looked into the low microphone issue, found the source of the problem but the fixes didn't work, added more details on the issue.
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/20
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/21
- SDK team confirmed that it's a bug in the SDK and is already in the plan
Date: CEST 2021-10-28 / CST 2021-10-28
Time: CEST 8:00AM / CST 2:00PM
Venue: https://futurewei.zoom.us/j/91398059719?pwd=cW9Td09pakJ3YkFBOUE2aTl2cGJGUT09
Agendas:
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/1
- VR Team reviewed codes and understand the issue now, will compile the source code and try to solve it by the deadline.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/2
- VR Team - this seems to be a bug. We have an app using this API. We need to make sure that when we change this we don't break the app.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/3
- Developer explains the issue, it is not difficult to use workaround, but VR Team should fix it. VRTeam: It works in their demos, maybe they can share the demo to see if it works; they can also review developer's source code.
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/4
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/5
- Developer clarified the information reported in this issue (use case and shows the codes/API), which is returning empty value but works on the Oculus OpenXR implementation. Developer shared public codes and compilation instruction. VR Team will try to compile and duplicate the issue.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/6
- VR Team to share their working 6DoF demo code to developer. Developer is adviced to show their related code in every issue so that VR Team can see how you the interface is being used.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/8
- VR Team will provide the profile in November.
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/9
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/10
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/11
- VR Team to provide non-animated 3D models to developer now.
-
https://github.com/hms-ecosystem/OpenXR-SDK/issues/12
- Developer explains the goal for VR Team to support Timewarp Layers is improving the image and video playback quality. In Oculus devices there is a huge quality improvements. VR Team: At a first stage we prefer not to provide those extensions. We could provide them in the future. We seem to need a lot of time to work on them. At this stage we prefer not to provide them. The feature needs to be in our runtime but our engineers don't have experience on these features. So we need time to know how to implement them. We need to find a solution. So we can provide this in the future. We understand the importance of the issue, and need some time. We will think about December and see if it is possible.
- https://github.com/hms-ecosystem/OpenXR-SDK/issues/15