Papers
Topics
Authors
Recent
Search
2000 character limit reached

SlideInVR: Immersive 360° Video Comparison in VR

Updated 4 July 2026
  • SlideInVR is a VR-based technique that compares two 360° immersive videos by rendering layered spherical-lune segments for simultaneous overlay and side-by-side comparison.
  • It enables dynamic control over each video’s visible angular region using extend, slide, swap, and peek operations to preserve spatial continuity and reduce cognitive load.
  • The design unifies toggle and side-by-side paradigms in immersive environments, addressing challenges of disorientation and workload while supporting detailed video analysis.

Searching arXiv for the specified papers to ground the article in current literature. Found relevant paper metadata for "To Slide or Not to Slide: Exploring Techniques for Comparing Immersive Videos" (Wang et al., 22 Feb 2026) and the broader VR presentation context paper "Planar or Spatial: Exploring Design Aspects and Challenges for Presentations in Virtual Reality with No-coding Interface" (Wu et al., 20 Oct 2025). SlideInVR is a VR-based technique for comparing two 360° immersive videos inside a headset. Rather than presenting only one full sphere at a time, it renders two spherical “lune” segments of the 360° spheres, layered in front/back, and allows dynamic reconfiguration of how much of each video is visible and where. The technique was introduced in "To Slide or Not to Slide: Exploring Techniques for Comparing Immersive Videos" as the VR instantiation of a generalized “sliding” concept intended to combine toggle and side-by-side comparison in a single interaction model for immersive video analysis (Wang et al., 22 Feb 2026).

1. Conceptual basis and design objectives

SlideInVR was designed for a problem specific to immersive videos: information is distributed across multiple directions, so comparison is cognitively demanding and strongly shaped by interaction technique. In a conventional IV player, or in ToggleInVR, the viewer is effectively inside one sphere at a time. SlideInVR instead retains the feeling of being inside an immersive sphere while making both videos simultaneously available through layered spherical regions.

Its stated design goals are to integrate toggle and side-by-side within VR, support flexible space allocation, reduce cognitive load and disorientation, preserve spatial exploration and presence, and generalize the 2D “before/after slider” idea to VR (Wang et al., 22 Feb 2026). These goals are tightly coupled. Overlay-like comparison is useful when regions of interest are aligned and the task involves subtle differences; side-by-side-like comparison is useful when regions of interest are spatially separated or when motion comparison is central. SlideInVR is intended to permit continuous movement between these regimes rather than forcing a priori commitment to one comparison paradigm.

A central motivation is geometric. A true side-by-side 360° layout in VR is not straightforward because the viewer can only occupy the center of one sphere at a time. SlideInVR addresses this by allocating different angular extents of the sphere to different videos. This preserves spatial continuity and presence while reducing the short-term memory burden associated with pure toggling, since simultaneous viewing becomes possible. The same design also lets the viewer shrink or grow the visible contribution of either video and reposition those contributions around the user.

The paper’s empirical discussion identifies a defining trade-off: SlideInVR is perceived as powerful, flexible, and often the favorite technique, but it also has a higher learning curve and workload than simpler alternatives. That tension is not incidental; it is a consequence of its attempt to unify multiple comparison strategies within one VR-native system.

2. Spherical-lune geometry and interaction model

In standard VR playback, a monoscopic 360° video is mapped to the inner surface of a sphere with the viewer at the center. SlideInVR modifies this representation by defining, for each video, a spherical-lune display area bounded by a start edge and an end edge, each a great-circle arc passing through both poles. The portion of the sphere between these edges is rendered, while the complementary region is not. The visible fraction can vary from 0 to 100%. When the edges coincide, that video covers the entire sphere; when they are separated, only an angular slice remains visible (Wang et al., 22 Feb 2026).

Two such spherical lunes are layered. One functions as the front layer and is rendered over the other wherever they overlap; the other is the back layer and appears only where the front layer does not cover. This arrangement permits continuous transitions among full overlay, partial overlay, and side-by-side distribution around the user’s field of view.

Four core interactions define the technique.

Extend adjusts the angular width of a video’s spherical-lune region by moving its start or end edge. The user grabs an edge and drags it, increasing or decreasing how much of that video is visible around the sphere. Front-layer edges are thicker and back-layer edges thinner, indicating layer order. This interaction supports dynamic allocation of spherical space to whichever video is currently more relevant.

