Multi-screen interactive real estate display method based on cave and LED

Abstract

The invention discloses a multi-screen interaction real estate display method based on a cave and an LED, and belongs to the technical field of vehicle-mounted electronics, and the method comprises the steps that a user interactively generates an operation item at a Pad end, analyzes a request, generates a rendering instruction, renders display content through Babylon.js, counts frame time and delay, judges whether a synchronization difference value between screens exceeds a threshold or not, and executes an adjustment strategy. The technical problems of synchronous control and space consistency rendering of multiple independent view angle LED screens in multi-frame rendering are solved, a three-view angle independent rendering mechanism among the multiple screens is achieved, stable and synchronous multi-screen content is ensured, a real-time Pad control and state response mechanism is supported, and the method and the device have the advantages of being simple in structure, convenient to operate and high in practicability. Smooth user operation and visual feedback are improved, and a modular system architecture is convenient to deploy and expand and adapts to various display environments and resolution specifications.

Description

Technical Field

[0001] The present invention belongs to the field of vehicle-mounted electronic technology, and in particular relates to a multi-screen interactive real estate display method based on caves and LEDs. Background Art

[0002] With the growing demand for multimedia displays, immersive experiences, and digital real estate presentations, multi-screen interactive display systems are becoming increasingly commonplace. In particular, in scenarios like real estate presentations, industrial sandboxes, and museum interactions, immersive visualization methods that combine 3D rendering with multi-screen interaction are becoming a crucial means of enhancing user interaction and spatial perception.

[0003] The CAVE (Cave Automatic Virtual Environment) system is a way to build an immersive virtual environment that can present three-dimensional information through multiple screens.

[0004] Currently, mainstream multi-screen display solutions rely primarily on single-viewpoint replication or simple split-screen image projection. While these solutions can achieve basic multi-screen expansion, they generally suffer from the following technical bottlenecks:

[0005] Traditional split-screen methods often use homologous mirror rendering, resulting in the same content displayed on multiple screens, lacking a sense of spatial three-dimensionality, and unable to restore the user's real experience of observing scenes from multiple perspectives in space.

[0006] During the multi-screen rendering process, due to factors such as network fluctuations, GPU scheduling and computing load, frame delay differences are very likely to occur between different screens, causing screen tearing or frame skipping, affecting viewing smoothness.

[0007] When users operate through a tablet or console, the existing system has intermediate delays in request distribution and perspective response, which cannot support real-time control and feedback requirements and reduces the operating experience. Summary of the Invention

[0008] The purpose of the present invention is to provide a multi-screen interactive real estate display method based on cave and LED, which solves the technical problems of synchronous control and spatial consistency rendering of multiple independent viewing angle LED screens in multi-frame rendering.

[0009] To achieve the above object, the present invention adopts the following technical solutions:

[0010] A multi-screen interactive real estate display method based on caves and LEDs includes the following steps:

[0011] Step 1: The user selects a view or operation item through the control interface on the Pad side. The Pad side generates an operation request, encapsulates the operation request, and sends it to the backend service system.

[0012] The operation item includes the operation type and the corresponding operation parameters;

[0013] The Pad establishes a connection with the backend service system through WebSocket and conducts real-time communication;

[0014] Step 2: The backend service system continuously monitors the WebSocket connection, receives and parses the operation request sent by the Pad in real time, and generates rendering instructions based on the classification results of the parsed operation items;

[0015] Step 3: The backend service system calls the Babylon.js rendering engine and executes the corresponding graphics update logic according to the operation type of the operation item in the rendering instruction;

[0016] The backend service system initializes the basic viewing angle and calculates the camera rotation angle corresponding to each screen based on the fixed spatial arrangement of the three screens;

[0017] The Babylon.js rendering engine binds rendering tasks to three camera perspectives;

[0018] Step 4: The Babylon.js rendering engine performs split-screen rendering. The backend service system continuously receives and monitors the frame time and rendering delay of each screen, and counts the current frame rendering status of each screen;

