Physical barrier real-time mapping system in large-space VR scene and VR head-mounted device

Abstract

The invention discloses a physical barrier real-time mapping system and VR head-mounted equipment in a large-space VR scene, and the system comprises a VR head-mounted equipment end which is integrated with an SLAM-based collection application and is used for scanning a target physical space to obtain spatial data; acquiring an obstacle mark point generated by user interaction on the basis of the spatial data; determining an obstacle data file based on the obstacle mark point; sending the obstacle data file to a server through a data transmission module; and the server converts the obstacle data file into an obstacle preform, and packs the preform into a standardized resource package. Physical space information is collected in real time at a VR equipment end, an obstacle data file is generated, and an obstacle is reproduced with high precision in a final VR application through a set of cloud-local collaborative resource loading mechanism, so that a protection system completely corresponding to a real environment is formed.

Description

Technical Field

[0001] This invention relates to the field of VR information processing technology, specifically to a real-time physical obstacle mapping system and a VR headset in a large-space VR scene. Background Technology

[0002] In existing virtual reality (VR) applications, especially large-scale VR experiences that require users to move freely in physical space (such as offline VR theme parks and training simulations), user safety is a core issue. When users wear head-mounted displays, their vision is completely blocked, making it impossible for them to perceive obstacles in the real environment (such as walls, pillars, furniture, etc.), which greatly increases the risk of collisions, resulting in personal injury or equipment damage.

[0003] Currently, a common solution is to pre-set fixed virtual boundaries in the virtual scene (such as Oculus's Guardian system), but this method has significant drawbacks: 1. Poor versatility: The preset virtual boundaries are fixed for specific and known site environments and cannot be adapted to physical spaces of different sizes, shapes and layouts.

[0004] 2. Insufficient flexibility: Once obstacles in the physical space change (such as tables and chairs moving), the preset virtual boundaries cannot be updated accordingly, resulting in protection failure or limiting the usable area.

[0005] 3. Low accuracy and realism: The preset boundaries are usually simple geometric shapes, which cannot accurately match the contours of complex and irregular physical obstacles, reducing the sense of immersion and making the safety protection inaccurate.

[0006] The root of these problems lies in the fact that existing technologies lack a complete solution that can quickly and accurately digitize obstacle information in any real physical space and dynamically and accurately map it into a virtual environment. Summary of the Invention

[0007] The main objective of this invention is to provide a real-time physical obstacle mapping system for large-space VR scenes, in order to address the shortcomings of related technologies.

[0008] To achieve the above objectives, according to a first aspect of the present invention, a real-time physical obstacle mapping system for large-space VR scenes is provided, comprising a VR headset terminal, integrating a SLAM-based acquisition application for scanning the target physical space to obtain spatial data; acquiring obstacle markers generated by user interaction based on the spatial data; determining an obstacle data file based on the obstacle markers; sending the obstacle data file to a server terminal through a data transmission module; the server terminal converting the obstacle data file into obstacle prefabs and packaging the prefabs into a standardized resource package; wherein, when the VR headset terminal is running, the standardized resource package is loaded and instantiated into the VR scene.

[0009] Optionally, based on spatial data, obstacle markers generated by user interaction can be obtained, including:

[0010] Optionally, when determining the obstacle data file based on obstacle location information: obtain the walking area parameters determined by the user using a preset VR controller joystick based on the obstacle location information; determine the obstacle data file based on the walking area parameters and the obstacle marker points.

[0011] Optionally, converting the obstacle data file into an obstacle prefab includes: parsing the obstacle data file, performing vertex merging and mesh optimization on the parsed data; adaptively determining the scaling ratio of the material texture based on the actual size of the obstacles in the parsed data; and determining the corresponding prefab based on the optimized mesh and the determined scaling ratio of the material texture.

[0012] Optionally, when markers are added, deleted, or their positions are modified, the prefab is dynamically updated according to the changes in the markers.

[0013] Optionally, during the process of packaging the prefab into a standardized resource package, an MD5 checksum file corresponding to the prefab version is generated simultaneously.

[0014] Optionally, when the VR headset starts up, it compares the MD5 file of the resource stored locally with the MD5 file stored on the cloud server. If the versions are inconsistent, it automatically downloads the latest version of the resource package to the local persistent path. If the versions are consistent, it directly loads the local resource package.

[0015] According to a second aspect of the present invention, a VR headset is provided, comprising: an integrated SLAM-based acquisition application for scanning a target physical space to obtain spatial data; acquiring obstacle markers generated by user interaction based on the spatial data; determining an obstacle data file based on the obstacle markers; and sending the obstacle data file to a server via a data transmission module.

[0016] This embodiment describes a real-time physical obstacle mapping system for large-space VR scenarios and a VR headset. The system includes a VR headset that integrates a SLAM-based data acquisition application to scan the target physical space and obtain spatial data. Based on the spatial data, obstacle markers generated by user interaction are acquired. An obstacle data file is determined based on these markers. The obstacle data file is then sent to a server via a data transmission module. The server converts the obstacle data file into obstacle prefabs and packages these prefabs into a standardized resource package. By acquiring physical space information in real time on the VR device, generating obstacle data files, and then using a cloud-local collaborative resource loading mechanism, the obstacles are accurately reproduced in the final VR application, forming a protection system that perfectly corresponds to the real environment. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a system structure diagram of an embodiment of the present invention; Figure 2 This is an application scenario diagram of the system in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of the invention described herein. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] According to an embodiment of the present invention, a real-time physical obstacle mapping system for large-space VR scenes is provided, with reference to... Figure 1 This includes: a VR headset that integrates a SLAM-based data acquisition application to scan the target physical space and obtain spatial data; based on the spatial data, acquiring obstacle markers generated by user interaction; determining obstacle data files based on the obstacle markers; and sending the obstacle data files to the server via a data transmission module.

