Stereoscopic display device and rendering synchronization method for multi-node stereoscopic display

CN122933876APending Publication Date: 2026-10-16谢朝阳
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611198451.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-08-07
Publication Date
2026-10-16

AI Technical Summary

Technical Problem

而渲染控制器的数量随显示屏数量增长,网络接口的成本、射频布局的复杂度以及印制板面积随之成倍增加

Benefits of technology

[0030] In the above technical solution, the rendering controller can allocate more resources to complex model details, physical simulation or anti-aliasing within a limited computing power budget, thus avoiding stuttering caused by insufficient computing power.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122933876A_ABST
    Figure CN122933876A_ABST
Patent Text Reader

Abstract

The application relates to a kind of stereoscopic display device and the rendering synchronization method of multi-node stereoscopic display.Main controller is periodically outputted to each rendering controller through synchronization signal line and broadcasts frame synchronization message carrying frame serial number through first unidirectional data bus without return every cycle.Each rendering controller counts the edge of the selected communication signal, receives the message with the frame serial number and the current count anchor;When the time limit exceeds the preset from the latest message and the selected communication signal is still normal, the local frame serial number is set as the anchor frame serial number and the sum of the edge number accumulated since anchoring, and the message is recovered and re-anchored.The local frame serial number in the rendering controller of the application will also be locked or automatically corrected by physical count increment when each selected communication edge arrives, thereby significantly suppressing the frame number jump or misplacement caused by the difference in message receiving time or software processing delay of each node, so that the whole system outputs the same frame serial number picture at the same physical time.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of stereoscopic display, and more particularly, to a stereoscopic display device and a method for synchronizing rendering of multi-node stereoscopic displays. Background Technology

[0002] Stereoscopic display devices achieve their imaging effect by using several beam-splitters arranged in a cone, with multiple displays providing images from different directions, thus creating a stereoscopic image that can be viewed while moving around the cone. This device typically requires a main controller for network access, voice interaction, and overall scheduling, as well as several rendering controllers, each driving its own displays and handling 3D rendering. Existing display devices often use bidirectional buses or local area networks to connect the main controller and the rendering controllers. Therefore, each rendering controller must have a corresponding transceiver or network interface. As the number of rendering controllers increases with the number of displays, the cost of network interfaces, the complexity of RF layout, and the printed circuit board area increase exponentially. Summary of the Invention

[0003] In view of this, the present invention provides a stereoscopic display device and a rendering synchronization method for multi-node stereoscopic display.

[0004] The objective of this invention is achieved through the following technical solution: A stereoscopic display device includes a reflector, N display screens, M rendering controllers, and a main controller. The reflector includes N beam splitters, which are correspondingly arranged with respect to the N display screens. Each rendering controller drives a plurality of the display screens. N is an integer not less than 3, and M is an integer greater than 1 and not greater than N. The main controller is connected to each of the rendering controllers via: A synchronization signal line is used to transmit periodic synchronization strobe signals to each of the rendering controllers; A first unidirectional data bus is used to broadcast first data to each of the rendering controllers; There are M independent state lines. One end of each state line is connected to the main controller, and the other end is connected to a corresponding rendering controller. The rendering controllers connected to different state lines are different from each other.

[0005] The above technical solution employs a three-type signal line topology: "one synchronization signal line + one unidirectional data bus + M independent status lines." This significantly reduces wiring complexity and hardware costs while achieving multi-node synchronous control. The design of the first unidirectional data bus with no return path simplifies the bus protocol and hardware interface, avoiding the arbitration mechanism and conflict handling logic required for bidirectional communication. Furthermore, each rendering controller lacks a network interface, with network access only through the main controller. As the number of displays increases, this greatly reduces network interface costs, RF layout area, and the number of printed circuit board layers.

[0006] M independent state lines allow each rendering controller to report its own status to the master controller. However, frame sequence numbers, animation state indexes, or image data are not transmitted on the state lines. This provides the master controller with the necessary node status awareness without disrupting the unidirectional broadcast architecture. Simultaneously, the synchronization signal line is separated from the data bus, ensuring that the synchronization strobe signal is unaffected by data packet transmission delays and guaranteeing the hardware-level determinism of edge counting.

[0007] The synchronization signal line is set independently of the first unidirectional data bus. The synchronization beat is not affected by the traffic on the data bus. Multiple rendering controllers are triggered by the same edge on the same line, allowing each display to present the image belonging to the same moment at the same time. This structure makes the distribution of beats and the distribution of data physically independent: even if the message on the unidirectional data bus is interrupted, the strobe signal on the synchronization signal line will still be output as usual, and the beats received by each rendering controller will not be changed as a result.

[0008] Alternatively, in one possible implementation, when M=N, each rendering controller drives one display screen; when M is even and M=1 / 2N, each rendering controller drives two display screens.

[0009] In the above technical solution, when M=N, each rendering controller drives only one display screen, which can realize the complete exclusive use of single-channel rendering resources. The screen output of each corresponding light splitter can obtain independent computing power support, completely avoiding the frame rate drop and screen latency problems caused by multi-screen sharing of rendering resources.

[0010] When M=1 / 2N, each rendering controller can drive two displays simultaneously. Without sacrificing the overall image synchronization accuracy, the number of rendering controllers can be halved, significantly reducing the overall hardware cost of the system, while also reducing the rack space and cabling occupied by the controllers.

[0011] Optionally, in one possible implementation, a second unidirectional data bus is further connected between the main controller and each of the rendering controllers, the second unidirectional data bus being used to broadcast second data to each of the rendering controllers.

[0012] In the above technical solution, a second unidirectional data bus is set up specifically for broadcasting second data, such as 3D model data, so that the distribution of model data is separated from the transmission of frame synchronization signaling, and they do not interfere with each other. After the 3D model data is transmitted through an independent channel, each rendering controller can complete the model replacement locally, and the main controller does not need to download rasterization data frame by frame, which greatly reduces the communication bandwidth pressure on the main controller.

[0013] A rendering synchronization method for multi-node stereoscopic display is applied to a stereoscopic display device. The device includes a main controller and M rendering controllers. The main controller outputs a periodic gating signal to each of the rendering controllers via a synchronization signal line and broadcasts a frame synchronization message via a first unidirectional data bus. There is no return path on the first unidirectional data bus. The main controller outputs periodic synchronization strobe signals to the M rendering controllers via the synchronization signal line, and broadcasts frame synchronization messages carrying frame sequence numbers to the M rendering controllers via the first unidirectional data bus; the frame sequence number of the frame synchronization message and the strobe period of the synchronization strobe signal increase sequentially, and the two correspond one-to-one. Each of the aforementioned rendering controllers performs the following steps: S1. Accumulate and count the specified edges of the synchronous gating signal, with a count increment of one in each gating cycle; S2. When the frame synchronization message is received, the local frame sequence number is set to the frame sequence number carried by the frame synchronization message, and the current edge cumulative count is recorded as the anchor value and the current time is the time of the most recent message. S3. When each specified edge arrives, determine whether the difference between the current time and the latest message time exceeds a preset time limit; if it does not exceed the time limit, keep the local frame sequence number unchanged; if it exceeds the time limit, update the local frame sequence number to the sum of the sequence number of the most recently received frame and the current edge cumulative count minus the anchor value. S4. Export the animation clock using the local frame number, and render the screen based on the animation clock.