[0019] Step 5: The backend service system determines in real time whether there is a frame delay difference between the three screens, and calculates the difference Δt between the frame delay of each screen and the average delay;

[0020] Compare the difference Δt with multiple preset delay thresholds, divide the synchronization adjustment window, and calculate the corresponding number of aligned frames or frame drop amplitude;

[0021] Step 6: The Babylon.js rendering engine generates the current frame image content in real time according to the viewing angle of each screen. The rendered display content is pushed to the corresponding screen through the backend service system and displayed.

[0022] Preferably, the operation request is specifically user operation behavior data generated by the Pad end after the user performs an interactive operation through the Web control interface of the Pad end, and different behaviors correspond to different operation items;

[0023] The operation items in the operation request include switching apartment models, rotating angles, starting animations, and zooming in and out.

[0024] Preferably, the backend service system continuously monitors WebSocket connections through the Node.js service, maintains the connection session on the Pad side and monitors message events;

[0025] The backend service system records the current system execution status in real time and generates a current status log;

[0026] The backend service system parses the operation items and classifies them into categories:

[0027] The operation item is to switch the apartment model, which triggers the loading of the new model and replaces the scene;

[0028] The operation item is the rotation angle, which triggers the camera perspective transformation;

[0029] The operation item is animation start, which triggers the execution of the predefined animation;

[0030] The operation item is zoom in and out, which triggers the execution to adjust the field of view;

[0031] The backend service system generates different rendering engine instructions based on the analysis results of the operation items.

[0032] Preferably, when executing step 3, the following steps are specifically included:

[0033] Step 3-1: The backend service system calls the Babylon.js rendering engine. The Babylon.js rendering engine initializes the rendering scene based on the current status log and sets the initial position and direction of the main camera based on the current model and basic perspective in the rendering scene. Specifically, the basic camera position P is initialized. base :

[0034]

[0035] Step 3-2: According to the spatial physical arrangement of the three screens, set the offset angles respectively, from left to right: θ1, θ2, θ3;

[0036] Step 3-3: Calculate the camera position P for each screen rendering according to the following formula i :

[0037] Rotation matrix:

[0038]

[0039] P i =R y (θ i )·P base ;

[0040] Among them, R y (θ) is the rotation matrix of the vector around the y-axis, θ is the offset angle; i represents the screen number, the default left screen is 1, the middle screen is 2, and the right screen is 3; θ i represents the offset angle of the i-th screen;

[0041] Step 3-4: Each screen is bound to a corresponding independent camera object, and its viewing angle parameters are written into the Babylon.js rendering engine; the viewing angle parameters include the camera's position and rotation angle.

[0042] Preferably, when executing step 4, the following steps are specifically included:

[0043] Step 4-1: The Babylon.js rendering engine renders the current frame image according to the offset angle of the camera on each screen;

[0044] Step 4-2: After each rendering is completed, record the start and end timestamps and calculate the rendering time of the current frame:

[0045] T i frame=T i end-T i start;

[0046] Among them, T i frame represents the rendering time of the i-th screen, T i end indicates the rendering end time of the i-th screen, T i Start indicates the rendering start time of the i-th screen;

[0047] Step 4-3: After the rendering frame is generated, the image result is pushed to the corresponding screen via WebSocket in real time;

[0048] Step 4-4: Monitor and collect the rendering time of each screen.

[0049] Preferably, when executing step 5, the following steps are specifically included:

[0050] Step 5-1: Calculate the average Tavg of the rendering time of the current frame on the three screens:

[0051] Tavg=(T1frame+T2frame+T3frame) / 3;

[0052] Step 5-2: Calculate the difference Δt between the frame delay of each screen and the average delay:

[0053] Δt=T i frame-Tavg;