[0023] In this embodiment, the device's SLAM (Simultaneous Localization and Mapping) technology is used to scan and understand the physical space, while the user confirms the positive direction of the virtual space. For example, after the application is launched, the physical space is scanned using SLAM technology to obtain spatial data including the shape, scale, and coordinate reference of the space, such as 3D point clouds, spatial boundaries and scale, and basic coordinate system; the user confirms the positive direction of the virtual space (e.g., the wall the user is facing is directly in front of the virtual space), which essentially establishes the directional correspondence between physical space coordinates and virtual space coordinates (ensuring that subsequently marked obstacles and set walking areas are completely aligned in the virtual space with the front, back, left, and right directions in reality).

[0024] As an optional implementation of this embodiment, obtaining obstacle markers generated by user interaction based on spatial data includes: obtaining markers determined by the emitted rays generated by the VR controller triggered by the user.

[0025] Users fire rays through a VR controller and click on the bottom edge of real obstacles point by point (the bottom edge is chosen to ensure consistent height of the markers and prevent the virtual wall from tilting later). When a user fires a ray through the VR controller and clicks on the bottom edge of an obstacle, the ray's landing point is converted into absolute physical coordinates (e.g., X=2.3m, Y=1.5m, Z=0.1m) by the SLAM real-time positioning module. These coordinates are calculated directly based on the base coordinate system obtained from the scan, ensuring that the position of the marker point is completely consistent with the physical position of the real obstacle edge. Combined with the ground plane parameters obtained from the scan, the Z-axis coordinate of the marker point is automatically calibrated (e.g., uniformly set to ground height + 0.1m) to ensure that all marker points are on the same horizontal reference plane (to avoid tilting of the virtual grid due to differences in user click height).

[0026] It should be understood that, instead of relying on manual user marking, the VR device's built-in depth camera or LiDAR sensor can automatically scan and identify the outlines of obstacles in physical space, automatically generating and exporting 3D mesh data. This can further improve the efficiency and automation of data collection.

[0027] As an optional implementation method in this embodiment, the marker points can be added, deleted, or their positions modified.

[0028] In this optional implementation, the user can add / remove / adjust marker points to correct marker deviations.