[0014] In the above technical solution, the gating signal output by the main controller through the synchronization signal line has physical periodicity, and the frame sequence number carried by the frame synchronization message increases sequentially and corresponds one-to-one with it. When each rendering controller receives a frame synchronization message, it locks the frame sequence number of the message with the current physical edge count value (anchor value). Thereafter, regardless of whether the message is interrupted, the local frame sequence number in each rendering controller will remain locked or automatically corrected according to the physical count increment when the edge of each gating cycle arrives. This significantly suppresses frame number jumps or misalignments caused by differences in message reception time or software processing delays at each node, enabling the entire system to output images with the same frame sequence number at the same physical moment.

[0015] Optionally, in one possible implementation, the preset time limit in step S3 is K gating cycles, where K is any integer from 2 to 5.

[0016] In the above technical solution, the preset time limit is limited to 2 to 5 gating cycles, which provides a reasonable engineering tolerance range: if it is less than 2 cycles, the guard mechanism may be accidentally triggered due to normal message transmission jitter; if it is more than 5 cycles, the message interruption time is too long, and unacceptable frame sequence number deviations may accumulate between nodes.

[0017] Optionally, in one possible implementation, each rendering controller periodically sends a ready signal back to the main controller via a corresponding independent state line; the main controller only enables the display screen to display when the ready signals of all the rendering controllers meet a preset condition.

[0018] In the above technical solution, each rendering controller periodically sends back a ready signal through an independent status line, enabling the main controller to monitor the operating status of each node in real time. The main controller only enables screen display when all registered rendering controllers are in a ready state, avoiding abnormal situations such as screen tearing, black screens on some displays, or displaying outdated images when some nodes are not ready.

[0019] Optionally, in one possible implementation, each of the rendering controllers rasterizes the same frame in parallel using two processor cores, dividing the frame into two non-overlapping strips according to the scan lines, and processing each strip by one of the processor cores; each of the rendering controllers records the actual rasterization time of each of the two processor cores in the previous frame, and adjusts the scan line where the strip boundary of the next frame is located based on the difference between the two.

[0020] In the aforementioned technical solutions, in traditional parallel rendering with fixed boundaries (such as half-segmented scan lines), if the upper half of the image is a complex scene and the lower half is a simple background, the processor core responsible for the upper half will be severely overloaded, while the other core will become idle prematurely, and the overall frame rate will be limited by the slower core. Therefore, this invention records the actual rasterization time of the two cores in the previous frame and uses the difference between them as feedback to adjust the boundary position of the next frame, forming a closed-loop negative feedback control system. After several frames of iterative convergence, the boundary line will automatically migrate to a scan line position where the time consumed by the two cores tends to be equal, achieving the theoretical minimum frame rendering time and significantly improving rendering throughput.

[0021] Optionally, in one possible implementation, each rendering controller counts the minimum and maximum values ​​of the depth value within the screen space of each frame, and linearly maps the depth value of the frame to a fixed-point integer as the key of the depth buffer, while retaining a code value that is not in the mapped value range as a screen clearing sentinel; when counting the extreme values, vertices located outside the screen are removed.

[0022] In the above technical solution, the minimum and maximum values ​​of the depth values ​​in the current screen space are counted frame by frame. Based on this, a linear mapping is performed to generate a fixed-point integer depth key. This abandons the traditional global fixed depth range mapping method, which allows the effective depth value of the current frame to completely cover the entire value range of the fixed-point integer. This greatly improves the depth accuracy of the depth buffer and reduces the depth conflict problem caused by the depth values ​​of near and far objects being too close from the root.

[0023] Optionally, in one possible implementation, the main controller further broadcasts the identifier of the animation state set to the M rendering controllers via a second unidirectional data bus, at which point each rendering controller performs the following steps: S2.1. Based on the identifier of the animation state set and the attribute flags of the locally stored 3D model, determine a set containing multiple discrete animation states; S2.2 Derive the time value from the local frame sequence number and calculate the interval index to which the time value belongs; S2.3. Using at least the interval index as input, select a state index from the animation state set using the same deterministic function as the other rendering controllers; S2.4. According to the animation state corresponding to the selected state index, and using the camera azimuth angle corresponding to this rendering controller, render the same 3D model and output it to the display screen it drives.

[0024] In the above technical solution, the main controller broadcasts the identifier of the animation state set only through the second unidirectional data bus. There is no need to send massive amounts of animation frame data to each rendering controller separately. The unified scheduling of the global animation state can be completed with only a very small number of broadcast data packets, which greatly reduces the data transmission bandwidth pressure between the main controller and multiple rendering nodes. Even if the M value increases with the number of displays, there will be no problem of data transmission load increasing exponentially.

[0025] Optionally, in one possible implementation, the deterministic function is a salted hash function, wherein the salt value is derived from the identifier of the animation state set and the attribute flag of the 3D model; the step of selecting the state index further includes: if the state index obtained by the current interval index is the same as the state index obtained by the previous interval index, then the state index obtained by the current interval index is shifted one position in the animation state set.

[0026] In the above technical solution, the salt value is derived from both the behavior category and the model attribute flag, ensuring that different behavior categories or different models are hashed to different positions in their respective sets under the same interval index, thus avoiding crosstalk between action libraries. If the current interval index is the same as the state index calculated from the previous interval index, it is automatically shifted one position, avoiding visual monotony caused by selecting the same animation state in two adjacent intervals.

[0027] Optionally, in one possible implementation, the 3D model does not rotate during the rendering process, and the camera azimuth angle corresponding to each rendering controller is a fixed value independent of time; and each rendering controller determines its corresponding camera azimuth angle by its locally stored node identifier.

[0028] In the above technical solution, the stereoscopic image is provided by multiple displays from different directions, and then combined into a three-dimensional image after being reflected by a beam splitter. To achieve correct stereoscopic imaging, each display must present a view of the same three-dimensional model in the same posture but viewed from different angles, rather than the model itself rotating, thus avoiding distortion or misalignment caused by the model's rotation.

[0029] Alternatively, in one possible implementation, each of the rendering controllers renders at an internal resolution lower than the display resolution, and then the hardware scaling unit scales it up to the display resolution in a non-blocking manner.

[0030] In the above technical solution, the rendering controller can allocate more resources to complex model details, physical simulation or anti-aliasing within a limited computing power budget, thus avoiding stuttering caused by insufficient computing power. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is one of the schematic diagrams of a stereoscopic display device according to an embodiment of the present invention.

[0033] Figure 2 This is a second schematic diagram of a stereoscopic display device according to an embodiment of the present invention.

[0034] Figure 3 This is a timing diagram of a frame number incrementing mechanism according to an embodiment of the present invention.