Slide rotates a video’s lune around the polar axis, changing the azimuthal location of the slice. SlideInVR visualizes this with band-shaped selectors: a pink band above the equator for Video A and a blue band below the equator for Video B. Grabbing and dragging a band changes the lune’s angular position. To reduce motion sickness, the position update is committed on release rather than continuously during drag. Functionally, slide can align regions of interest for overlay or place them side by side within the primary field of view.

Swap exchanges which video is in the front layer and which is in the back layer. This changes which source is visually prioritized in overlapping areas and allows the comparison to be inverted without reconstructing the layout.

Peek temporarily reveals a circular window of the back-layer video inside the area currently occupied by the front layer. The window is centered where the user is looking, appears when any trigger button is pressed, and spans 15° vertically and horizontally. Peek supports local in-place inspection when the videos are roughly aligned, and it can also mimic local toggling without moving lune boundaries.

SlideInVR also provides higher-level operations through a hidden radial menu centered on the left controller. ROIs Overlay automatically slides and extends both videos until predefined regions of interest are co-located and overlapping in front of the user. ROIs SxS configures the lunes so that the two ROIs are side by side in front of the user. Reset Views returns to a default half-and-half layout with Video A as front layer. Set Views 360° extends the front-layer video to 100% of the sphere, making SlideInVR behave like ToggleInVR for viewing while retaining access to the back layer through peek and toggling. Restart Videos rewinds both videos to time 0, and Open/Close Panel toggles panel visibility. The study reports that participants heavily used ROIs SxS and ROIs Overlay to move directly into comparison mode after navigation (Wang et al., 22 Feb 2026).

A typical usage sequence begins with overlapping spherical slices in a headset. Head orientation provides natural navigation; controllers support temporal navigation, edge dragging, band dragging, radial-menu actions, and peek activation. The resulting workflow is hybrid by construction: overlay and peek are suited to fine-grained local differences, whereas side-by-side ROI placement supports coarser comparison of motion, timing, and appearance.

3. Interface, rendering, and control architecture

SlideInVR was implemented on Meta Quest 3 as a standalone system, using Unity 2022.3.16f1 and Meta XR Interaction SDK v66.0. The headset provides approximately 96° vertical FoV and 104° horizontal FoV. Input is handled with two Quest 3 controllers; tracking uses native Quest tracking for the HMD and controllers. The videos are monoscopic 360° videos in equirectangular projection, rendered with custom shaders onto the inner surface of spherical meshes (Wang et al., 22 Feb 2026).

The rendering architecture consists of two spherical-lune display areas rendered by custom shaders. Each video has its own playback instance. Temporal control is intentionally decoupled: SlideInVR supports independent temporal navigation of Video A and Video B, and playback can be synchronized or unsynchronized depending on user action. Both videos may play simultaneously, or one may be paused while the other advances.

A distinctive auxiliary visualization is the minimap, rendered above each controller as an azimuthal equidistant projection. Each minimap contains a circular representation of the 360° environment, a field-of-view indicator, an arrow labeled “F” for the front direction, and an ROI indicator with a 3D trajectory extruded over time. A 3D progress bar passes through the minimap center to show video time and is hidden when the minimap faces the user to avoid occlusion. The trajectory visualization encodes time in depth and moves with playback, while the minimap itself remains fixed to reduce motion sickness.

Temporal interaction is mapped per video: the left controller controls Video A and the right controller controls Video B. Moving a controller down toggles play/pause for that video. Holding a specific button, such as X, and moving the controller forward or backward performs continuous seeking. Thumbstick forward and backward perform 5s fast-forward/rewind. This arrangement supports workflows in which a frame in one video must be aligned with a different frame in the other, rather than assuming rigid synchronization.

Several implementation choices are explicitly motivated by comfort. During slide operations, large spherical rotations are not continuously committed, because rotating the spherical content while the head remains still can induce motion sickness. Likewise, the minimap remains fixed while its trajectory and progress indicators move along a depth axis, reducing motion discomfort. The 15°×15° peek window is described as small enough to avoid major conflicting motion cues while remaining large enough to expose local detail (Wang et al., 22 Feb 2026).

4. Position within the immersive-video comparison design space

The paper situates SlideInVR within a design space structured by two axes: approach—toggle or overlay, side-by-side or juxtaposition, and sliding as a hybrid—and modality—VR or 2D desktop. In the experimental system, five techniques were implemented: SlideInVR, ToggleInVR, SlideIn2D, ToggleIn2D, and SideBySideIn2D (Wang et al., 22 Feb 2026).