[0029] As an optional implementation of this embodiment, when determining the obstacle data file based on obstacle location information: obtain the walking area parameters determined by the user using a preset VR controller joystick based on the obstacle location information; determine the obstacle data file based on the walking area parameters and the obstacle location information.

[0030] In this optional implementation, in large-space VR scenes, the user's movable area is usually pre-designed and fixed, and its shape or size cannot be arbitrarily changed. When virtual projects are deployed to different physical spaces (e.g., venue A has pillars, venue B is rectangular), the fixed virtual walking area may cover real-world obstacles (e.g., the virtual area includes the pillars of venue A), causing users to collide with real-world pillars when moving within the virtual area in the physical space. Therefore, this contradiction is resolved by adjusting the parameters of the virtual walking area. Without changing the shape / size of the virtual area itself, the user's posture in the virtual-real coordinate system is adjusted to allow it to avoid real-world obstacles while preserving as much of the virtual area's usable range as possible.

[0031] Furthermore, these parameters include three core parameters: position offset parameters (X-axis translation, Y-axis translation (Z-axis height in some scenarios)), which adjust the position of the virtual walking area in the horizontal direction to avoid point obstacles; rotation angle parameters (rotation angle around the Y-axis (0°-360°)), which adjust the orientation of the virtual walking area to adapt to the shape of the physical space or long strip obstacles; and height alignment parameters (vertical offset (Z-axis compensation)), which adapt to the height difference of the physical ground (such as slight slopes or steps) to avoid misalignment between the virtual area and the physical ground.

[0032] When adjusting parameters, the virtual walking area moves / rotates in real time following the parameter changes, allowing users to intuitively observe whether the virtual area avoids obstacles without blind adjustments. All parameter adjustments are based on 3D physical space coordinates generated by SLAM technology: the position, rotation, and height parameters of the virtual walking area are all bound to absolute coordinates in physical space (e.g., a 1-meter translation along the X-axis corresponds to a 1-meter movement to the right in physical space), ensuring that after adjustment, every point in the virtual area accurately matches the safe area in physical space, avoiding misalignment between the virtual and real worlds. The virtual walking area is based on Unity's NavMesh. NavMesh first generates a walkable area in the virtual world through baking (excluding virtual obstacles), and parameter adjustments further adapt this virtual walkable area to real-world physical obstacles, essentially adding a physical space adaptation filter to NavMesh, ultimately generating a walkable range that conforms to virtual logic and is safe in reality.

[0033] Based on all marker points and walking area data (such as coordinates, rotation, and offset), a binary file (RedMesh.txt) is generated according to the data structure required by the user. The binary file can be stored locally on the device.

[0034] The system also includes a server that converts obstacle data files into obstacle prefabs and packages the prefabs into a standardized resource package; wherein, when the VR headset is running, the standardized resource package is loaded and instantiated into the VR scene.

[0035] In this embodiment, the object being parsed is an obstacle data file (such as RedMesh.txt, in binary format). The parsed data is discrete and unoptimized, including core obstacle data, complete parameters of the walking area, and non-core but necessary auxiliary information, which is used to ensure data integrity, version consistency, and process traceability.

[0036] Extracting the core obstacle data is the fundamental basis for constructing the virtual obstacle outline, including a set of obstacle vertex coordinates: the absolute 3D physical space coordinates (X=xx.m, Y=xx.m, Z=xx.m) of each obstacle marker point, based on a unified coordinate system established by SLAM scanning (aligned to the physical space at the millimeter level); containing all valid marker points (the final data after removing invalid points, with no duplicates / isolated points). The marker point coordinates are generated through VR controller raycasting + SLAM positioning, stored serially in the data file, and need to be restored to a point list format after parsing (e.g., one vertex array for each obstacle). This serves as the raw data for vertex merging and mesh optimization, used to fit the obstacle outline.

[0037] This also includes vertex topology data: clearly identifying which vertices belong to the same obstacle (grouping information, e.g., vertices 1-5 belong to wall A, vertices 6-10 belong to pillar B), the ordering of vertices within the same obstacle (clockwise / counterclockwise, ensuring the correct direction of contour closure), and the association logic of vertices (e.g., which vertices form a plane). The data file stores the vertex grouping identifiers (to avoid confusion between different obstacle contours), and this association relationship must be restored after parsing. This prevents multiple obstacle contours from becoming disordered, ensuring that mesh optimization is performed independently for each obstacle.