[0035] Figure 4 This is a flowchart illustrating the selection of animation states according to an embodiment of the present invention.

[0036] Reference numerals: 1 - Main controller; 2 - Rendering controller; 3 - Display screen; 4 - Beam splitter; 5 - Reflector; 6 - Synchronization signal line; 7 - First unidirectional data bus; 8 - Second unidirectional data bus; 9 - Status line; 10 - Non-volatile memory unit; 11 - Network interface; 12 - Microphone; 13 - Speaker. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0038] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0039] Please refer to Figure 1 and Figure 2 This embodiment provides a stereoscopic display device, including a reflector 5, N displays 3, M rendering controllers 2, and a main controller 1. The reflector 5 includes N beam splitters 4, which are correspondingly arranged with the N displays 3. Each rendering controller 2 drives several displays 3. N is an integer not less than 3, and M is an integer greater than 1 and not greater than N. The main controller 1 is connected to each rendering controller 2 via: A synchronization signal line 6 is used to transmit periodic synchronization strobe signals to each rendering controller 2; A first unidirectional data bus 7 is used to broadcast first data to each rendering controller 2; There are M independent state lines 9. One end of each state line 9 is connected to the main controller 1, and the other end is connected to a corresponding rendering controller 2. The rendering controllers 2 connected to different state lines 9 are different.

[0040] Employing a three-type signal line topology of "one synchronization signal line 6 + one unidirectional data bus + M independent status lines 9," multi-node synchronous control is achieved while significantly reducing wiring complexity and hardware costs. The design of the first unidirectional data bus 7, with no return path, simplifies the bus protocol and hardware interface, avoiding the arbitration mechanism and conflict handling logic required for bidirectional communication. Furthermore, each rendering controller 2 does not have a network interface 11; instead, the main controller 1 connects to the network. As the number of displays 3 increases, this significantly reduces the cost of network interfaces 11, RF layout area, and the number of printed circuit board layers.

[0041] M independent state lines 9 enable each rendering controller 2 to report its own status to the main controller 1. However, frame sequence numbers, animation status indexes, or image data are not transmitted on state lines 9, thus providing the main controller 1 with the necessary node status awareness capabilities without disrupting the unidirectional broadcast architecture. At the same time, the synchronization signal line 6 is separated from the data bus, so that the synchronization strobe signal is not affected by data packet transmission delay, ensuring the hardware-level determinism of edge counting.

[0042] The synchronization signal line 6 is set independently of the first unidirectional data bus 7. The synchronization beat is not affected by the traffic on the data bus. Multiple rendering controllers 2 are triggered by the same edge on the same line, and each display screen 3 can display the image belonging to the same moment at the same time. This structure makes the distribution of beats and the distribution of data physically independent of each other: even if the message on the first unidirectional data bus 7 is interrupted, the strobe signal on the synchronization signal line 6 will still be output normally, and the beats received by each rendering controller 2 will not be changed as a result.

[0043] Specifically, the reflector 5 is enclosed by four triangular beam-splitters 4 forming a cone structure, with each beam-splitter 4 forming a 45-degree angle with the plane of the corresponding display screen 3. The four display screens 3 can be placed below each of the four beam-splitters 4, corresponding one-to-one.

[0044] like Figure 1 As shown, when M=N, each rendering controller 2 drives one display screen 3; that is, the four rendering controllers 2 drive the four display screens 3 respectively. Each rendering controller 2 drives only one display screen 3, which can realize the complete exclusive use of single-channel rendering resources. The screen output of each corresponding light splitter 4 can obtain independent computing power support, completely avoiding the frame rate drop and screen latency problems caused by multi-screen sharing of rendering resources.

[0045] like Figure 2As shown, in another implementation, when M is an even number and M=1 / 2N, that is, M=2 and N=4, each rendering controller 2 can drive two displays 3 at the same time. Without losing the overall screen synchronization accuracy, the number of hardware components of the rendering controller 2 is halved, which greatly reduces the overall hardware cost of the system and reduces the rack space and total cabling occupied by the controller.

[0046] It should be noted that the main controller 1 is equipped with a network interface 11, a memory card interface, and is connected to a microphone 12 and a speaker 13; none of the four rendering controllers 2 are equipped with a network interface 11. A general-purpose input / output pin of the main controller 1 is connected to the input pins of the four rendering controllers 2 via a synchronization signal line 6, and a periodic strobe signal is output on the synchronization signal line 6. A serial transmit pin of the main controller 1 is connected to the serial receive pins of the four rendering controllers 2 via a first unidirectional data bus 7, for broadcasting first data, such as a frame synchronization message carrying a frame sequence number in this embodiment.

[0047] All rendering controllers 2 do not require separate network interface configurations, significantly reducing the hardware cost of the multi-screen stereoscopic display system. This also avoids risks such as IP conflicts and network storms caused by multiple network ports simultaneously accessing the network, simplifying the overall system network topology. Secondly, the main controller 1 directly connects to the microphone 12 and speaker 13, enabling centralized acquisition, processing, and synchronous output of audio signals. Furthermore, the main controller can directly connect to external storage media via a memory card interface, allowing for local storage of large-volume 3D materials and multi-view rendering configuration files for multi-screen stereoscopic displays without relying on a network.

[0048] In addition, four status lines 9 are led one by one from the four pins of the main controller 1 to the four rendering controllers 2, and the four lines are not connected to each other. The four status lines 9 fall on the four pins of the main controller 1; each rendering controller 2 is provided with a non-volatile memory unit 10, which stores the node identifier of the rendering controller 2. Each rendering controller 2 determines its corresponding azimuth angle based on the node identifier, and the four azimuth angles are 90 degrees apart. Each rendering controller 2's non-volatile memory unit 10 independently stores its own node identifier. After the device is powered on, the main controller 1 does not need to reassign IDs one by one, and the device identification can be quickly completed, which greatly shortens the system startup initialization time and improves the power-on response efficiency of the stereoscopic display device.

[0049] The non-volatile storage unit 10 has two switchable storage partitions to retain rollbackable original content during upgrades. Specifically, the two switchable storage partitions enable a dual-zone redundancy design of "running partition + backup partition". If the program or configuration data in one partition is corrupted, it can quickly switch to the other partition to start running, avoiding the rendering controller crashing due to a single storage zone failure, thereby significantly improving the operational reliability of the stereoscopic display system.

[0050] In this embodiment, a second unidirectional data bus 8 is also connected between the main controller 1 and each rendering controller 2. The second unidirectional data bus 8 is used to broadcast second data to each rendering controller 2. A set of serial interface pins of the main controller 1 is connected to the four rendering controllers 2 via the second unidirectional data bus 8 for broadcasting the second data, such as three-dimensional model data in this embodiment.

[0051] It should be noted that the receiving and transmission ends of the first unidirectional data bus 7 and the second unidirectional data bus 8 are not connected.