Technique Modality Core characteristic
SlideInVR VR Two simultaneous spherical lunes with extend, slide, swap, peek
ToggleInVR VR One full 360° IV at a time with toggling and local peek
SlideIn2D 2D desktop Overlay of two flat viewports with resizable top layer
ToggleIn2D 2D desktop Single shared viewport toggled between videos
SideBySideIn2D 2D desktop Two equal-sized simultaneous views

Relative to ToggleInVR, SlideInVR provides two IVs simultaneously, two minimaps, sliding and extension operations, swap, ROI macros, and peek. The advantage is flexibility: the viewer can adapt the layout to moving ROIs, differing viewpoints, and tasks requiring side-by-side inspection of temporal evolution. The paper also reports a reduction in disorientation relative to full-scene toggling, because the user can change only part of the environment rather than flipping the whole sphere. The corresponding disadvantage is complexity: participants described the technique as “overwhelming” initially, and some found it difficult to determine which layer was in front or which edges belonged to which video (Wang et al., 22 Feb 2026).

Relative to SlideIn2D, SlideInVR exchanges the flat overlay of monitor-based viewports for spherical-lune overlays in an immersive field. SlideInVR is qualitatively described as better for perceiving graphics quality and distortions, preserving spatial awareness, and maintaining presence. SlideIn2D, by contrast, is described as simpler to learn, lower in workload, and easier for users more comfortable with mouse and keyboard.

Relative to 2D-only approaches, SlideInVR offers the richest control over spatial layout and immersive fidelity, but at the cost of increased physical demand and interactional complexity. This design-space position is central to its interpretation: SlideInVR is not merely a VR translation of a 2D slider but the VR, hybrid-toggle/juxtaposition point in the authors’ taxonomy. Its purpose is to bridge superposition and juxtaposition rather than instantiate a single one.

A common misconception is to equate SlideInVR with a straightforward side-by-side VR viewer. The paper’s geometry argues against that interpretation. Its key innovation is not a static split of the 360° scene, but a layered, manipulable allocation of angular space that can approximate overlay, side-by-side, and intermediate states without abandoning immersive spherical viewing.

5. Empirical evaluation and observed user strategies

SlideInVR was evaluated in a within-subjects user study with N=20N=20 participants, all with prior VR experience. Each participant used the five comparison techniques across four task types, with one task of each type per technique, for a total of 20 tasks per participant. Dependent measures were accuracy, perceived helpfulness on a 7-point Likert scale, NASA-TLX workload on a 7-point scale, UMUX-Lite usability, and qualitative reports of strategies and workflows. Ratings were analyzed with Friedman and Wilcoxon with Holm-Bonferroni procedures, while accuracy used mixed-effects logistic regression (Wang et al., 22 Feb 2026).

On accuracy, SlideInVR had mean = 0.64, SD = 0.48, n=80n=80. The corresponding values were 0.65 for ToggleInVR, 0.75 for SlideIn2D, 0.69 for ToggleIn2D, and 0.64 for SideBySideIn2D. The logistic regression found no significant main effect of Technique with p.313p \ge .313, no significant main effect of TaskType with p.19p \ge .19, and no significant interaction with p.24p \ge .24. Thus, SlideInVR was neither quantitatively superior nor inferior in accuracy within the study.

On helpfulness, SlideInVR’s ratings were generally high and comparable to SlideIn2D and SideBySideIn2D. For [T1] temporal differences, the Friedman test yielded p=.017p = .017, indicating some overall technique differences, though no post-hoc pairwise difference survived correction. For [T2–T4], there was no significant technique effect with p.194p \ge .194. This matters because it shows that the technique’s added complexity did not translate into lower perceived utility.

On workload, Friedman tests across techniques showed significance only for physical demand, with p<0.001p < 0.001^{***}; other subscales and overall workload were not significant. Post-hoc comparisons for physical demand between SlideInVR and the 2D techniques did not remain significant after correction: p=.072p = .072 against SlideIn2D, p=.061p = .061 against ToggleIn2D, and n=80n=800 against SideBySideIn2D. Nonetheless, the paper describes SlideInVR as descriptively higher in physical demand than 2D techniques, consistent with required head and body movement and the management of multiple spatial layers and controls. Participants also described it as mentally demanding due to the number of features and the need to manage layers, although that did not reach statistical significance on the NASA-TLX mental-demand scale.

On UMUX-Lite, mean scores were 76.53 for SideBySideIn2D, 75.98 for SlideIn2D, 72.19 for ToggleInVR, 69.48 for SlideInVR, and 66.23 for ToggleIn2D. The omnibus Friedman test yielded n=80n=801, so there was no significant overall effect. Pairwise results showed significance only for SideBySideIn2D vs ToggleIn2D with n=80n=802. SlideInVR therefore was not quantitatively penalized in usability despite repeated qualitative reports of complexity.