[0038] All parameters related to the walking area are set, corresponding to the position, rotation, offset, and other information previously adjusted by the user, to ensure that the virtual walking area can accurately adapt to obstacles in the future. Walking area parameters: Preset core dimensions of the virtual walking area (e.g., 6m×6m square, 5m×4m rectangle), shape type identifier (square / rectangle / irregular polygon, based on application preset). The data file stores the preset framework information, which is parsed and restored to structured data of size and shape. This ensures that the core area of ​​the virtual walking area remains unchanged, only adjusting its posture to adapt to obstacles.

[0039] It also includes posture adjustment parameters for the walking area: the final posture parameters adjusted by the user via the controller joystick, including: position offset parameters (X-axis / Y-axis translation, such as X+1m, Y-0.5m, based on the SLAM coordinate system); rotation angle parameters (rotation angle around the Y-axis, such as 45°, adapting to the physical space shape); and vertical offset parameters (Z-axis height compensation, such as +0.1m, adapting to ground height differences). The data file stores the adjusted final parameters, not the initial preset values, ensuring that they can be directly used for scene instantiation after parsing. This allows for precise positioning of the virtual walking area in the VR scene, avoiding obstacles.

[0040] Relative relationship data between the walking area and obstacles: minimum safe distance between the virtual walking area and each obstacle (e.g., 0.3m from wall A and 0.5m from column B), and whether there are overlap warning signs (if there is still overlap after adjustment, the warning sign will be stored in the file, and after parsing, a manual second adjustment will be prompted). This verifies the safety of the walking area to avoid the risk of virtual-to-real collisions in the generated prefabricated structures.

[0041] Auxiliary information: Data file version number, MD5 checksum (corresponding to the version verification code synchronized to the cloud later), and data generation timestamp (e.g., 2024-XX-XX XX:XX:XX). Version and verification information are automatically appended when the data file is generated to prevent corruption during data transmission / storage. The MD5 hash is compared with the cloud AssetBundle to ensure that the loaded resource is a matching version.

[0042] As an optional implementation of this embodiment, converting the obstacle data file into an obstacle prefab includes: parsing the obstacle data file, performing vertex merging and mesh optimization on the parsed data; adaptively determining the scaling ratio of the material texture based on the actual size of the obstacles in the parsed data; and determining the corresponding prefab based on the optimized mesh and the determined material texture scaling ratio.

[0043] The parsed data may contain duplicate vertices or very close vertices (for example, a user may accidentally click the same location twice, or two adjacent points may be only 0.01m apart). The system automatically identifies vertices in the parsed data whose coordinates overlap or whose distance is less than a threshold (e.g., 0.001m), merges them into one vertex, and preserves the contour relationship corresponding to that vertex.

[0044] The original vertices after parsing are discrete points. To form the three-dimensional shape of the virtual obstacle, these points need to be connected into triangles (the basic unit of 3D model rendering). However, direct connection will generate a large number of small and redundant triangles (for example, 5 points directly connected may generate 6 triangles, some of which are too small to be of any practical rendering significance). Based on the merged vertices, the system recalculates the connection method of the triangular faces, that is, it removes redundant triangular faces with an area smaller than the threshold and merges adjacent coplanar triangular faces, ultimately forming a mesh with a small number of faces, a regular structure, and the ability to accurately restore the outline of obstacles. Combined with the actual size of the obstacles in the parsed data (calculated from the original vertex coordinates, such as the length of the wall being 3m and the height being 2.8m), the scaling ratio of the material texture is adaptively adjusted (for example, the texture is made to fit the 3m long wall to avoid texture stretching or repetition).

[0045] The parsed data is transformed from a set of coordinates that can only record position into efficient data suitable for VR engine (such as Unity) rendering and collision detection—reducing the number of vertices and triangles, reducing DrawCalls, alleviating GPU computing pressure, and ensuring that virtual obstacles are displayed smoothly in real time in VR scenes and that collision warnings are accurate.