[0052] A second unidirectional data bus 8 is set up specifically for broadcasting secondary data, such as 3D model data, so that the distribution of model data is separated from the transmission of frame synchronization signaling, and they do not interfere with each other. After the 3D model data is transmitted through an independent channel, each rendering controller 2 can complete the model replacement locally, and the main controller 1 does not need to download rasterization data frame by frame, which greatly reduces the communication bandwidth pressure on the main controller 1.

[0053] Please refer to Figure 3 The electrical parameters in this embodiment can be specifically selected as follows. The strobe signal frequency on the synchronization signal line 6 is 18 Hz, with a period of approximately 55.6 milliseconds. The first unidirectional data bus 7 is a unidirectional asynchronous serial bus with a baud rate of 115200, 8 data bits, no parity bit, 1 stop bit, and no return connection; the frame synchronization message transmitted on it is a fixed-length 8-byte message, consisting of a two-byte start flag, a one-byte opcode, four bytes of parameters, and a one-byte checksum. The second unidirectional data bus 8 is a unidirectional synchronous serial bus with a clock frequency of 2 MHz, connected only to the clock line, data output line, and chip select line; the receive return pin is not connected; the 3D model data transmitted on it is a fixed-length frame, each frame being 4128 bytes, consisting of a 32-byte frame header and a 4096-byte payload, which becomes 4160 bytes after direct memory access alignment. Status line 9 is a single-wire open-drain structure connected to the power supply via a pull-up resistor. It is high when idle, with a baud rate of 2400. Each byte consists of a start bit, 8 data bits (least significant bit first), an even parity bit, and a stop bit. The high 4 bits of the byte represent the firmware version, and the low 4 bits represent the ready status. The heartbeat period is 40 milliseconds, and the freshness determination window of the main controller 1 is 120 milliseconds.

[0054] Each rendering controller 2 has its own independent voltage regulation circuit, which is not shared with each other. Each rendering controller 2 is equipped with a completely independent voltage regulation circuit. When a single device experiences a sudden load change or short circuit, the fault current will not be conducted to other rendering controllers 2 through the common power supply link, thus avoiding the problem of a single fault causing the power supply of the entire multi-screen system to collapse, and greatly improving the overall fault tolerance of the stereoscopic display system.

[0055] Each display screen 3 is equipped with an independent constant current boost backlight driver circuit, one circuit per screen. Each backlight driver circuit only shares the input power and ground, and their switching nodes are not shared. This can be achieved using a constant current boost driver chip. Each display screen 3 is equipped with a dedicated and independent constant current boost backlight driver circuit. When a short circuit or overcurrent fault occurs in a single backlight circuit, the fault will not be conducted to other screens through the shared switching nodes. This avoids the problem of a single screen backlight abnormality causing the backlight of the entire stereoscopic display device to go out collectively, greatly improving the operational reliability of the multi-screen system.

[0056] Each rendering controller 2 uses a module integrating 16 megabytes of flash memory and 32 megabytes of external memory. When the second unidirectional data bus 8 has a long trace on the printed circuit board and is a one-to-many connection, a source-end matching resistor of 22 to 33 ohms can be connected in series on the clock line and data output line on the main controller 1 side, and then passed through each rendering controller 2 in a daisy chain to suppress reflections.

[0057] It's important to note the heartbeat cycle for state line 9. State line 9 is sent by the rendering controller 2 using a bit-flipping method. Sending one byte requires approximately 4.6 milliseconds of continuous processing on one of the processor cores. If the sending cycle is shorter, such as 8 milliseconds, it will occupy about 35% of the core's time, conflicting with the rendering work that core is handling simultaneously. However, using a 40-millisecond cycle allows 3 bytes to fall within the main controller's 1120-millisecond freshness determination window, ensuring the reliability of the determination remains unaffected.

[0058] Regarding the clock frequency of the second unidirectional data bus 8: This bus has a trace length of approximately 610 mm within the entire machine and is a one-to-many connection, so an excessively high frequency is not advisable. However, actual measurements show that lower frequencies do not necessarily lead to greater stability: lowering it to 1 MHz actually worsens the situation, with 0 successful resolutions within an observation window of approximately 110 seconds, and 146 to 233 frame end failures on each rendering controller 2 side; increasing it to 3 MHz causes decoding by one of the rendering controllers 2 to fail. A clock frequency of 2 MHz ensures stable operation. Therefore, this embodiment uses 2 MHz.

[0059] Furthermore, regarding the necessity of each rendering controller 2 employing its own independent voltage regulator circuit, when the voltage regulator circuit margin is insufficient or multiple rendering controllers 2 share the same circuit, the voltage drop under current transients will only cause individual rendering controllers 2 to fail, thus disrupting the consistency between screens. In actual testing, when four rendering controllers 2 from the same batch were running beyond their rated frequency, only one of them failed and reset due to the voltage drop of its voltage regulator circuit under current transients, occurring approximately four times within 150 seconds; after returning to the rated frequency, it did not recur within 450 seconds. Therefore, each rendering controller 2 should be equipped with its own independent voltage regulator circuit.

[0060] This embodiment also provides a rendering synchronization method for multi-node stereoscopic display, applied to the aforementioned stereoscopic display device. The device includes a main controller 1 and M rendering controllers 2. The main controller 1 outputs periodic gating signals to each rendering controller 2 via a synchronization signal line 6, and broadcasts frame synchronization messages via a first unidirectional data bus 7. There is no return path on the first unidirectional data bus 7. The main controller 1 outputs periodic synchronization strobe signals to M rendering controllers 2 via synchronization signal line 6, and broadcasts frame synchronization messages carrying frame sequence numbers to M rendering controllers 2 via the first unidirectional data bus 7; the frame sequence number of the frame synchronization message and the strobe period of the synchronization strobe signal increase sequentially, and the two correspond one-to-one. Each rendering controller 2 performs the following steps: S1. Accumulate and count the specified edges of the synchronous gating signal, with a count increment of one in each gating cycle; S2. When a frame synchronization message is received, the local frame sequence number is set to the frame sequence number carried by the frame synchronization message, and the current edge cumulative count is recorded as the anchor value and the current time is the time of the most recent message. S3. When each specified edge arrives, determine whether the difference between the current time and the most recent message time exceeds a preset time limit; if it does not exceed the time limit, keep the local frame sequence number unchanged; if it exceeds the time limit, update the local frame sequence number to the sum of the most recently received frame sequence number and the current edge cumulative count minus the anchor value. S4. Export the animation clock using the local frame number and render the screen based on the animation clock.

[0061] The gating signal output by the main controller 1 through the synchronization signal line 6 has physical periodicity, and the frame sequence number carried by the frame synchronization message increases sequentially and corresponds one-to-one with it. When each rendering controller 2 receives a frame synchronization message, it locks the frame sequence number of the message with the current physical edge count value (anchor value). Thereafter, regardless of whether the message is interrupted, the local frame sequence number in each rendering controller 2 will remain locked or automatically corrected according to the physical count increment when the edge of each gating cycle arrives. This significantly suppresses frame number jumps or misalignments caused by differences in message reception time or software processing delays at each node, ensuring that the entire system outputs images with the same frame sequence number at the same physical moment.

