HCVR Scene Generation: High Compatibility Virtual Reality Environment Generation for Extended Redirected Walking

TL;DR

HCVR introduces ENI++ to quantify physical–virtual space compatibility and uses LLM-guided asset selection combined with OOB checking and ENI++ directed modifications to generate VR scenes that are inherently RDW-friendly. By aligning virtual layouts to maximize RDW-feasible regions, HCVR achieves markedly fewer collisions (e.g., 22.78x fewer) and lower ENI++ scores (35.89% less) while delivering higher user satisfaction (12.5%) compared to LLM-based generation. The approach integrates boundary-aware geometry analysis, room segmentation, and iterative object adjustment to produce scalable, navigable VR environments suitable for large scenes within constrained physical spaces. This work advances practical VR immersion by enabling collision-free natural walking through RDW-optimized scene design, with potential applications in therapy, training, and gaming where physical space limitations are common.

Abstract

Natural walking enhances immersion in virtual environments (VEs), but physical space limitations and obstacles hinder exploration, especially in large virtual scenes. Redirected Walking (RDW) techniques mitigate this by subtly manipulating the virtual camera to guide users away from physical collisions within pre-defined VEs. However, RDW efficacy diminishes significantly when substantial geometric divergence exists between the physical and virtual environments, leading to unavoidable collisions. Existing scene generation methods primarily focus on object relationships or layout aesthetics, often neglecting the crucial aspect of physical compatibility required for effective RDW. To address this, we introduce HCVR (High Compatibility Virtual Reality Environment Generation), a novel framework that generates virtual scenes inherently optimized for alignment-based RDW controllers. HCVR first employs ENI++, a novel, boundary-sensitive metric to evaluate the incompatibility between physical and virtual spaces by comparing rotation-sensitive visibility polygons. Guided by the ENI++ compatibility map and user prompts, HCVR utilizes a Large Language Model (LLM) for context-aware 3D asset retrieval and initial layout generation. The framework then strategically adjusts object selection, scaling, and placement to maximize coverage of virtually incompatible regions, effectively guiding users towards RDW-feasible paths. User studies evaluating physical collisions and layout quality demonstrate HCVR's effectiveness with HCVR-generated scenes, resulting in 22.78 times fewer physical collisions and received 35.89\% less on ENI++ score compared to LLM-based generation with RDW, while also receiving 12.5\% higher scores on user feedback to layout design.

Figures (10)

• Figure 1: HCVR Architecture: A physical environment with obstacles $P_{env}$ and a virtual space with a floor plan $V_{env}$ is able to use ENI++ metric to process a score map. We use BUDAS gan2021many to identify the rooms in the virtual floor plan. The objects for each room, their spatial relationships between each others, and the room will thus be generated. The compatibility information for each room processes along with the LLM prompt in the initial layout generation. Sampled points are displayed across the scene plot, with colors transitioning from yellow to purple to represent ENI++ scores—yellow denoting high values and purple indicating low ones. Out-Of-Boundary (OOB) checker thus keep all objects in the initial layout inside each room without any overlaps. Lastly, we retrieve the score map to re-modify the objects locations within their spatial constraints so that all of them can cover as much incompatible area as possible. HCVR thus finally left the compatible and redirected friendly area available for user to explore.
• Figure 2: The blue bounded area indicates a calculated visibility polygon from point $v_p$ and the red bounded area represents one from $p_p$. The $overlay$ area of both visibility polygons is constrained and not allowed the user to walk into the current direction due to the front obstacle in $P_{env}$. However, this problem can be solved if the user is being redirected and walking with a certain degree of rotation. The $overlay + rotation$ clearly enlarged the overlapped area and allows a larger accessible area for users.
• Figure 3: This figure illustrates the differences between ENI and ENI++ in the resulting plots with an identical virtual and physical scene pair. The virtual environment $V_{env}$ is defined as a 20×20 square, while $P_{env}$, is a 20x25 rectangular area. The zoomed in patched shows the difference between ENI and ENI++ due to the implementation of boundary-sensitive and rotation-sensitive visibility polygons comparison.
• Figure 4: This figure shows different ENI++ score map being plot on the same $V_{env}$ while given distinct $P_{env}$. The ENI++ score was plotted as colors ranges from purple to yellow (low to high). It is obvious to see how it varies. The first scene is shows high compatibility. The second pair shows the lowest ENI++ score as the marked area at the left while the third ENI++ plot shows the lowest score in the middle area.
• Figure 5: Demo LLM prompt for object suggestion which uses capacity score as minimum number of items of a room. Function and size description of each room can impact the LLM output on items and number of items (complete prompt details are in supplementary materials).