[0046] When determining the prefab, collider components are automatically added based on the optimized mesh. The shape of the collider is completely consistent with the optimized mesh, ensuring that a collision warning is triggered when the user approaches in VR. During visual rendering, corresponding materials (such as red mesh texture) are added based on the actual size of the obstacles in the parsed data (this information has been retained during optimization) to ensure that the visual effect matches the real-world obstacles. The above mesh, collider, and material are packaged into a prefab, which can be repeatedly loaded and instantiated by VR applications (e.g., multiple scenes sharing the same obstacle model).

[0047] As an optional implementation of this embodiment, when markers are added, deleted, or their positions are modified, the prefab is dynamically updated according to the changes in the markers.

[0048] Based on the adjusted marker points, prefabricated structures, such as a red grid (red net), are dynamically generated. The red net changes synchronously with the marker points, transforming discrete marker points into continuous, visual virtual obstacle outlines. This allows users to intuitively see the positional relationship and occlusion relationship between real-world obstacles and the virtual red net (e.g., whether the red net completely fits the wall or misses any pillar edges), ensuring the accuracy of the virtual mapping. The original point data of the obstacle markers provides a clear obstacle boundary reference for setting the walking area. The red net is equivalent to a virtual obstacle entity, allowing users to clearly know which areas are obstacles and need to be avoided when subsequently setting their walking area.

[0049] For example, the system can generate green marker points (visually displaying the marked points) and red preview surfaces in real time. For instance, when a user clicks on the bottom edge of a real wall with a controller ray, the system calculates the physical spatial coordinates of that point, then overlays a green marker point at the same location on the edge of the real wall; and then, based on the coordinates of multiple marker points, stitches together a red preview wall surface that matches the wall outline.

[0050] Using the physical spatial coordinates of marker points as the core reference, a dynamic, red virtual mesh is generated through the steps of 'data preprocessing → contour fitting → mesh filling → real-time linkage'. Essentially, this transforms discrete marker points into continuous, visualized safety protection boundaries, relying entirely on the positional information and spatial reference of the marker points. When generating the virtual mesh based on marker points, the following method can be used (this is merely an example; other methods can be employed): During generation, the system first performs preprocessing of the marker point data. This involves initial processing of the raw marker point data generated by the user to avoid redundant or erroneous data affecting the accuracy of the redo log. The processing logic relies entirely on the original information of the marker points: invalid points are removed, duplicate points (where coordinates completely overlap) and abnormal points (such as isolated points far from other marker points, which are likely due to user errors); the point sequence is smoothed and regularized by sorting the marker points of the same obstacle clockwise / counterclockwise (e.g., walls from the top left corner → top right corner → bottom right corner → bottom left corner) to ensure the continuity of subsequent contour fitting; and critical missing points are filled in. If the spacing between marker points is too large (e.g., exceeding 0.5m), the system automatically inserts interpolation points (based on the straight / curved trend of adjacent points) to avoid breaks or irregular depressions in the redo log.

[0051] Based on the marker points, the core of Rednet is to restore the true outline of the obstacle. This step is entirely based on the pre-processed marker points and generates the outline through multi-point closure logic: For straight obstacles (such as walls and square pillars), the sorted marker points are directly connected end to end to form a polygonal outline (e.g., 4 marker points → rectangular outline); For curved obstacles (such as circular pillars and curved walls), curves (such as Bézier curves and arcs) are fitted by the marker points and then closed to form a smooth outline (e.g., 8 marker points → approximately circular outline); For multi-layer / three-dimensional obstacles (such as high platforms and low cabinets), if the marker points contain height information (different Z-axis coordinates), multi-layer outlines are generated based on marker points of different heights, and then the outlines of each layer are connected to form a three-dimensional frame (Rednet will cover the sides and top critical protective surfaces of the obstacle).