[0062] The rendering synchronization method in this embodiment includes three key points, all of which must be present simultaneously. First, the mechanism does not intervene at all when the message is normal. When the message is fresh, the local frame sequence number is a step function driven purely by the message; the assignment statement in the synchronization strobe interrupt is not executed, and each rendering controller 2 latches the same constant between two messages, which is the source of consistency between screens. If this preset time limit is not set, allowing the synchronization strobe signal to always participate in incrementing, it will introduce jitter when the message is normal. Second, the mechanism only takes over after the preset time limit has elapsed; the condition for taking over is the conjunction of two conditions: "already anchored" and "more than the preset time limit since the most recent message has elapsed." Third, the local frame sequence number during the carrying period is not continued from the frozen value, but is re-derived according to "the most recent valid frame sequence number plus the accumulated edge count since the anchoring time". Since each rendering controller 2 shares the same synchronization strobe signal line and its anchoring reference comes from the same broadcast sequence number, after their respective guarding mechanisms take effect, the local frame sequence numbers derived by each rendering controller 2 are the same and advance together, rather than advancing independently. Once the message is restored, the anchoring reference and anchoring count are reset, and any deviations accumulated during the carrying period are erased at once, leaving no residual error.

[0063] Referring to Figure 3, from top to bottom, the figures are: the synchronization gating signal on the synchronization signal line 6, the frame synchronization message on the first unidirectional data bus 7, and the local frame sequence numbers of the two rendering controllers 2 (referred to as node 2-1 and node 2-2 in the figure). The horizontal axis represents time, with each grid representing one gating cycle; in this embodiment, the gating signal frequency is 18 Hz, and one gating cycle is approximately 55.6 milliseconds.

[0064] The synchronization strobe signal flips continuously at a fixed period throughout the entire process. Each rendering controller 2 accumulates a count of its designated edge (rising edge in this embodiment), incrementing the count by one for each strobe cycle, i.e., step S1. This count is driven only by the physical edge on the synchronization signal line 6 and is independent of whether there is a message on the first unidirectional data bus 7.

[0065] From frame 0 to frame 5, the main controller 1 broadcasts frame synchronization messages periodically via the first unidirectional data bus 7. The frame numbers carried are 100 to 105, corresponding one-to-one with the gating cycle. Each rendering controller 2, upon receiving a message, sets its local frame number to the frame number carried in that message, records the current edge count as the anchor value, and records the current time as the time of the most recent message (step S2). The local frame number in the diagram is stepped rather than sloped: it remains a constant between two adjacent messages. Each rendering controller 2 latches the same constant, which is the source of the same frame being displayed on each display screen 3 at the same time.

[0066] Starting from the 6th frame, the frame synchronization message is interrupted, and the first unidirectional data bus 7 track in the diagram is empty in this interval. At each specified edge, the rendering controller 2 compares the difference between the current time and the most recent message time to see if it exceeds a preset time limit, i.e., step S3. In this embodiment, the preset time limit is 150 milliseconds, equivalent to approximately 2.70 gating cycles. Within this time limit, the local frame sequence number remains unchanged: node 2-1 last received 105 from the 5th frame, and subsequently, 55.6 milliseconds have passed in the 6th frame and 111.1 milliseconds have passed in the 7th frame, both not exceeding 150 milliseconds. Therefore, it remains 105 in these two frames, and the horizontal segment of this track in the diagram during the 6th and 7th frames represents this short holding period.

[0067] By the 8th frame, 166.7 milliseconds had passed since the most recent message, exceeding the preset time limit, while the synchronization strobe signal remained normal. Therefore, rendering controller 2 stopped waiting for messages and updated the local frame sequence number to the sum of the most recently received frame sequence number and the current edge cumulative count minus the anchor value. Here, the value is not continuously incremented from the existing value, but rather re-derived from the anchor point each frame: node 2-1 obtains 105 + (8-5) = 108 in the 8th frame, 109 in the 9th frame, and so on. The frame sequence number track in the diagram continues to ascend at a rate of one increment per frame during the message interruption, perfectly synchronized with the synchronization strobe signal.

[0068] Figure 3 The two rendering controllers 2 lose messages at different times: node 2-1 last received 105 on the 5th frame, while node 2-2 last received 103 on the 3rd frame. Their anchor values ​​and timeout times are also different. Node 2-2 maintains 103 on the 4th and 5th frames, and starts to advance on its own from the 6th frame, obtaining 103 + (6-3) = 106. Nevertheless, since the edge cumulative counts of both come from the same edge on the same synchronization signal line 6, and their respective anchor frame sequence numbers and anchor counts are recorded in pairs, substituting into the above formula, they both obtain the same value at the same physical moment: on the 8th frame, node 2-1 is 105 + (8-5) = 108, and node 2-2 is 103 + (8-3) = 108, which is the same; thereafter, on the 9th frame, both are 109, and on the 10th frame, both are 110, until the message is recovered. This is why this embodiment can maintain consistency across screens during message interruption: the local frame sequence number does not depend on how many messages each node has received, but only on the shared physical edge count and their respective anchoring relationships.

[0069] The 14th message is recovered, carrying a frame sequence number of 114. Each rendering controller 2 re-anchors according to step S2, that is, sets its local frame sequence number to 114 and refreshes the anchor value and the most recent message time. Since the local frame sequence number of each node has just advanced to 114 during the automatic advancement, the value at the re-anchoring point is connected to the value of the automatic advancement. The two frame sequence number tracks in the figure coincide with the message track at this point, and the frame sequence number does not jump or roll back.

[0070] Finally, each rendering controller 2 derives an animation clock using its local frame number and renders the screen based on that animation clock, i.e., step S4. Since the local frame number increments frame by frame throughout the process and remains consistent across nodes, each display 3 always presents the same frame at the same physical moment.

[0071] Specifically, we can first understand the following three key variables: The sequence number of the most recently received frame: the number of the last frame successfully received from the first unidirectional data bus 7 (e.g., 373884). Anchor value: The cumulative number of edges generated by synchronization signal line 6 at the same moment when the "most recent frame number" is received (for example, the count at that time was 271800). Current edge count: The current edge count generated by hardware synchronization signal line 6 (e.g., the current count is 271850).

[0072] In scenarios where messages are normal (within the preset time limit), the local frame sequence number remains unchanged. Specifically, frame synchronization messages arrive continuously on the first unidirectional data bus 7, with the most recent message occurring just milliseconds ago. At this time, the rendering controller 2 does nothing, directly ignoring the edge interruption of the synchronization signal line 6 and continuing to use the frame sequence number from the previous message.

[0073] In the scenario of message interruption (exceeding the preset time limit), when the first unidirectional data bus 7 stops for more than the preset time limit (e.g., 150 milliseconds), but the synchronization strobe signal is still healthy, the following formula is executed: New local frame sequence number = the most recently received frame sequence number + (current edge cumulative count - anchor value); Substituting the above values, the calculation is: 373884 + (271850 - 271800) = 373934.