[0054] Step 5-3: Classify and judge the frame synchronization status of the three screens: If the difference Δt of the three screens is less than 12ms, the current synchronization is considered normal and the synchronization adjustment state is not entered; if the delay of any screen is greater than 20ms, the synchronization adjustment state is entered;

[0055] Step 5-4: Enter the synchronous adjustment state, specifically setting three threshold windows and performing window comparison:

[0056] w1:12ms≤|Δt|<20ms→ΔN=5;

[0057] w2:20ms≤|Δt|<33ms→ΔN=10;

[0058] w3:|Δt|≥33ms→ΔN=15;

[0059] Among them, w1, w2, and w3 represent the window levels set in 3 respectively, and ΔN represents the number of adjusted frames.

[0060] Preferably, when executing step 6, a preset adjustment strategy is executed based on the difference Δt of each screen calculated in step 5, thereby achieving frame-level synchronization during multi-screen presentation.

[0061] Preferably, the preset adjustment strategy includes:

[0062] Strategy 1: Establish and maintain a short-term frame buffer in the sending queue of each screen, delay push to the screen that triggers the w1 window level according to Δt, and pre-render and cache the screen that triggers the w3 window level in advance;

[0063] Strategy 2: The backend service system obtains the ACK messages for the previous frame N from all screens and determines whether to push the next frame N+1 based on the ACK messages. The push of the next frame N+1 is triggered only after all screens have completed displaying frame N.

[0064] Strategy 3: After receiving an image frame, each screen displays the content and returns a confirmation message (ACK) to the backend service system through WebSocket. The ACK message contains the screen number and frame number. The backend service system controls the synchronization rhythm based on the ACK message.

[0065] Strategy 4: When any screen responds with an ack message within the preset delay, the backend service system resends the current frame N or skips the current frame N, directly pushes the next frame N+1, and resets the cache queue.

[0066] The cave- and LED-based multi-screen interactive real estate display method described in this invention solves the technical problems of synchronous control and spatially consistent rendering of multiple independent-viewpoint LED screens in multi-frame rendering. This method implements a three-perspective independent rendering mechanism across multiple screens, creating a spatially realistic immersive visual effect. It also constructs a dynamic frame synchronization adjustment model based on a delay threshold to ensure stable synchronization of multi-screen content. It supports real-time pad control and status response mechanisms, improving smooth user operation and visual feedback. The modular system architecture facilitates deployment and expansion, adapting to a variety of display environments and resolution specifications. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Figure 1 It is the main flow chart of the present invention;

[0068] Figure 2 It is a schematic diagram of the system architecture of the present invention;

[0069] Figure 3 is a flow chart of step 3 of the present invention;

[0070] Figure 4 is a flow chart of step 4 of the present invention;

[0071] Figure 5 It is a flow chart of step 5 of the present invention. DETAILED DESCRIPTION

[0072] like Figure 1-Figure 5 The multi-screen interactive real estate display method based on cave and LED includes the following steps:

[0073] Step 1: The user selects a view or operation item through the control interface on the Pad side. The Pad side generates an operation request, encapsulates the operation request, and sends it to the backend service system.

[0074] The operation item includes the operation type and the corresponding operation parameters;

[0075] The Pad establishes a connection with the backend service system through WebSocket and conducts real-time communication;

[0076] The operation request is specifically user operation behavior data generated by the Pad end after the user performs an interactive operation through the Web control interface of the Pad end, and different behaviors correspond to different operation items;

[0077] The operation items in the operation request include switching apartment models, rotating angles, starting animations, and zooming in and out.

[0078] In this embodiment, the user's operation behaviors on the Pad side (such as clicking a button, selecting an apartment type) are converted into structured operation requests in real time.

[0079] An operation request contains at least fields such as the operation type (e.g., switching models, adjusting perspectives), parameter values, etc. These operation requests are transmitted to the backend service system via the WebSocket protocol, enabling low-latency, two-way communication.

[0080] For example, if a user clicks the "Change Apartment Type" button on a Pad and selects Apartment Type B, the fields in the operation request are as follows:

[0081] user_id="U123", timestamp="2025-05-08T14:32:21Z", operation="switch_model", parameters:{"model_id"="B}.

[0082] Step 2: The backend service system continuously monitors the WebSocket connection, receives and parses the operation request sent by the Pad in real time, and generates rendering instructions based on the classification results of the parsed operation items;

[0083] The backend service system continuously monitors WebSocket connections through the Node.js service, maintains the connection session on the Pad side and monitors message events;

[0084] The backend service system records the current system execution status in real time and generates a current status log;

[0085] The backend service system parses the operation items and classifies them into categories:

[0086] The operation item is to switch the apartment model, which triggers the loading of the new model and replaces the scene;

[0087] The operation item is the rotation angle, which triggers the camera perspective transformation;

[0088] The operation item is animation start, which triggers the execution of the predefined animation;

[0089] The operation item is zoom in and out, which triggers the execution to adjust the field of view;

[0090] The backend service system generates different rendering engine instructions based on the analysis results of the operation items.

[0091] In this embodiment, the backend service system may adopt an event-driven architecture (such as Node.js) to monitor WebSocket connections.

[0092] Whenever the backend service system receives a new operation request, it triggers the parsing and classification module to perform semantic analysis and mapping of the operation items, generating rendering instructions executable by Babylon.js (such as updating the model and changing the perspective). At the same time, the backend service system records the processing log of each request to support subsequent debugging and backtracking.

[0093] Step 3: The backend service system calls the Babylon.js rendering engine and executes the corresponding graphics update logic according to the operation type of the operation item in the rendering instruction;

[0094] The backend service system initializes the basic viewing angle and calculates the camera rotation angle corresponding to each screen based on the fixed spatial arrangement of the three screens;

[0095] The Babylon.js rendering engine binds rendering tasks to three camera perspectives;

[0096] When executing step 3, the specific steps include:

[0097] Step 3-1: The backend service system calls the Babylon.js rendering engine. The Babylon.js rendering engine initializes the rendering scene based on the current status log and sets the initial position and direction of the main camera based on the current model and basic perspective in the rendering scene. Specifically, the basic camera position P is initialized. base :

[0098]

[0099] In this embodiment, the basic camera position is that the center screen faces the center point of the scene, the position is set to (0, y, z), and the direction is set to the positive Z axis.

[0100] Step 3-2: According to the spatial physical arrangement of the three screens, set the offset angles respectively, from left to right: θ1, θ2, θ3;

[0101] Step 3-3: Calculate the camera position P for each screen rendering according to the following formula i :

[0102] Rotation matrix:

[0103]

[0104] P i =R y (θ i )·P base ;

[0105] Among them, R y (θ) is the rotation matrix of the vector around the y-axis, θ is the offset angle; i represents the screen number, the default left screen is 1, the middle screen is 2, and the right screen is 3; θ i Indicates the offset angle of the i-th screen. In this embodiment, the default θ i The values ​​can be θ1 = -30°, θ2 = 0°, and θ3 = +30°. The specific values ​​can also be set according to the installation position of the screen, and can also be calculated according to the following formula: offset angle = screen spacing / user viewing distance × scale factor.

[0106] Step 3-4: Each screen is bound to a corresponding independent camera object, and its viewing angle parameters are written into the Babylon.js rendering engine; the viewing angle parameters include the camera's position and rotation angle.

[0107] Step 4: The Babylon.js rendering engine performs split-screen rendering. The backend service system continuously receives and monitors the frame time and rendering delay of each screen, and counts the current frame rendering status of each screen;

[0108] When executing step 4, the specific steps include:

[0109] Step 4-1: The Babylon.js rendering engine renders the current frame image according to the offset angle of the camera on each screen;

[0110] Step 4-2: After each rendering is completed, record the start and end timestamps and calculate the rendering time of the current frame:

[0111] T i frame=T i end-T i start;

[0112] Among them, T i frame represents the rendering time of the i-th screen, T i end indicates the rendering end time of the i-th screen, T i Start indicates the rendering start time of the i-th screen;

[0113] Step 4-3: After the rendering frame is generated, the image result is pushed to the corresponding screen via WebSocket in real time;

[0114] Step 4-4: Monitor and collect the rendering time of each screen.

[0115] In this embodiment, the Babylon.js engine renders the three images separately. Each time a frame is rendered, the start and end time of the current frame is recorded, and the image is packaged and sent to the corresponding screen via WebSocket.

[0116] The backend service system also needs to monitor feedback from all screens simultaneously, count and update the rendering time of each screen for subsequent delay evaluation and synchronization control.

[0117] Step 5: The backend service system determines in real time whether there is a frame delay difference between the three screens, and calculates the difference Δt between the frame delay of each screen and the average delay;

[0118] Compare the difference Δt with multiple preset delay thresholds, divide the synchronization adjustment window, and calculate the corresponding number of aligned frames or frame drop amplitude;

[0119] When executing step 5, the specific steps include:

[0120] Step 5-1: Calculate the average Tavg of the rendering time of the current frame on the three screens:

[0121] Tavg=(T1frame+T2frame+T3frame) / 3;

[0122] Step 5-2: Calculate the difference Δt between the frame delay of each screen and the average delay:

[0123] Δt=T i frame-Tavg;

[0124] Step 5-3: Classify and judge the frame synchronization status of the three screens: If the difference Δt of the three screens is less than 12ms, the current synchronization is considered normal and the synchronization adjustment state is not entered; if the delay of any screen is greater than 20ms, the synchronization adjustment state is entered;

[0125] Step 5-4: Enter the synchronous adjustment state, specifically setting three threshold windows and performing window comparison:

[0126] w1:12ms≤|Δt|<20ms→ΔN=5;

[0127] w2:20ms≤|Δt|<33ms→ΔN=10;

[0128] w3:|Δt|≥33ms→ΔN=15;

[0129] Among them, w1, w2, and w3 represent the window levels set in 3 respectively, and ΔN represents the number of adjusted frames.

[0130] Step 6: The Babylon.js rendering engine generates the current frame image content in real time according to the viewing angle of each screen. The rendered display content is pushed to the corresponding screen through the backend service system and displayed.

[0131] In this embodiment, the Babylon.js rendering engine generates corresponding image content according to the viewing angle offset configuration of each screen in each frame period. The specific operations are as follows:

[0132] First, an independent virtual camera is configured for each screen. The viewing angle parameters of the virtual camera are set according to the calculated offset angle to ensure that the image rendered by each screen maintains the angle difference and conforms to the overall spatial layout.

[0133] In each frame rendering cycle, the rendering engine performs perspective rendering on the scene based on each virtual camera and generates the current frame image in real time.

[0134] Then, after the image is generated, the image content is packaged into a data stream in a specified format (such as a Base64-encoded image frame) and the current frame number (such as frame_id) is attached. This number remains consistent across all screens and is used as a synchronization reference.

[0135] The rendering results are then sent to the corresponding screen via WebSocket through the backend service system.

[0136] In this embodiment, in order to ensure the frame-level synchronization of multi-screen display, the basic

[0137] The frame time offset of each screen calculated in step 5 is combined with the current frame number to execute a preset adjustment strategy. The preset adjustment strategy that can be used in this embodiment includes the following:

[0138] Strategy 1: Establish and maintain a short-term frame buffer in the sending queue of each screen, delay push to the screen that triggers the w1 window level according to Δt, and pre-render and cache the screen that triggers the w3 window level in advance;

[0139] Strategy 2: The backend service system obtains the ACK messages for the previous frame N from all screens and determines whether to push the next frame N+1 based on the ACK messages. The push of the next frame N+1 is triggered only after all screens have completed displaying frame N.

[0140] Strategy 3: After receiving an image frame, each screen displays the content and returns a confirmation message (ACK) to the backend service system through WebSocket. The ACK message contains the screen number and frame number. The backend service system controls the synchronization rhythm based on the ACK message.

[0141] Strategy 4: When any screen feeds back an ack message within the preset delay, the backend service system resends the current frame N or skips the current frame N, directly pushes the next frame N+1, and resets the cache queue. In this embodiment, the preset delay can be set to 3 consecutive frames.

[0142] The cave- and LED-based multi-screen interactive real estate display method described in this invention solves the technical problems of synchronous control and spatially consistent rendering of multiple independent-viewpoint LED screens in multi-frame rendering. This method implements a three-perspective independent rendering mechanism across multiple screens, creating a spatially realistic immersive visual effect. It also constructs a dynamic frame synchronization adjustment model based on a delay threshold to ensure stable synchronization of multi-screen content. It supports real-time pad control and status response mechanisms, improving smooth user operation and visual feedback. The modular system architecture facilitates deployment and expansion, adapting to a variety of display environments and resolution specifications.

Claims

1. A multi-screen interactive real estate display method based on cave and LED, characterized by: The steps include: Step 1: The user selects a view or operation item through the control interface on the Pad side. The Pad side generates an operation request, encapsulates the operation request, and sends it to the backend service system. The operation item includes the operation type and the corresponding operation parameters; The Pad establishes a connection with the backend service system through WebSocket and conducts real-time communication; Step 2: The backend service system continuously monitors the WebSocket connection, receives and parses the operation request sent by the Pad in real time, and generates rendering instructions based on the classification results of the parsed operation items; Step 3: The backend service system calls the Babylon.js rendering engine and executes the corresponding graphics update logic according to the operation type of the operation item in the rendering instruction; The backend service system initializes the basic viewing angle and calculates the camera rotation angle corresponding to each screen based on the fixed spatial arrangement of the three screens; The Babylon.js rendering engine binds rendering tasks to three camera perspectives; Step 4: The Babylon.js rendering engine performs split-screen rendering. The backend service system continuously receives and monitors the frame time and rendering delay of each screen, and counts the current frame rendering status of each screen; Step 5: The backend service system determines in real time whether there is a frame delay difference between the three screens, and calculates the difference Δt between the frame delay of each screen and the average delay; Compare the difference Δt with multiple preset delay thresholds, divide the synchronization adjustment window, and calculate the corresponding number of aligned frames or frame drop amplitude; Step 6: The Babylon.js rendering engine generates the current frame image in real time based on the viewing angle offset of each screen and the difference Δt obtained in step 5, the window level described by the difference Δt, and the preset synchronization strategy. The previous frame image is pushed to the corresponding screen through the backend service system and displayed.

2. The multi-screen interactive real estate display method based on caves and LEDs according to claim 1, characterized in that: The operation request is specifically user operation behavior data generated by the Pad end after the user performs an interactive operation through the Web control interface of the Pad end, and different behaviors correspond to different operation items; The operation items in the operation request include switching apartment models, rotating angles, starting animations, and zooming in and out.

3. The multi-screen interactive real estate display method based on cave and LED according to claim 2, characterized in that: The backend service system continuously monitors WebSocket connections through the Node.js service, maintains the connection session on the Pad side and monitors message events; The backend service system records the current system execution status in real time and generates a current status log; The backend service system parses the operation items and classifies them into categories: The operation item is to switch the apartment model, which triggers the loading of the new model and replaces the scene; The operation item is the rotation angle, which triggers the camera perspective transformation; The operation item is animation start, which triggers the execution of the predefined animation; The operation item is zoom in and out, which triggers the execution to adjust the field of view; The backend service system generates different rendering engine instructions based on the analysis results of the operation items.

4. The multi-screen interactive real estate display method based on caves and LEDs according to claim 3, characterized in that: When executing step 3, the specific steps include: Step 3-1: The backend service system calls the Babylon.js rendering engine. The Babylon.js rendering engine initializes the rendering scene based on the current status log and sets the initial position and direction of the main camera based on the current model and basic perspective in the rendering scene. Specifically, the basic camera position P is initialized. base : Step 3-2: According to the spatial physical arrangement of the three screens, set the offset angles respectively, from left to right: θ1, θ2, θ3; Step 3-3: Calculate the camera position P for each screen rendering according to the following formula i : Rotation matrix: P.S i ZR y (θ i )·P base 100. Among them, R y (θ) is the rotation matrix of the vector around the y-axis, θ is the offset angle; i represents the screen number, the default left screen is 1, the middle screen is 2, and the right screen is 3; θ i represents the offset angle of the i-th screen; Step 3-4: Each screen is bound to a corresponding independent camera object, and its viewing angle parameters are written into the Babylon.js rendering engine; the viewing angle parameters include the camera's position and rotation angle.

5. The multi-screen interactive real estate display method based on cave and LED according to claim 1, characterized in that: When executing step 4, the specific steps include: Step 4-1: The Babylon.js rendering engine renders the current frame image according to the offset angle of the camera on each screen; Step 4-2: After each rendering is completed, record the start and end timestamps and calculate the rendering time of the current frame: T i frame=T i end-T i start; Among them, T i frame represents the rendering time of the i-th screen, T i end indicates the rendering end time of the i-th screen, T i Start indicates the rendering start time of the i-th screen; Step 4-3: After the rendering frame is generated, the image result is pushed to the corresponding screen via WebSocket in real time; Step 4-4: Monitor and collect the rendering time of each screen.

6. The multi-screen interactive real estate display method based on cave and LED according to claim 5, characterized in that: When executing step 5, the specific steps include: Step 5-1: Calculate the average Tavg of the rendering time of the current frame on the three screens: Tavg=(T1frame+T2frame+T3frame) / 3; Step 5-2: Calculate the difference Δt between the frame delay of each screen and the average delay: Δt=T i frame-Tavg; Step 5-3: Classify and judge the frame synchronization status of the three screens: If the difference Δt of the three screens is less than 12ms, the current synchronization is considered normal and the synchronization adjustment state is not entered; if the delay of any screen is greater than 20ms, the synchronization adjustment state is entered; Step 5-4: Enter the synchronous adjustment state, specifically setting three threshold windows and performing window comparison: w1:12ms≤|Δt|<20ms→ΔN=5; w2:20ms≤|Δt|<33ms→ΔN=10; w3:|Δt|≥33ms→ΔN=15; Wherein, w1, w2, and w3 represent the window levels set in 3 respectively, and ΔN represents the number of adjusted frames.

7. The multi-screen interactive real estate display method based on caves and LEDs according to claim 6, characterized in that: When executing step 6, based on the difference Δt of each screen obtained in step 5 and the window level to which the difference Δt belongs, a preset adjustment strategy is executed to achieve frame-level synchronization during multi-screen presentation. The preset adjustment strategy includes: Strategy 1: Establish and maintain a short-term frame buffer in the sending queue of each screen, delay push to the screen that triggers the w1 window level according to Δt, and pre-render and cache the screens that trigger the w2 and w3 window levels in advance; Strategy 2: The backend service system obtains the ACK messages for the previous frame N from all screens and determines whether to push the next frame N+1 based on the ACK messages. The push of the next frame N+1 is triggered only after all screens have completed displaying frame N. Strategy 3: After receiving an image frame, each screen displays the content and returns a confirmation message (ACK) to the backend service system through WebSocket. The ACK message contains the screen number and frame number. The backend service system controls the synchronization rhythm based on the ACK message. Strategy 4: When any screen responds with an ack message within the preset delay, the backend service system resends the current frame N or skips the current frame N, directly pushes the next frame N+1, and resets the cache queue.

Images