[0052] Furthermore, based on the closed contour, a red mesh is generated. The density and shape of the mesh are designed for clear visualization and efficient rendering, and depend on the size information of the contour: the size of the mesh unit is determined and adaptively adjusted according to the size of the obstacle (e.g., a wall length of 3m → mesh unit of 0.3m × 0.3m, a column diameter of 1m → mesh unit of 0.2m × 0.2m), which ensures that the contour details are not lost and avoids excessive GPU pressure due to overly dense mesh; mesh lines are generated by drawing parallel mesh lines (horizontal + vertical) along the length × height direction of the contour to form a regular quadrilateral mesh (or a triangular mesh, to adapt to complex contours); the red mesh attributes are bound, and the mesh color is set to high-alert red, the line width is 0.5-1px (to ensure clear visibility in VR), and the transparency is 60%-80% (to avoid completely obscuring real-world obstacles and not affect the virtual and real observation in MR mode).

[0053] Furthermore, Rednet's core advantage lies in its dynamic adaptation to changes in marker points. The logic behind this step is that marker points are the cause, and Rednet is the effect, entirely dependent on the real-time status of the marker points. When adding a new marker, the system automatically incorporates the new marker into the outline of the corresponding obstacle, refits the outline, and updates the mesh (e.g., adding one marker to a wall → the outline changes from a rectangle to a pentagon, and the red mesh is reconstructed simultaneously). When deleting or moving markers, the remaining markers are preprocessed again → the outline is reclosed → the mesh is refilled (e.g., removing one corner point of a wall → the outline becomes a triangle, and the red mesh is shrunk and adapted simultaneously). After the red mesh is generated, it is superimposed on the corresponding position of the real obstacle in the MR view in real time. Users can intuitively see the spatial overlap relationship between the real obstacle and the red mesh. If the red mesh is found to be off-center, it can be corrected by adjusting the markers.

[0054] Finally, the collision detection logic is bound together. The rednet is not only a visual element, but also a safety protection boundary. This step requires adding colliders based on the rednet's grid data, relying on the spatial coordinates of the grid: add a collider component (such as Mesh Collider) to each grid cell of the rednet, and the position and shape of the collider are completely consistent with the rednet; when the user approaches the rednet in VR (distance threshold such as 0.3m), the system triggers a collision warning (such as rednet flashing, controller vibration), realizing the dual function of visual reminder + safety protection.

[0055] As an optional implementation of this embodiment, during the process of packaging the prefab into a standardized resource package, an MD5 checksum file corresponding to the prefab version is generated simultaneously.

[0056] As an optional implementation in this embodiment, when the VR headset starts up, it compares the MD5 file of the resource stored locally with the MD5 file stored on the cloud server. If the versions are inconsistent, it automatically downloads the latest version of the resource package to the local persistent path. If the versions are consistent, it directly loads the local resource package.

[0057] In this optional implementation, the standardized resource package is in AssetBundle format, and an MD5 checksum file corresponding to the resource version is generated synchronously during the packaging process.

[0058] When a VR application starts, it compares the MD5 file of the resource stored locally with the MD5 file stored on the cloud server. If the versions are inconsistent, it automatically downloads the latest version of the resource package to the local persistent path. If the versions are consistent, it loads the local resource package directly.

[0059] It should be understood that obstacle data can also be synchronized to the cloud and parsed locally in a pure data format (such as JSON or binary) instead of being packaged as an AssetBundle. The client can then dynamically generate meshes and materials based on the data, which allows for finer-grained updates and smaller download sizes.

[0060] This embodiment uses a dedicated map scanning and annotation application (APK) to collect physical space information in real time on the VR device, generate obstacle data files, and then uses a cloud-local collaborative resource loading mechanism to reproduce the obstacles with high precision in the final VR application, forming a red net protection system that completely corresponds to the real environment.

[0061] According to an embodiment of the present invention, a VR headset is also provided, characterized in that it includes: an integrated SLAM-based acquisition application for scanning the target physical space to obtain spatial data; based on the spatial data, acquiring obstacle markers generated by user interaction; determining an obstacle data file based on the obstacle markers; and sending the obstacle data file to a server through a data transmission module.

