As mentioned above, the non-OpenXR SDK independently developed by Qualcomm, that is, the SnapdragonXR-SDK (SXR SDK) will no longer be maintained after version 4.0.6, and will be replaced by the Snapdragon XR OpenXR SDK v1.x based on the OpenXR standard. Series SDK (the name is a bit confusing, but the points are clear), from the initial official version 1.0 this year to the current version 1.5:
The original plan of this article is to directly explain the development of QXRservice based on Snapdragon XR OpenXR SDK v1.5 , but I still feel that it is necessary to learn more about Qualcomm's SDK first.
This new version of Qualcomm SDK
is oriented to the content layer and based on the OpenXR standard;
oriented to the device layer , the implementation of Runtime encapsulates the open source Runtime mentioned in the previous blog : Monado;
the Runtime not only encapsulates the open source Monado, but also integrates the middle layer of Qualcomm The core QXRService is wrapped in it.
The following figure is the overall architecture of Qualcomm's new SDK middle layer:
In the new version of the SDK, Qualcomm changed the name of the original QVRService to QXRService in many places. It is not difficult to see that Qualcomm wants to lay out the basic ecology of VR, AR, and MR (collectively referred to as XR) in the future through this OpenXR-based SDK.
Next, take a look inside this version of the SDK:
It is mainly divided into five parts:
1. Apps
2. Compositor
3. Controllers
4. device_config
5. OpenXRLoader
6. Runtime
to see one by one
1.APP
Mainly some Demo apks.
These apks are based on OpenXR/Vulkan and OpenGLES. The native app
code is not open source. There are only Apk and bat scripts for installation in each folder.
Example: HelloXR:
2.Compositor
The role of Compositor lies in rendering-related processing such as PTW, ATW, and ASW. In the open source Runtime Monado, the Compositor part is written in the monado code using shader code. However, Qualcomm has made many extensions to Monado and separated the Compositor part. , encapsulated into a separate so in the Runtime.
There are only two header files in the Compositor folder of the SDK, which may be for Qualcomm to facilitate the integration of TW rendering-related algorithms by some customers.
3.Controllers
There is a doc description document and two snapdragon-openxr-input-plugin.aar plugins in the Controllers folder, which are debug and release version plugins.
This snapdragon-openxr-input-plugin.aar plug-in is the aar report of the "external device" packaged by Qualcomm that is connected to the Runtime Interface. This plug-in is required for the access of controllers, gestures, bracelets and other peripherals.
Only by loading this input-plugin plug-in and accessing Qualcomm Runtime to realize the relevant Interface, the Pose and Event generated by the peripheral can be passed up to OpenXR through the Runtime, and then passed to the content side.
4.device_config
Anyone who has done VR head-mounted display calibration should know the function of device_config. It mainly saves the distortion parameters of each camera of the head-mounted display, the name of the definition, the specification size; the specification of the IMU, the detailed parameters; the detailed parameters of the visual frustum, etc. configuration file.
In addition to the configuration file in the device_config folder, there is also a script to push the configuration file to the corresponding path of the device:
The device_config subdirectory and its related configuration files:
These configuration files, including the qvrservice_config.txt file under /vendor/etc/qvr, will be used during the calibration, use and function program development of the headset.
Among them, it is worth mentioning the /vendor/etc/qvr/qvrservice_config.txt file, which saves some of the most basic configurations of VR headsets. Once modified, it will affect the entire headset, so except for temporary use by developers, generally It will not be used, but trinity.txt will be modified in a targeted manner
5.OpenXRLoader
What is stored in this directory is what was mentioned in the previous blog. The OpenXR layer is used to load the OpenXR Loader of the Runtime layer. Its compilation method can be modified in OpenXR, and it can be compiled into so or aar package.
It is compiled into an aar in the Qualcomm SDK.
6.Runtime
At first glance, there is only one Runtime Apk and one bat script in the Runtime directory, but they have to be disassembled for a detailed look.
Change the apk suffix of openxr_runtime_app-inputService-release.apk to zip, and then decompress it to see the following:
There is nothing substantive in assets, kotlin, and res. You don’t need to look carefully, but focus on the lib directory. The specific disassembly is as follows:
The three libraries marked with blue boxes:
libqxrcamclient.so
libqxrcoreclient.so
libqxrsplitclient.so
These three libraries are what we develop, that is, we are the library files we need to develop based on QXRService. Although libqxrsplitclient.so is generally not used, it is still brought.
Two other points worth noting:
(1). The library starting with libqvr and libqxr is the encapsulation of QXRService in the Runtime of this version of SDK
(2). libqxrcamclient.so / libqxrcoreclient.so / libqxrsplitclient.so, compared with the old version 4.0 .6 SDK, the name prefixes of these three libraries have been changed from libqxr to libqxr, which also shows Qualcomm's long-term plan to lay out the XR industry ecology through the new version of SDK.
Conclusion: If you are making XR products on Qualcomm's platform, in the Snapdragon XR OpenXR SDK v1.x series SDK that Qualcomm is continuously releasing, the development of QXRService is the most critical part of connecting the self-developed algorithm to the Qualcomm SDK.
At present, based on QXRService, the self-developed Qvrdatalogger tool similar to Qualcomm has been developed , which can successfully capture the following important basic data and other required data:
(1). Top and bottom Slam Camera image data
(time stamp, Exposure time, image memory address, FrameNumber and other image details)
(2). IMU data (time stamp, gyroscope data, accelerometer data) (3). Pose data output by Qualcomm SLAM (time stamp, position, four elements)
In the follow-up blog, I will continue to use two to three articles to explain the detailed development process.