The qualitative results are central to SlideInVR’s interpretation. Participants repeatedly described it as having “more possibility,” and as powerful and flexible. They valued the ability to grow and shrink regions, shift fluidly between overlay and side-by-side, and use ROIs Overlay and ROIs SxS as shortcuts. At the same time, many participants reported that it was overwhelming at first, citing too many buttons and interaction modes and difficulty identifying front/back layers or edge ownership.

Observed strategies were adaptive. Participants often used ROIs SxS for side-by-side ROI comparison and ROIs Overlay for fine-grained inspection. They exploited the ability to reduce the magnitude of scene changes—for example, extending only a portion of the sphere rather than toggling the whole environment—and reported that this reduced disorientation compared with ToggleInVR. Many used parallel viewing with both videos playing simultaneously for simpler tasks, but shifted to sequential or staggered playback for more demanding counting or memory-heavy tasks.

Preference data reinforced the qualitative picture. 40% of participants ranked SlideInVR 1st, and 70% placed it in the top 2. The overall Friedman test for preference yielded n=80n=803. Post-hoc comparisons showed SlideInVR vs ToggleIn2D: n=80n=804, SlideIn2D vs ToggleIn2D: n=80n=805, and SideBySideIn2D vs ToggleIn2D: n=80n=806. The technique was therefore among the most liked, even though it imposed greater learning demands (Wang et al., 22 Feb 2026).

6. Workflows, application domains, and design implications

The paper describes a characteristic SlideInVR workflow with two main phases. In the navigation phase, the user relies on minimaps and head rotations to locate ROIs, often invoking ROIs SxS or ROIs Overlay to align views automatically. In the comparison phase, strategy varies by task. For [T1] temporal occurrence, ROIs may be placed side by side while both videos play simultaneously. For [T2] motion differences, side-by-side ROI placement supports trajectory tracking, sometimes combined with sequential viewing when motion is complex. For [T3] local attribute differences, overlay plus peek supports close inspection of subtle pose, color, or shape changes. For [T4] global visual quality, users may prefer more overlay-like layouts or full-sphere front-video display through Set Views 360° (Wang et al., 22 Feb 2026).

The technique is presented as beneficial for professional IV review/editing, including comparison of multiple takes, stitching outputs, and different camera placements; for training and motion analysis, such as sports or medical training; for AI-generated IV quality evaluation, especially of distortion, stitching, and global consistency; and for educational, historical, and environmental comparisons that require both contextual side-by-side and overlay views. These examples share one property: the compared content is immersive, spatially distributed, and not necessarily aligned in a single narrow viewport.

The paper is equally explicit about less suitable scenarios. SlideInVR is not ideal for very simple, one-off comparisons where static side-by-side or toggling suffices, for users unfamiliar with VR or with minimal time, or for high-density multi-video comparison, since the current design supports only two videos and further layering would likely increase clutter and confusion.

Several design principles follow from these observations. First, VR sliding comparison should support both juxtaposition and superposition, and ROI-based operations are particularly valuable because they collapse multi-step geometric manipulation into direct task-oriented actions. Second, preserving spatial continuity and limiting the amount of environmental change can reduce disorientation and motion sickness relative to full-scene switching. Third, front/back layering must be legible through strong visual cues. Fourth, controller-attached minimaps with stable positioning can provide essential spatial-temporal guidance without adding motion discomfort. Fifth, there is a persistent need to balance power and simplicity through mechanisms such as progressive disclosure, simplified modes, or stronger context-sensitive defaults (Wang et al., 22 Feb 2026).

In a broader VR-systems context, a plausible implication is that SlideInVR’s power-versus-simplicity trade-off aligns with findings from VR presentation research, where users may still prefer planar and static formats in VR for better accessibility and efficient communication even while acknowledging the value of immersive and spatial features (Wu et al., 20 Oct 2025). For SlideInVR, this does not weaken the case for hybrid immersive comparison; rather, it clarifies that such systems benefit from onboarding, composable controls, and workflow-sensitive abstraction.

As a contribution to the literature, SlideInVR extends comparison-technique taxonomy into immersive 360° contexts by treating sliding as a hybrid of overlay and side-by-side rather than a mere UI metaphor. It also contributes to immersive analytics and HCI for IV production and evaluation by demonstrating that flexible, VR-native comparison is feasible and valued, but only under careful management of workload, spatial orientation, and interaction complexity.

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to SlideInVR.