[0074] Understandably, the "difference" represents the elapsed time, meaning "how many hardware cycles have passed since the last valid message was received." Since the main controller 1 sends one frame per cycle, this difference equals the "number of lost / missed frames." Because all rendering controllers 2 share the same synchronization signal line 6 (with the same edge count), and the last received frame sequence number is the same (broadcast message), when this condition is triggered, the "new frame sequence number" calculated by all controllers is exactly the same (all 373934). Once the data bus recovers and a new message arrives, the "most recent message time" is refreshed, and the anchor count is reset to the current edge count. At this point, the time interval returns to zero, the judgment returns to the "not exceeded" state, the formula is no longer executed, and any small deviations accumulated during the takeover period are erased in one go, leaving no residual.

[0075] The specified edge of the synchronization gating signal in step S1 of this embodiment needs to be explained as follows. The above formula directly uses the "accumulated number of edges since the anchoring time" as the increment of the frame sequence number. The premise of this formula is that the edge count and the frame sequence number advance with the same step size, that is, each synchronization gating cycle increases the count by exactly one. Since the main controller 1 sends a frame synchronization message and increments the frame sequence number by one in each synchronization gating cycle, and there are two edges in one cycle, one rising edge and one falling edge, each rendering controller 2 must pre-select one of the rising edge and the falling edge and count only that kind of edge. If this limitation is not made and both edges are counted together, the count will advance at twice the rate of the frame sequence number, and the local frame sequence number derived during the carrying period will advance at twice the correct value, and the animation clock will be accelerated accordingly. As for whether to select the rising edge or the falling edge, it has no impact on the embodiment, as long as the type selected by each rendering controller 2 is the same; for example, the rising edge is selected in this embodiment.

[0076] In this embodiment, the frequency of the synchronization strobe signal on synchronization signal line 6 is 18 Hz, corresponding to a period of approximately 55.5556 milliseconds. Each rendering controller 2 captures this signal via an edge interrupt on a general-purpose input / output pin. The interrupt service routine resides in the internal instruction memory to ensure deterministic response and accumulates the rising edge count therein. The rendering controller 2 determines "synchronization online" within a 500-millisecond window; that is, if the most recent strobe rising edge is more than 500 milliseconds ago, synchronization is considered lost and the system is degraded to free-running based on the local clock. The number of warm-up frames during the device power-on initialization phase is 8. During this phase, the rendering gate is not suspended to avoid deadlock during the first frame initialization.

[0077] In this embodiment, the first unidirectional data bus 7 is a unidirectional asynchronous serial bus with a baud rate of 115200, 8 data bits, no parity bit, 1 stop bit, and no return connection. The frame synchronization message transmitted on it has a fixed-length 8-byte compact structure, consisting of a two-byte start flag (values ​​0xA5 and 0x5A), a one-byte opcode (0x01 in the frame synchronization message), a four-byte little-endian parameter (which is the frame sequence number in the frame synchronization message), and a one-byte checksum. The checksum is calculated over the five bytes of the opcode and parameter, using an 8-bit cyclic redundancy check with a generator polynomial of 0x07 and an initial value of 0. The main controller 1 sends one frame and increments the frame sequence number in each strobe cycle; the rendering controller 2 receives the message in a parsing loop with start flag resynchronization, that is, it searches for the start flag in the byte stream to re-establish the frame boundary at any time.

[0078] In this embodiment, the preset time limit in step S3 is K gating cycles, where K is any integer from 2 to 5. The preset time limit is 150 milliseconds. Calculated using a gating cycle of 55.5556 milliseconds, this time limit is equivalent to 2.70 gating cycles, falling within the range of 2 to 5 with margin on both sides.

[0079] Setting the preset time limit to 2 to 5 gating cycles provides a reasonable engineering tolerance range: if it is less than 2 cycles, the guard mechanism may be triggered erroneously due to normal message transmission jitter; if it is more than 5 cycles, the message interruption time will be too long, and unacceptable frame sequence number deviations may accumulate between nodes.

[0080] Specifically, in this embodiment, the rendering controller 2 performs re-anchoring upon receiving a frame synchronization message: it sets the anchoring reference to the absolute frame sequence number carried in the message, sets the anchoring count to the current rising edge cumulative count, sets the anchored flag to true, sets the most recent message time to the current time, and directly sets the local frame sequence number to the frame sequence number carried in the message. At each rising edge of the synchronization strobe signal, if the anchored flag is true and the difference between the current time and the most recent message time exceeds 150 milliseconds, the local frame sequence number is set to the anchoring reference plus the difference between the current rising edge cumulative count and the anchoring count; otherwise, no value is assigned. Thus, when the message is normal, the local frame sequence number is entirely driven by the message, and this assignment in the edge interrupt is an empty operation.

[0081] In this embodiment, each rendering controller 2 periodically sends a ready signal back to the main controller 1 via the corresponding state line 9; the main controller 1 only enables the display screen 3 to display when the ready signals of all rendering controllers 2 meet the preset conditions.

[0082] Each rendering controller 2 periodically sends back an encoded byte as a ready signal via an independent state line 9, enabling the main controller 1 to monitor the operational status of each node in real time. The main controller 1 only enables screen display when all registered rendering controllers 2 are in a ready state, all ready signals of rendering controllers 2 are within a 120-millisecond freshness window, and the states represented by each ready signal belong to the acceptable state set. This avoids abnormal situations such as screen tearing, black screens on some displays 3, or displaying outdated images when some nodes are not ready.

[0083] In this embodiment, the acceptable state set includes two states: "ready and frame received" and "ready and running". Either one is acceptable, and their codes are 0x5 and 0x4, respectively.

[0084] The specific implementation of state line 9 in this embodiment is as follows: it is a single-wire open-drain structure connected to the power supply via a pull-up resistor. It is high-level when idle, with a baud rate of 2400. Each byte consists of a start bit, eight data bits (lowest bit first), an even parity bit, and a stop bit. The high 4 bits of the byte represent the firmware version of the rendering controller 2, and the low 4 bits represent its ready state. The feedback period is 40 milliseconds.

[0085] In this embodiment, each rendering controller 2 rasterizes the same frame in parallel using two processor cores, dividing the frame into two non-overlapping stripes according to the scan lines, and assigning each stripe to one processor core for processing; each rendering controller 2 records the actual rasterization time of each of the two processor cores in the previous frame, and adjusts the scan line where the stripe boundary of the next frame is located based on the difference between the two.

[0086] Specifically, the worker thread records the actual rasterization time of each of the two cores in the previous frame. The control quantity is calculated by multiplying the difference between the two cores by the image height and then dividing by the sum of the two cores; this formula is a self-normalized proportional term. The resulting displacement is applied with half-step damping, i.e., divided by 2, and limited to ±16 scan lines per frame. The boundary line clamp is located between lines 12 and 273, with an initial value of half the image height, i.e., line 142. The rasterization function clamps each strip according to its upper and lower boundaries, so the pixel output remains unchanged regardless of where the boundary falls. The movement of the boundary only re-divides which core writes which non-overlapping scan lines.