[0062] It also includes: a VR controller that is separately configured from the VR headset, used to determine a marker point based on the direction of the ray after the ray emission operation is triggered.

[0063] It also includes: a VR controller joystick that is separate from the VR headset, and walking area parameters determined based on obstacle location information after the VR controller joystick is triggered for adjustment.

[0064] Data acquisition module (corresponding file XrOpen.cs): This module runs on VR headsets such as Pico4U and is a standalone application.

[0065] In this embodiment, the SLAM-based acquisition application can be a SLAM scanning module to acquire 3D environmental information of the target physical space; a MR display module to visualize the physical space and virtual marker elements, and to lock the positive direction of the virtual space upon receiving user commands; a controller interaction module to respond to the user's ray-marking operation, generating obstacle markers and a preview wall, and simultaneously acquiring adjustment parameters for the virtual walking area; the application processes the 3D environmental information, obstacle marker data, and virtual walking area adjustment parameters to generate a binary obstacle data file containing obstacle vertex data, walking area coordinates, and attitude parameters, which is stored in the data storage module; the wireless communication module transmits the obstacle data file to the development end, or receives resource version verification information from the cloud server.

[0066] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A real-time physical obstacle mapping system for large-space VR scenes, characterized in that, include: The VR headset integrates a SLAM-based data acquisition application to scan the target physical space and obtain spatial data. Based on spatial data, obtain obstacle markers generated by user interaction; Obstacle data files are determined based on obstacle markers; the obstacle data files are then sent to the server via a data transmission module. On the server side, the obstacle data file is converted into obstacle prefabs, and the prefabs are packaged into a standardized resource package; When the VR headset is running, the standardized resource package is loaded and instantiated into the VR scene.

2. The real-time physical obstacle mapping system in a large-space VR scene according to claim 1, characterized in that, Based on spatial data, the obstacle markers generated by user interaction are obtained, including: Obtain the marker point determined by the emitted ray generated by the VR controller triggered by the user.

3. The real-time physical obstacle mapping system in a large-space VR scene according to claim 2, characterized in that, When determining the obstacle data file: Obtain the walking area parameters determined by the user using a preset VR controller joystick based on obstacle location information; The obstacle data file is determined based on the walking area parameters and the obstacle markers.

4. The real-time physical obstacle mapping system in a large-space VR scene according to claim 1, characterized in that, Converting the obstacle data file into an obstacle prefab includes: The obstacle data file is parsed, and vertex merging and mesh optimization are performed on the parsed data; and the scaling ratio of the material texture is adaptively determined based on the actual size of the obstacles in the parsed data. The corresponding prefab is determined based on the optimized mesh and the determined material texture scaling ratio.

5. The real-time physical obstacle mapping system in a large-space VR scene according to claim 4, characterized in that, When markers are added, deleted, or their positions are modified, the prefabricated body is dynamically updated according to the changes in the markers.

6. The real-time physical obstacle mapping system in a large-space VR scene according to claim 1, characterized in that, During the process of packaging the prefab into a standardized resource package, an MD5 checksum file corresponding to the prefab version is generated simultaneously.

7. The real-time physical obstacle mapping system in a large-space VR scene according to claim 6, characterized in that, When the VR headset starts up, it compares the MD5 file of the resource stored locally with the MD5 file stored on the cloud server. If the versions are inconsistent, it automatically downloads the latest version of the resource package to the local persistent path. If the versions are consistent, it loads the local resource package directly.

8. A VR headset, characterized in that, include: It integrates a SLAM-based data acquisition application for scanning the target physical space to obtain spatial data; Based on spatial data, obtain obstacle markers generated by user interaction; Determine obstacle data files based on obstacle marker points; The obstacle data file is sent to the server via the data transmission module.

9. The VR headset according to claim 8, characterized in that, Also includes: The VR controller, which is separate from the VR headset, is used to determine a marker point based on the direction of the ray after the ray emission operation is triggered.

10. The VR headset according to claim 9, characterized in that, Also includes: The VR controller joystick, which is separate from the VR headset, determines the walking area parameters based on obstacle location information after the VR controller joystick is triggered for adjustment.

Images