A virtual reality (VR) device management method and system applied to a cloud VR application scenario
By simulating the driver and data interaction of VR devices on the server side, the problem of not being able to open VR applications without VR devices is solved, realizing the management of virtual VR devices in cloud VR scenarios and providing a convenient user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- WELLINK TECH CO LTD
- Filing Date
- 2022-09-23
- Publication Date
- 2026-06-23
AI Technical Summary
Without VR equipment, users cannot open VR applications, causing inconvenience.
The server receives the client's VR startup request, starts the virtual VR device, sets the resolution and frame rate of the rendered screen, uses the OpenVR API to drive the virtual VR device, simulates controller and headset data, and sends the rendered screen and controller vibration feedback data.
Even without an actual VR device, it can open VR applications and provide the same user experience as a real device, enabling cloud-based VR device management.
Smart Images
Figure CN115576416B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data communication, and more specifically, to a method and system for managing virtual VR devices in cloud VR application scenarios. Background Technology
[0002] With the rapid development of computer technology, virtual reality (VR) technology has gradually matured, and electronic products related to VR are increasingly entering people's daily lives and work. Virtual Reality (VR), also known as virtual reality technology, is a new and practical technology that emerged in the 20th century. Along with its emergence, the video game industry has also begun to utilize VR to enhance the gaming experience. It not only provides a fun and effective form of exercise but also allows users to experience entirely new gameplay. Therefore, VR is gaining popularity. However, a problem exists when using VR: without VR equipment, desired VR applications cannot be opened, causing inconvenience for many users.
[0003] Therefore, how to provide a virtual VR device management method that enables VR application software to be opened even without VR devices is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0004] This application provides a virtual VR device management method for cloud VR application scenarios, specifically including the following sub-steps: the server receives a VR start request sent by the client; according to the VR start request, the server starts the virtual VR device corresponding to the VR application; in response to starting the virtual VR device, the server sets the resolution and frame rate of the rendering screen of the virtual VR driver, and makes the resolution and frame rate of the rendering screen effective; in response to the VR application completing the rendering screen, the virtual VR device in the server sends the rendered screen to the client, and the client receives the VR application screen; the server receives the position, posture, and button data of the controller and title sent by the client, and sends the received position, posture, and button data of the controller and title to the VR application; the server sends the controller vibration feedback data of the VR application to the client, and the client receives the controller vibration feedback data.
[0005] As shown above, the VR launch request includes setting the resolution and frame rate required by the VR application.
[0006] As mentioned above, the client can be one of the following: VR device, mobile phone, or PC mobile client.
[0007] As mentioned above, the virtual VR device corresponding to the VR application launched by the server includes a driver that sends controller and head-mounted display data to the virtual VR device through a specified data interface, thereby enabling the virtual VR device to have a head-mounted display and controllers.
[0008] As shown above, the specified interface is the OpenVR API interface.
[0009] As shown above, the OpenVR API is presented as a C++ interface class and consists of pure virtual functions, including TrackedDevicePoseUpdated, Present, and GetWindowBounds.
[0010] As shown above, an image texture is created based on the resolution set in the VR launch request, and the game texture rendered on the headset is copied based on the created image texture, so that the resolution of the image data output by the VR application is consistent with the resolution set by the client.
[0011] As shown above, the virtual VR driver creates a thread to calculate the rendering time based on the frame rate set in the VR startup request, and completes the setting of the rendering frame rate based on that time.
[0012] A virtual VR device management system for cloud VR application scenarios is characterized by comprising a server and a client, wherein the server and the client interact with each other to complete any of the above methods.
[0013] As described above, the server includes a first receiving unit, a startup unit, a setting unit, a first sending unit, a second receiving unit, and a second sending unit. The first receiving unit receives a VR startup request sent by the client. The startup unit starts the virtual VR device corresponding to the VR application according to the VR startup request. The setting unit sets the resolution and frame rate of the rendering screen of the virtual VR driver and makes the resolution and frame rate of the rendering screen effective. The sending unit sends the rendering screen to the client, and the client receives the VR application screen. The second receiving unit receives the position, posture, and button data of the controller and title sent by the client and sends the received position, posture, and button data of the controller and title to the VR application. The second sending unit sends the controller vibration feedback data of the VR application to the client, and the client receives the controller vibration feedback data.
[0014] This application has the following beneficial effects:
[0015] This application enables the creation of virtual VR devices for application recognition through data interaction between the client and server without affecting the server-side VR application. Furthermore, when the client sends corresponding data, that data can be used as correct input data, thus achieving the goal of cloudification. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.
[0017] Figure 1 This is a flowchart of a virtual VR device management method applied in a cloud VR application scenario, according to an embodiment of this application.
[0018] Figure 2 This is a schematic diagram of the structure of a virtual VR device management system applied in a cloud VR application scenario, according to an embodiment of this application.
[0019] Figure 3 This is a schematic diagram of the server-side structure of a virtual VR device management system applied in a cloud VR application scenario, according to an embodiment of this application. Detailed Implementation
[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0021] Example 1
[0022] like Figure 1 As shown, this application provides a virtual VR device management method for cloud VR application scenarios. This method is an important part of cloud VR applications. By writing a driver, the VR application scenario recognizes the existence of a VR device on the server.
[0023] Specifically, in this embodiment, the device driver function is implemented based on the driver layer interface provided by OpenVR, and it exists in the form of a virtual driver, so that the VR application scenario will think that there is a VR device on the server.
[0024] Specifically, the following steps are included:
[0025] Step S110: The server receives the VR start request sent by the client.
[0026] The VR launch request sent by the client includes the pre-set resolution and frame rate required for the VR application.
[0027] The client side includes mobile devices such as VR devices, PCs, and mobile phones.
[0028] Step S120: Based on the VR startup request, the server starts the virtual VR device corresponding to the VR application.
[0029] Specifically, on the server side, the Activate function of the ITrackedDeviceServerDriver class in the OpenVR driver layer is used to implement a virtual VR device with a headset and controllers.
[0030] OpenVR provides a unified data interface for VR games, eliminating the need for VR games to directly interact with the manufacturer's SDK. Furthermore, OpenVR's API (Application Program Interface) is presented as C++ interface classes, and all are pure virtual functions, such as TrackedDevicePoseUpdated, Present, and GetWindowBounds.
[0031] Furthermore, the TrackedDevicePoseUpdated function is called to send the controller and headset data to the virtual VR device's driver.
[0032] Step S130: In response to starting the virtual VR device, the server sets the resolution and frame rate of the rendered screen of the virtual VR driver and makes the resolution and frame rate of the rendered screen effective.
[0033] The VR launch request sent by the client contains the resolution required by the VR application. An image texture is created based on this resolution, and the game texture rendered to the headset is copied based on the created image texture. This ensures that the resolution of the image data output by the VR application is consistent with the resolution set by the client. The set resolution is returned in the GetWindowBounds function of the IVRDisplayComponent class.
[0034] Furthermore, the VR launch request sent by the client includes the frame rate required by the VR application. Based on this frame rate, the virtual VR driver creates a thread to calculate the rendering time. For example, if the client sets the frame rate to 60 frames, the server needs to render one frame in about 1 / 60 of a second, approximately 16ms, by calling the VsyncEvent function to notify the VR application to render the screen.
[0035] Step S140: In response to the VR application completing the rendering, the virtual VR device on the server sends the rendered image to the client, and the client receives the VR application image.
[0036] Step S150: The server receives the position, posture, and button data of the controller and title sent by the client, and sends the received position, posture, and button data of the controller and title to the VR application.
[0037] Step S160: The server sends the VR application's controller vibration feedback data to the client, and the client receives the controller vibration feedback data.
[0038] Specifically, the server obtains events through the PollNextEvent interface. When the event type is VREvent_Input_HapticVibration, it is controller vibration feedback data, and then sends the corresponding controller vibration feedback data to the client.
[0039] Step S160: The VR application sends controller vibration feedback according to a pre-set program.
[0040] Steps S110-S140, S150, and S160 are executed in parallel. Through these steps, this embodiment can open VR application software even without a VR device, making it more convenient.
[0041] Example 2
[0042] like Figure 2 As shown, this embodiment provides a virtual VR device management system applied in a cloud VR application scenario, including a server 210 and a client 220. The server 210 and the client 220 interact with each other to complete the above-mentioned virtual VR device management method applied in a cloud VR application scenario.
[0043] Specifically, such as Figure 3 As shown, the server 210 includes a first receiving unit 310, a starting unit 320, a setting unit 330, a first sending unit 340, a second receiving unit 350, and a second sending unit 360.
[0044] The first receiving unit 310 is used to receive the VR start request sent by the client.
[0045] The startup unit 320 is connected to the first receiving unit 310 and is used to start the virtual VR device corresponding to the VR application according to the VR startup request.
[0046] The setting unit 330 is connected to the startup unit 320 and is used to set the resolution and frame rate of the rendering screen of the virtual VR driver, and to make the resolution and frame rate of the rendering screen effective.
[0047] The sending unit 340 can be a virtual VR device, connected to the setting unit 330, used to send the rendered screen to the client, and the client receives the VR application screen.
[0048] The second receiving unit 350 is used to receive the position, posture, and button data of the controller and title sent by the client, and to send the received position, posture, and button data of the controller and title to the VR application.
[0049] The second sending unit is used to send the VR application's controller vibration feedback data to the client, and the client receives the controller vibration feedback data.
[0050] This application has the following beneficial effects:
[0051] This application enables the creation of virtual VR devices for application recognition through data interaction between the client and server without affecting the server-side VR application. Furthermore, when the client sends corresponding data, that data can be used as correct input data, thus achieving the goal of cloudification.
[0052] Although the examples referenced in this application are described for illustrative purposes only and not for limiting the scope of this application, changes, additions and / or deletions to the implementation may be made without departing from the scope of this application.
[0053] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for managing virtual VR devices in cloud VR application scenarios, characterized in that, Applied to a system including a server and a client, the method includes the following steps performed by the server: The server receives a VR startup request sent by the client, which includes preset resolution and frame rate parameters; In response to the VR launch request, the server launches a virtual VR device corresponding to a VR application based on the OpenVR driver layer interface. Launching the virtual VR device includes simulating a complete virtual VR hardware, including a headset and controllers, on the server by implementing the Activate function of the ITrackedDeviceServerDriver class, so that the VR application running on the server can recognize the virtual VR device as a real physical VR device. In response to the startup of the virtual VR device, the server sets the resolution and frame rate of the rendering screen of the virtual VR driver and makes the resolution and frame rate of the rendering screen effective; specifically: according to the preset resolution parameters, the server sets the resolution of the rendering screen of the virtual VR device through the GetWindowBounds function of the IVRDisplayComponent class, and according to the preset frame rate parameters, a thread is created to calculate the rendering time, and the VsyncEvent function is called to notify the VR application of the frame rate of the rendering screen; In response to the VR application completing the rendering, the virtual VR device on the server sends the rendered image to the client, and the client receives the VR application image. The server receives the position, posture, and button data of the controllers and titles sent by the client, and then sends the received position, posture, and button data of the controllers and titles to the VR application. The server sends VR application controller vibration feedback data to the client, and the client receives the controller vibration feedback data.
2. The virtual VR device management method applied in cloud VR application scenarios as described in claim 1, characterized in that, A client is one of the following: VR devices, mobile phones, or PC mobile terminals.
3. The virtual VR device management method applied in cloud VR application scenarios as described in claim 1, characterized in that, An image texture is created based on the resolution set in the VR launch request, and the game texture rendered on the headset is copied based on the created image texture, so that the resolution of the image data output by the VR application is consistent with the resolution set by the client.
4. The virtual VR device management method applied in cloud VR application scenarios as described in claim 3, characterized in that, Based on the frame rate set in the VR startup request, the virtual VR driver creates a thread to calculate the rendering time and sets the frame rate of the rendered image accordingly.
5. A virtual VR device management system applied in cloud VR application scenarios, characterized in that, The method includes a server and a client, and the server and client interact to complete the virtual VR device management method for cloud VR application scenarios as described in any one of claims 1-4.
6. The virtual VR device management system applied in cloud VR application scenarios as described in claim 5, characterized in that, The server includes a first receiving unit, a startup unit, a setting unit, a first sending unit, a second receiving unit, and a second sending unit; The first receiving unit is used to receive VR start requests sent by the client. The startup unit is used to start the virtual VR device corresponding to the VR application based on the VR startup request; The settings unit is used to set the resolution and frame rate of the rendered image of the virtual VR driver, and to make the resolution and frame rate of the rendered image effective. The sending unit is used to send the rendered screen to the client, and the client receives the VR application screen; The second receiving unit is used to receive the position, posture, and button data of the controller and title sent by the client, and to send the received position, posture, and button data of the controller and title to the VR application. The second sending unit is used to send the VR application's controller vibration feedback data to the client, and the client receives the controller vibration feedback data.