[0087] In traditional parallel rendering with fixed boundaries (such as half-segmented scan lines), if the upper half of the image is a complex scene and the lower half is a simple background, the processor core responsible for the upper half will be severely overloaded, while the other core will become idle prematurely, limiting the overall frame rate to the slower core. Therefore, this embodiment records the actual rasterization time of the two cores in the previous frame and uses the difference between them as feedback to adjust the boundary position of the next frame, forming a closed-loop negative feedback control system. After several frames of iterative convergence, the boundary line will automatically migrate to a scan line position where the time consumed by the two cores tends to be equal, achieving the theoretical minimum frame rendering time and significantly improving rendering throughput.

[0088] In this embodiment, each rendering controller 2 counts the minimum and maximum values ​​of the depth value in the screen space of each frame, and linearly maps the depth value of the frame to a fixed-point integer as the key of the depth buffer, while retaining a code value that is not in the mapped value range as a screen clearing sentinel; when counting extreme values, vertices located outside the screen are removed.

[0089] Specifically, each rendering controller 2 first scans the minimum and maximum depth values ​​within the screen space of each frame, and removes vertices located outside the screen during the scan—these vertices are clamped as invalid coordinates during the quantization process; if not removed, the depth range will be over-expanded, causing the effective precision to approach zero. Then, using the minimum value as a bias, and proportionally by dividing 65534 by the difference between the maximum and minimum values, the pixel-wise depth is linearly mapped to a 16-bit integer and clamped between 0 and 65534, with 65535 serving as a screen-clearing sentinel. The depth buffer is divided into two sub-planes according to the scan lines. The first sub-plane covers lines 0 to 141, with a capacity of 160 x 142 x 2 (45440 bytes); the second sub-plane covers lines 142 to 284, with a capacity of 160 x 143 x 2 (45760 bytes). The two sub-planes independently request storage space, prioritizing the internal memory of the rendering controller 2, and reverting to external memory if the request fails. Addressing the depth buffer determines the subplane to which a pixel belongs by the scan line it is in. Only one line determination is needed per pixel, and the overhead is negligible.

[0090] The minimum and maximum depth values ​​within the current screen space are counted frame by frame. Based on these values, a linear mapping is performed to generate a fixed-point integer depth key. This method abandons the traditional global fixed depth range mapping method and allows the effective depth value of the current frame to completely cover the entire value range of the fixed-point integer. This significantly improves the depth accuracy of the depth buffer and reduces depth conflicts caused by the depth values ​​of near and far objects being too close.

[0091] Furthermore, regarding internal resolution and hardware scaling: Each rendering controller 2 renders at an internal resolution lower than the display resolution, and then the hardware scaling unit scales it up to the display resolution in a non-blocking manner. This allows the rendering controller 2 to allocate more resources to complex model details, physics simulation, or anti-aliasing within a limited computing budget, avoiding stuttering due to insufficient computing power. Each rendering controller 2 renders at an internal resolution of 160 x 285, and then the hardware scaling unit scales it up by 3 times before outputting it to the 480 x 854 display screen 3. Since 3 times the internal rendering height equals 855 rows, exceeding the 854 rows of the display screen 3, the source image sent to the scaling unit takes 284 rows from the internal rendering result, which is then scaled up to 852 rows, with one row left at the top and bottom of the display screen 3 and centered. The horizontal 160 columns, after being scaled up by 3 times, become exactly 480 columns, requiring no rounding. Scaling is initiated in a non-blocking manner, with a completion interrupt releasing the semaphore, allowing the scaling process to overlap with the rendering of the next frame in time. The color buffer is double-buffered, while the scan buffer output to display screen 3 is triple-buffered. Triple buffering is used instead of double buffering to avoid competition between the writing of the hardware scaling unit and the scan output of display screen 3.

[0092] Please refer to Figure 4 In this embodiment, the main controller 1 can also broadcast the identifier of the animation state set to the M rendering controllers 2 via the second unidirectional data bus 8. At this time, each rendering controller 2 performs the following steps: S2.1. Based on the identifier of the animation state set and the attribute flags of the locally stored 3D model, determine a set containing multiple discrete animation states. S2.2 Derive the time value from the local frame sequence number and calculate the interval index to which the time value belongs; S2.3. At least with the interval index as input, select the state index from the animation state set using the same deterministic function as the other rendering controllers 2; S2.4. According to the animation state corresponding to the selected state index, the same 3D model is rendered and output to the display screen 3 driven by the rendering controller 2 using the camera azimuth angle corresponding to the rendering controller 2.

[0093] The main controller 1 broadcasts the identifier of the animation state set only through the second unidirectional data bus 8. It does not need to send massive amounts of animation frame data to each rendering controller 2 individually. It can complete the unified scheduling of the global animation state with only a very small number of broadcast data packets, which greatly reduces the data transmission bandwidth pressure between the main controller 1 and multiple rendering nodes. Even if the M value increases with the number of displays 3, there will be no problem of the data transmission load increasing exponentially.

[0094] Each rendering controller 2 obtains the time value in seconds by dividing the local frame number by the gating frequency 18. The start time of the current action category is recorded by each rendering controller 2: when a broadcast animation state set identifier is received, and this identifier differs from the currently active one, each rendering controller 2 records the time value derived from the local frame number as the start time of the current round. Since each rendering controller 2 decodes the same broadcast message under the same frame number, and the new start time is derived only from the previous state and this time value, the start times recorded by each rendering controller 2 are identical. The relative time is obtained by subtracting the start time of the current round from this time value, and then rounded down to the nearest integer (8.0 seconds) to obtain the interval index. The interval length of 8.0 seconds is chosen to match the minimum cycle interval of the device's avatar actions.

[0095] The deterministic function in this embodiment is a hash function with salt values, which are derived from the identifier of the animation state set and the attribute flag of the 3D model. The step of selecting the state index also includes: if the state index obtained by the current interval index is the same as the state index obtained by the previous interval index, then the state index obtained by the current interval index is shifted one position in the animation state set.

[0096] Salt values ​​are derived from both behavior category and model attribute flags, ensuring that different behavior categories or models are hashed to different positions in their respective sets under the same interval index, avoiding crosstalk between action libraries. If the state index calculated from the current interval index is the same as that from the previous interval index, it is automatically shifted one position to avoid visual monotony caused by selecting the same animation state in two adjacent intervals.

[0097] Specifically, the deterministic function takes the interval index, set capacity, and salt value as input. The salt value is derived from the behavior category and the attribute flag of the 3D model, and its calculation formula is: behavior category multiplied by 131, plus attribute flag multiplied by 65537, plus 1. The hash function is in the form of a 32-bit terminator, which is: right shift 16 bits XOR, multiply by the constant 0x7FEB352D, right shift 15 bits XOR, multiply by the constant 0x846CA68B, right shift 16 bits XOR. During selection, the interval index is first multiplied by the constant 2654435761 and then the salt value is added. After hashing, the remainder is taken with respect to the set capacity to obtain the state index. If this state index is the same as the state index calculated using the same method for the previous interval index, it is shifted one position in the set to avoid selecting the same animation state in two adjacent intervals.

[0098] It should be noted that each rendering controller 2 maintains the selected animation state within the same interval index, and performs a cross-fade between two adjacent intervals for a duration of 0.6 seconds. For example, the fade-in duration for entering the first state and the fade-out duration for exiting the first state are both 1.0 seconds. During the maintenance of the animation state, a procedural periodic motion derived from the local frame sequence number is superimposed onto that animation state. The above superposition is only applied to the pose during maintenance.

[0099] Furthermore, the rotation angle of the 3D model itself is always 0 degrees in this embodiment, that is, the model does not rotate, and the camera azimuth angle corresponding to each rendering controller 2 is a fixed value independent of time; the sense of stereoscopic effect is entirely generated by the fixed camera azimuth angle corresponding to each rendering controller 2. Each rendering controller 2 determines its own camera azimuth angle by the node identifier stored in its non-volatile storage unit 10.

[0100] Understandably, the stereoscopic image is composed of images provided by multiple displays 3 from different directions, which are then combined into a single three-dimensional image after being reflected by the beam splitter 4. To achieve accurate stereoscopic imaging, each display 3 must present a view of the same three-dimensional model in the same posture but viewed from different angles, rather than the model itself rotating, thus avoiding distortion or misalignment caused by the model's rotation.

[0101] In the description of this invention, it should be understood that terms such as "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0102] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0103] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A stereoscopic display device, comprising a reflector, N display screens, M rendering controllers, and a main controller, wherein the reflector includes N beam splitters, the N beam splitters are correspondingly arranged with respect to the N display screens, and each rendering controller drives a plurality of the display screens; wherein N is an integer not less than 3, and M is an integer greater than 1 and not greater than N; the main controller is connected to each of the rendering controllers via: A synchronization signal line is used to transmit periodic synchronization strobe signals to each of the rendering controllers; A first unidirectional data bus is used to broadcast first data to each of the rendering controllers; There are M independent state lines. One end of each state line is connected to the main controller, and the other end is connected to a corresponding rendering controller. The rendering controllers connected to different state lines are different from each other.

2. The stereoscopic display device according to claim 1, characterized in that, When M=N, each of the rendering controllers drives one of the displays; when M is even and M=1 / 2N, each of the rendering controllers drives two displays.

3. The stereoscopic display device according to claim 1, characterized in that, A second unidirectional data bus is also connected between the main controller and each of the rendering controllers. The second unidirectional data bus is used to broadcast second data to each of the rendering controllers.

4. A rendering synchronization method for multi-node stereoscopic display, applied to a stereoscopic display device, the device comprising a main controller and M rendering controllers, the main controller outputting periodic gating signals to each of the rendering controllers via a synchronization signal line, and broadcasting frame synchronization messages via a first unidirectional data bus, wherein there is no return path on the first unidirectional data bus; characterized in that: The main controller outputs periodic synchronization strobe signals to the M rendering controllers via the synchronization signal line, and broadcasts frame synchronization messages carrying frame sequence numbers to the M rendering controllers via the first unidirectional data bus; the frame sequence number of the frame synchronization message and the strobe period of the synchronization strobe signal increase sequentially, and the two correspond one-to-one. Each of the aforementioned rendering controllers performs the following steps: S1. Accumulate and count the specified edges of the synchronous gating signal, with a count increment of one in each gating cycle; S2. When the frame synchronization message is received, the local frame sequence number is set to the frame sequence number carried by the frame synchronization message, and the current edge cumulative count is recorded as the anchor value and the current time is the time of the most recent message. S3. When each specified edge arrives, determine whether the difference between the current time and the latest message time exceeds a preset time limit; If the limit is not exceeded, the local frame sequence number remains unchanged; If the limit is exceeded, the local frame sequence number is updated to the sum of the most recently received frame sequence number and the current edge cumulative count minus the anchor value; S4. Export the animation clock using the local frame number, and render the screen based on the animation clock.

5. The rendering synchronization method for multi-node stereoscopic display according to claim 4, characterized in that, The preset time limit in step S3 is K gating cycles, where K is any integer from 2 to 5.

6. The rendering synchronization method for multi-node stereoscopic display according to claim 4, characterized in that, Each rendering controller periodically sends a ready signal back to the main controller via a corresponding independent state line; the main controller only enables the display screen to display when the ready signals of all rendering controllers meet preset conditions.

7. The rendering synchronization method for multi-node stereoscopic display according to claim 4, characterized in that, Each of the rendering controllers rasterizes the same frame in parallel using two processor cores, dividing the frame into two non-overlapping strips according to the scan lines, and assigning each strip to one of the processor cores for processing; each of the rendering controllers records the actual rasterization time of each of the two processor cores in the previous frame, and adjusts the scan line where the strip boundary of the next frame is located based on the difference between the two.

8. The rendering synchronization method for multi-node stereoscopic display according to claim 4, characterized in that, Each rendering controller calculates the minimum and maximum depth values ​​in the screen space of each frame, and linearly maps the depth values ​​of the frame to fixed-point integers as keys for the depth buffer, while retaining a code value that is not in the mapped value range as a screen clearing sentinel; when calculating the extreme values, vertices located outside the screen are removed.

9. The rendering synchronization method for multi-node stereoscopic display according to claim 4, characterized in that, The main controller also broadcasts the identifier of the animation state set to the M rendering controllers via a second unidirectional data bus. At this time, each rendering controller performs the following steps: S2.

1. Based on the identifier of the animation state set and the attribute flags of the locally stored 3D model, determine a set containing multiple discrete animation states; S2.2 Derive the time value from the local frame sequence number and calculate the interval index to which the time value belongs; S2.

3. Using at least the interval index as input, select a state index from the animation state set using the same deterministic function as the other rendering controllers; S2.

4. According to the animation state corresponding to the selected state index, and using the camera azimuth angle corresponding to this rendering controller, render the same 3D model and output it to the display screen it drives.

10. The rendering synchronization method for multi-node stereoscopic display according to claim 9, characterized in that, The deterministic function is a salted hash function, and the salt value is derived from the identifier of the animation state set and the attribute flag of the 3D model; the step of selecting the state index further includes: if the state index obtained by the current interval index is the same as the state index obtained by the previous interval index, then the state index obtained by the current interval index is shifted one position in the animation state set.

11. The rendering synchronization method for multi-node stereoscopic display according to claim 9, characterized in that, The 3D model does not rotate during the rendering process, and the camera azimuth angle corresponding to each rendering controller is a fixed value independent of time; and each rendering controller determines its corresponding camera azimuth angle by the node identifier stored locally.

12. The rendering synchronization method for multi-node stereoscopic display according to claim 4, characterized in that, Each of the rendering controllers renders at an internal resolution lower than the display resolution, and then the hardware scaling unit scales it up to the display resolution in a non-blocking manner.