A dynamic rendering engine and intelligent lighting device control method

Abstract

The application relates to a dynamic rendering engine and a smart lighting device control method, wherein the dynamic rendering engine comprises: a scene mode registration module, which is used for registering one or more scene modes, each of which corresponds to a scene rendering function; a time management module, which is used for maintaining a time reference value and updating the time reference value; a rendering scheduling module, which is used for calculating a progress parameter representing an animation process according to a current system time and the time reference value, and calling a target scene rendering function and inputting the progress parameter into the function; and a frame buffer module, which is used for storing rendering data generated by the scene rendering function in response to the progress parameter; wherein the scene rendering function is configured to output the same rendering data for the same progress parameter. Through the above design, the application realizes instantaneous determination, millisecond-level synchronization, seamless recovery and accurate control of a rendering state.

Description

Technical Field

[0001] This invention relates to the field of intelligent lighting control technology, and in particular to a dynamic rendering engine and an intelligent lighting equipment control method. Background Technology

[0002] With the popularization of smart lighting technology, users have placed higher demands on the richness and smoothness of dynamic lighting effects (such as gradients, color flows, and scene changes), as well as the collaboration between multiple devices. The core of achieving these complex animation effects lies in a high-efficiency and reliable rendering engine.

[0003] In existing technologies, the dynamic rendering control of intelligent lighting devices mainly has the following two typical solutions and their inherent defects: 1. Frame-based rendering control: This is the most traditional approach. It relies on a continuously incrementing frame counter to drive the animation progress, with each frame's rendering output uniquely determined by its current frame number. This method suffers from the following technical bottlenecks: The rendering result depends on historical state: the rendering output of each frame is not independent, but heavily relies on the historical accumulated value of the frame counter. This counter is a critical internal state variable, and the correctness of its value directly affects the rendering result. Once the counter becomes inaccurate due to unexpected circumstances (such as arithmetic overflow or being incorrectly reset), it will directly lead to abnormal rendering.

[0004] System reboot results in state loss and animation jumps: Frame counters are typically stored in volatile memory. When the device loses power or the rendering process restarts, the counter state is lost and reset to zero. This causes the animation to fail to resume from the point of interruption, instead being forced to jump back to the starting frame to begin again, resulting in significant user experience interruptions and screen jumps.

[0005] Low synchronization accuracy and cumulative errors across multiple devices: To achieve animation synchronization between multiple devices, the current frame sequence number of the master device needs to be broadcast to the slave devices. However, due to network transmission latency and slight differences in the internal operating cycles of each device, the frame sequence number received by the slave device is delayed, causing its rendering progress to be out of sync with the master device. More seriously, this sequence number-based deviation accumulates over time, making it difficult to achieve and maintain high-precision synchronization at the millisecond level.

[0006] Implementing state transitions at arbitrary times is complex: to jump to any point in the animation stream, the corresponding target frame number must be precisely calculated. This process often requires recording and restoring the counter state before the jump, which is logically complex and prone to errors.

[0007] 2. Another common approach based on simple time delay control relies on a fixed time delay to control the switching of light states. This method is more rudimentary, and its limitations are: The animation is severely lacking in expressiveness: it can usually only achieve simple blinking or a cycle of switching between two states, and cannot support complex dynamic effects with continuous changes in color and brightness.

[0008] Time control accuracy is difficult to guarantee: the accuracy of timing delay is easily affected by system load and interrupt response, making it difficult to provide a stable and accurate time reference.

[0009] Lack of effective coordination mechanism: Each device runs its own delay cycle independently, lacking a unified synchronization signal, making it impossible to achieve a coordinated and consistent dynamic effect among multiple devices.

[0010] Therefore, there is an urgent need in this field for an innovative rendering engine architecture that can fundamentally overcome the shortcomings of the existing technologies mentioned above, and achieve instantaneous determination of rendering state, high-precision synchronization between devices, seamless recovery of running state, and flexible control of animation progress.

[0011] It should be noted that the information disclosed in the background section above is only for understanding the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0012] The technical problem this application aims to solve is: how to overcome the inherent defects of animation rendering models based on state accumulation in order to achieve instantaneous determination and precise control of the rendering state.

[0013] The technical solution adopted in this application to solve the above-mentioned technical problems is as follows.

[0014] This application provides a dynamic rendering engine, including: The scene mode registration module is used to register one or more scene modes, and each scene mode corresponds to a scene rendering function. The time management module is used to maintain and update a time base value. The rendering scheduling module is used to calculate the progress parameters representing the animation process based on the current system time and time base value, and call the target scene rendering function, inputting the progress parameters into the function; The frame buffer module is used to store rendering data generated by the scene rendering function in response to the progress parameter; The scene rendering function is configured to output the same rendering data for the same progress parameters.

[0015] In some embodiments, the dynamic rendering engine further includes a state machine module for managing the running state of the dynamic rendering engine; the running state includes at least one of a stopped state, an initialized state, a running state, a paused state, and a jump state.

[0016] In some embodiments, the time management module is further configured to maintain a color unit time, which is a preset duration of a color unit; the progress parameter consists of the current color unit index and the elapsed time within the current color unit; the rendering scheduling module calculates the progress parameter, including: calculating the elapsed time within the current color unit based on the difference between the current system time and the time base value; and determining the current color unit index based on the elapsed time within the current color unit and the color unit time.

[0017] In some embodiments, the time base value maintained by the time management module is the start time of the current color unit; the rendering scheduling module calculates the elapsed time in the current color unit based on the difference between the current system time and the start time of the current color unit; when the elapsed time in the current color unit is greater than or equal to the color unit time, the start time is updated and the index of the current color unit is adjusted.

[0018] In some embodiments, the time management module updates the time base value by: responding to an external jump instruction or synchronization instruction, the external instruction carrying the target color cell index and the elapsed time within the target color cell; the time management module calculates the target color cell start time based on the target color cell index, the elapsed time within the target color cell, and the color cell time, and updates the time base value to the target color cell start time.

[0019] In some embodiments, a method for controlling an intelligent lighting device is also provided, comprising: registering one or more scene modes, each scene mode corresponding to a scene rendering function; maintaining a time reference value; calculating a progress parameter representing the animation process based on the current system time and the time reference value; calling a target scene rendering function and inputting the progress parameter into the function to obtain rendering data; wherein the scene rendering function is configured to output the same rendering data for the same progress parameter; and controlling the intelligent lighting device based on the rendering data.

[0020] In some embodiments, the intelligent lighting device control method further includes: managing the operating state of the intelligent lighting device control method; the operating state includes at least one of the following: stop state, initialization state, running state, paused state, and jump state.

[0021] In some embodiments, the intelligent lighting device control method further includes maintaining a color unit time, wherein the color unit time is a preset duration of a color unit; the progress parameter consists of the current color unit index and the elapsed time within the current color unit; calculating the progress parameter includes: calculating the elapsed time within the current color unit based on the difference between the current system time and the time base value; and determining the current color unit index based on the elapsed time within the current color unit and the color unit time.

[0022] In some embodiments, the time base value is the start time of the current color unit; the elapsed time in the current color unit is calculated by calculating the difference between the current system time and the start time; when the elapsed time in the current color unit is greater than or equal to the color unit time, the start time is updated and the current color unit index is adjusted.

[0023] In some embodiments, the intelligent lighting device control method further includes the step of updating a time reference value: receiving an external jump instruction or synchronization instruction, the instruction carrying a target color cell index and the elapsed time within the target color cell; calculating the start time of the target color cell based on the target color cell index, the elapsed time within the target color cell, and the color cell time; and updating the maintained time reference value to the start time of the target color cell.

[0024] The present invention has the following beneficial effects: Because this invention employs the technical feature of "calculating progress parameters representing the animation process based on the current system time and time base value," it utilizes the physical characteristics of linear and independently measurable time as the basis for calculation, mapping the abstract animation process onto a concrete and objective system timeline. This brings the quantifiable function of the animation process, allowing any state of the animation to be accurately described by one or a set of parameters directly related to time, providing an objective basis for state determination and control. Furthermore, because this invention employs the technical feature of "calling the target scene rendering function and inputting the progress parameters into the function," it establishes that the input of the rendering driver is the "progress parameter" rather than the frame number. This brings the function of decoupling the rendering driver mechanism from historical states, making each rendering call independent and not dependent on the result of the previous call or any accumulated counter. Furthermore, because this invention employs the technical feature of "the scene rendering function is configured to output the same rendering data for the same progress parameters," it defines the deterministic nature of the rendering function, making the rendering function a pure function. This brings the function of deterministic and reproducible rendering results, ensuring that as long as the input parameters are the same, the output is strictly consistent regardless of when, where, or under what system state the call takes place.

[0025] In summary, based on the coordination and synergy of the aforementioned technical features, this invention provides diverse rendering capabilities through the "Scene Mode Registration Module"; the "Time Management Module" maintains the time base for the animation process; the "Rendering Scheduling Module" is responsible for converting real-time time into process parameters and driving rendering; and the "Frame Buffer Module" is responsible for temporarily storing the output results. These modules cooperate to achieve instantaneous determination of the rendering state by time parameters and, by managing the "time base value," achieve precise and error-free control of the animation progress, thus successfully overcoming the inherent defects of animation rendering models based on state accumulation.

[0026] Other beneficial effects of the present invention will be further described below. Attached Figure Description

[0027] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 Flowchart of traditional intelligent lighting equipment rendering control method based on frame sequence number; Figure 2 A schematic diagram illustrating the animation state jump of a smart lighting device using frame control after restarting; Figure 3 : A schematic diagram illustrating the static frame rendering data principle and windmill mode rendering effect of this invention; Figure 4 : Block diagram of the algorithm system of the dynamic rendering engine of this invention; Figure 5 : Explanation diagram of the state parameters of the windmill mode entry function of this invention; Figure 6 : Data structure diagram of configuration parameters for windmill mode scene in this invention; Figure 7 : Data structure diagram of rendering progress parameters for windmill mode in this invention; Figure 8 : A schematic diagram of the input parameters of the windmill_seek_to function in the windmill mode of this invention; Figure 9 : A schematic diagram illustrating the internal state update of the windmill_seek_to function in the windmill mode of this invention; Figure 10 : A schematic diagram of the input parameters of the windmill_get_colors function in the windmill mode of this invention; Figure 11 : A schematic diagram of the lamp bead layout of the intelligent lighting device applying the present invention; Figure 12 : Timing diagram of the core function call in the windmill mode of this invention; Figure 13 : This invention defines the master-slave device synchronization data packet format. Figure 14 : Timing diagram of the master-slave device synchronization process using the present invention; Figure 15 : System architecture diagram of the dynamic rendering engine applying the present invention. Detailed Implementation

[0028] The embodiments of the present invention will be described in detail below. It should be emphasized that the following description is merely exemplary and not intended to limit the scope and application of the present invention.

[0029] 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 embodiments of the present invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0030] This invention recognizes the problems existing in the prior art, such as "rendering results depend on historical states, state is lost after device restart, low synchronization accuracy of multiple devices, and complex state transition implementation". Based on the principle of "animation rendering model that depends on state accumulation (such as frame counters)", this invention proposes "a dynamic rendering engine and intelligent lighting device control method" based on the principle of "time-driven and state decoupling" to solve the above-mentioned problems of the prior art.

[0031] Specifically, the present invention achieves the above objectives through the following concepts: First, a time base value independent of the rendering process is maintained by the time management module, which serves as an objective reference point for the animation process; second, the rendering scheduling module calculates a "progress parameter" (e.g., composed of a color unit index and the elapsed time within the unit) representing the absolute progress of the animation based on the difference between the current system time and this time base value. This parameter is only related to time and is independent of the rendering history state; finally, the calculated progress parameter is used as the sole input to call a deterministic scene rendering function registered by the scene mode registration module and configured to "output the same rendering data for the same progress parameter", generating rendering data and storing it in the frame buffer module.

[0032] The contribution of this concept lies in transforming animation rendering from a traditional, historically accumulated state-driven model (such as frame numbers) to a purely functional model driven by objective time parameters that are instantaneously determined. The progress parameter, acting as a mapping of the timeline, allows any state of the animation to be accurately described and reproduced. Therefore, after a device restart, rendering can seamlessly resume from the point of interruption simply by restoring the time base value, eliminating animation jumps caused by state loss. When synchronizing multiple devices, only the time base value or progress parameter needs to be synchronized; each device can independently calculate completely consistent rendering results based on the same parameters, achieving millisecond-level high-precision synchronization without accumulated errors. When performing state transitions, only the target time parameter needs to be specified, eliminating the need for complex frame number calculations and historical state saving, thus achieving flexible and precise control.

[0033] In some embodiments, the present invention provides a dynamic rendering engine, comprising: a scene mode registration module for registering multiple preset scene modes, each scene mode corresponding to a rendering function; a time management module for maintaining the start time of the color unit of the current animation, the current color unit index, and the animation cycle time; a state machine module for managing the running state of the scene modes, including a stopped state, an initialization state, a running state, a paused state, and a jump state; a rendering scheduling module for calculating the precise position of the animation in the current cycle based on the current system time, and calling the rendering function of the corresponding scene mode to generate static frame rendering data; and a frame buffer module for storing the pixel data of the rendering output.

[0034] In some embodiments, the rendering scheduling module adopts a time-period-based rendering model: it calculates the elapsed time of the current unit based on the current system time; it determines whether the color unit needs to be switched based on the elapsed time of the current unit and the preset unit switching time; and it calls the rendering function based on the current time parameter to generate static frame rendering data corresponding to the current moment.

[0035] In some embodiments, static frame rendering data has the following characteristics: the rendering data for each frame is determined solely by the timestamp of the current moment; given the same time parameter, the rendering function returns the same rendering result whenever it is called; and it does not depend on the historical value of the frame sequence number or frame counter.

[0036] In some embodiments, the time management module is further configured to: maintain the start time of the color unit and update the time each time the color unit is switched; calculate the elapsed time in the current unit based on the difference between the current time and the start time of the color unit; and support external jump instructions to modify the start time of the color unit to achieve accurate restoration of the animation state.

[0037] In some embodiments, the preset scene modes include: windmill mode for rendering a rotating windmill effect; halo mode for rendering a beat halo effect; ray mode for rendering a rotating ray effect; starry sky mode for rendering a sparkling starry sky effect; and kaleidoscope mode for rendering a kaleidoscope effect.

[0038] In some embodiments, the rendering functions of each scene mode adopt a unified interface specification: input parameters include scene state, scene configuration, and rendering progress information; rendering progress information includes the current color unit index and the elapsed time in the current unit; output parameters include rendered pixel data.

[0039] Obviously, the static frame rendering data of the present invention has advantages in the following scenarios: recovery after device restart: only the current time parameter needs to be recorded, and there is no need to save the complete frame data; multi-device synchronization: each device calculates independently according to the same time parameter, and there is no need to transmit the complete frame data; state transition: the target state can be described by the time parameter, and there is no need to save the state before the transition.

[0040] Obviously, compared with the frame-based rendering control method, the time-period-based rendering control method of the present invention has the following advantages: decoupling of rendering result from rendering time: frame data at any time can be calculated independently; support for precise jump at any time: only the time parameter of the target time needs to be provided; high synchronization accuracy: multiple devices can calculate the same rendering result based on the same time parameter.

[0041] In some embodiments, the present invention also provides a method for controlling an intelligent lighting device, comprising the following steps: Step A: Initialize the rendering engine, create a rendering thread, and set the color unit switching time and animation cycle time; Step B: Receive scene mode configuration, including scene mode ID and color configuration; Step C: Initialize by calling the rendering function of the corresponding scene mode based on the scene mode ID; Step D: The rendering thread executes in a loop, obtains the current system time, and calculates the current color unit index and the elapsed time within the unit; Step E: Call the rendering function according to the time parameters to generate static frame rendering data and output it to the frame buffer; Step F: Repeat steps D to E until a stop command is received.

[0042] In some embodiments, step D, which involves calculating the current color cell index and the elapsed time within the cell, includes: Get the current system time nw and the start time of the current color unit clr_start; Calculate the elapsed time for the current cell: elapsed = nw - clr_start; If elapsed is greater than or equal to the preset unit time unit_time, then: clr_start += unit_time, clr_index++; Finally, we obtain the current color cell index and the elapsed time within the current cell.

[0043] In some embodiments, a synchronization jump step is further included: receiving an external synchronization instruction, which includes the target color unit index and the elapsed time within the target unit; calculating the target color unit start time based on the target unit index and the elapsed time within the target unit; updating the color unit start time to the target value and updating the current color unit index to the target index; and generating static rendering data for the corresponding frame based on the new time parameters during the next rendering call.

[0044] In some embodiments, when the rendering thread resumes after a pause, it does not need to rebuild the rendering state: upon resumption, it obtains the current system time; recalculates the color unit index and the elapsed time within the unit based on the current time; and calls the rendering function to generate static frame data corresponding to the current moment.

[0045] In some embodiments, the default value for color unit time is 500 milliseconds.

[0046] In some embodiments, the method further includes a periodic synchronization step: a preset synchronization period; when the synchronization time is reached, the master device sends the current time parameter; each slave device updates the local color unit start time and color unit index according to the received time parameter.

[0047] The following will compare the present invention with the prior art in conjunction with the accompanying drawings, and further describe the specific embodiments of the present invention. The embodiments are merely illustrative and do not mean that the present invention is limited to the following examples.

[0048] I. Limitations of existing traditional frame control methods.

[0049] refer to Figure 1 The existing technology has the following problems.

[0050] 1.1 Problems with traditional frame control methods: Traditional frame control methods use frame counters to drive animation rendering, as shown in the following code: uint16_t frame_counter = 0; void render_loop() { while(1) { render_frame(frame_counter); frame_counter++; sleep(frame_interval); } }

[0051] 1.2 Analysis of Core Issues: Question 1: The rendering result depends on the historical values ​​of the frame counter.

[0052] In traditional frame control, the rendering function "render_frame(frame_counter)" depends on the current value of the frame counter. However, the frame counter is a state variable, and its value depends on: How many times has it been executed since it started? Are there any frame skips or dropped frames in the middle? Is there any other code that modifies the counter?

[0053] If the frame counter malfunctions (such as overflow, improper overflow handling, or being manually reset), the rendering result will also be incorrect. The frame counter itself becomes an implicit dependency of the rendering process.

[0054] Question 2: The device status is lost after restarting.

[0055] This is the most serious problem. The frame counter is stored in memory (RAM) and resets to zero after a power outage or restart. For example... Figure 2 As shown, suppose the animation is playing at frame 500: the animation will suddenly jump back to the first frame, and the user will see a noticeable jump, resulting in a very poor user experience. To solve this problem, an additional state persistence mechanism needs to be designed (such as saving the current frame to Flash), but this increases system complexity and storage overhead.

[0056] Question 3: The synchronization accuracy of multiple devices is limited.

[0057] Assume the master device synchronizes the frame sequence number to the slave device: Master device current frame: 100; From device A's current frame: 99 ← 1 frame difference; From device B's current frame: 98 ← 2 frames difference; Because frame counters are independent, differences in transmission latency can cause discrepancies between the frame counters of slave and master devices. For example, at 20fps, a difference of one frame translates to a 50ms difference. If network jitter causes a slave device to miss synchronization packets for several consecutive frames, the error will accumulate.

[0058] II. Advantages of the static frame rendering data of this invention.

[0059] refer to Figure 3 Using the code for the windmill mode, we will explain the three core advantages of static frame rendering data.

[0060] Advantage 1: The device automatically recovers after restarting without any animation jumps.

[0061] In traditional frame control, the frame counter resets to zero after the rendering thread restarts, and the animation must start again from the first frame, resulting in a noticeable jump.

[0062] In this invention, only two time parameters need to be restored after the rendering thread restarts: color_elapsed_ms = now_ms - color_start_time_ms; For windmill mode, after restarting, if the same (color_unit_index, elapsed_ms) is passed in, windmill_seek_to will immediately calculate the same rotation_angle, and the screen will continue from the interrupted position without any jumps.

[0063] Advantage 2: Millisecond-level synchronization across multiple devices.

[0064] Taking the windmill mode as an example, during synchronization, the master device broadcasts "(color_unit_index, elapsed_ms)", and the slave device, after receiving it, uses its own wall time to calculate "color_start_time_ms". color_start_time_ms = now_ms - compensated_elapsed; All devices obtain the same "(color_unit_index, elapsed_ms)" in the next frame, call "windmill_seek_to" to get the same "rotation_angle", and "windmill_get_colors" outputs the same pixels.

[0065] Even if the transmission delays are different, after compensation by the slave device through poll_delay, the synchronization error is only the transmission delay (about a few milliseconds to tens of milliseconds), which is far better than the "one frame difference = 100ms" of the frame sequence number scheme.

[0066] Advantage 3: The core of the minimal data transmission volume lies in the fact that static frame rendering data uses time parameters (color unit index and elapsed time within the unit) as synchronization information, rather than transmitting complete frame data. In the synchronization implementation of this invention, the synchronization packet sent from the master device to the slave device contains only 5 bytes: packet header (1 byte), color_unit_index (1 byte), elapsed (2 bytes), and CRC checksum (1 byte). Compared to traditional frame control methods that require transmitting complete frame sequence numbers or complete frame data (hundreds of bytes), the synchronization overhead of this invention is extremely small. From the code implementation, the synchronization packet format is head(0xD2) + color_index (1 byte) + elapsed (2 bytes) + crc (1 byte). In the master device's timed synchronization logic, only the current color_unit_index and the elapsed_ms calculated by now_ms - color_start_time_ms are needed to describe the animation state at any given time, resulting in extremely low network bandwidth usage and a significant improvement in synchronization efficiency.

[0067] III. Detailed explanation of the algorithm of the time-period-based rendering model of this invention.

[0068] The following combination Figure 4 The algorithm system block diagram uses the windmill pattern as an example to introduce the specific implementation of the algorithm.

[0069] 3.1 Windmill mode entry function "tbl_scene_show_windmill_mode". The tbl layer calls the entry function for the windmill effect, using the state parameter to distinguish three working stages. OPERATE_RET tbl_scene_show_windmill_mode( SCENE_SHOW_STATE_E state, / / Flags that distinguish the working stage (see explanation below); TBL_SCENE_SHOW_INFO_T *p_info, / / Static configuration (see explanation below); TBL_SCENE_SHOW_SEEK_INFO_T *p_seek, / / Time parameter (only RUNNING / SEE) (not NULL) VOID_T *p_private), / / Reserved, not yet implemented, pass NULL.

[0070] 3.2 Parameter Details: For details, please refer to the following: Figures 5 to 7 , where state is the instruction passed from the tbl layer to the rendering function, telling it what to do at the moment; where "p_info" is the static configuration of the scene show, which is passed in once during initialization and does not change during operation; p_seek is a time parameter, which is calculated by the tbl layer every frame based on the system runtime.

[0071] 3.3 windmill_seek_to: Calculates the position of the windmill based on the time parameter.

[0072] The tbl layer calls this function during the START / RUNNING / SEEK states to update the internal state of the windmill module based on time parameters. This function does not output any pixels; it only updates two internal variables.

[0073] Function prototype: void windmill_seek_to(uint8_t color_unit_index, uint32_t elapsed_ms) Parameter details reference Figure 8; The internal state reference updated after function execution Figure 9 ; The internal calculation formula is as follows ("windmill_apply_state"): / / Step 1: Convert elapsed_ms to the fan blade angle within the cell; / / fps=20, cycle_time=2000ms, then rotation_speed = 90 degrees / (2000*20 / 1000) = 4.5 degrees / frame; float angle_in_unit = (elapsed_ms * fps / 1000.0f) * rotation_speed; / / Step 2: Cumulative angle = Number of complete units * 90 degrees + Angle within the unit; g_windmill.rotation_angle = color_unit_index * 90.0f + angle_in_unit; / / Step 3: Current color index = Current cell number % Total number of colors; g_windmill.current_color_index = color_unit_index % color_count; For example: When you input "color_unit_index=2, elapsed_ms=300ms" (assuming fps=20); angle_in_unit = (300 * 20 / 1000) * 4.5 = 27° (rotated 27° within the unit); rotation_angle = 2 * 90 + 27 = 207° (a total of 207° rotation); current_color_index = 2 % 4 = 2 (Currently displayed color is 2).

[0074] 3.4 windmill_get_colors: Calculates the color of each LED based on the windmill's position.

[0075] The tbl layer calls this function when in the RUNNING state. Its function is to traverse each LED in the device area according to the current internal state of the windmill and fill the corresponding color value into the output buffer.

[0076] Function prototype: int windmill_get_colors(int x, int y, int width, int height, USHORT_T *out_buffer); for detailed explanation of its parameters, please refer to [link / reference]. Figure 10 .

[0077] "width" and "height" together determine the shape of the device; see reference for details. Figure 11 .

[0078] Iteration: Call windmill_get_color_at for each LED; For each LED in the area, the internal function "windmill_get_color_at(x, y, &rgbcw)" is called. This function determines the color of the LED based on the current internal state of the windmill, "g_windmill.rotation_angle" and "g_windmill.current_color_index".

[0079] The core logic of `windmill_get_color_at` is shown in the following code: int windmill_get_color_at(int x, int y, LIGHT_RGBCW_T *rgbcw) { / / Step 1: Calculate the angle of the LED beads relative to the center point on the canvas float dx = x - (canvas_width / 2); float dy = y - (canvas_height / 2); float point_angle = atan2(-dy, dx) * 180.0f / PI; / / Clockwise 0-360° / / Step 2: Map to the 0-90° range (the windmill cycles once every 90°). float local_angle = fmod(point_angle, 90.0f); / / Step 3: What angle is the current fan blade sweeping at (also within the range of 0-90°)? float sweep_angle = fmod(g_windmill.rotation_angle, 90.0f); / / Step 4: Compare and decide what color to display if (local_angle <= sweep_angle) { / / The fan blade has swept over this LED bead → Display the current animation color rgbcw = colors[g_windmill.current_color_index]; } else { / / The fan blades did not reach this LED bead → Show background color rgbcw = bg_color; } }

[0080] For example: "rotation_angle=207°" → "sweep_angle=27°" (207° % 90° = 27°); LED A's angle on the canvas = 30° → "local_angle=30°" → 30°>27° → Display background color; LED B's angle on the canvas = 15° → "local_angle=15°" → 15°≤27° → Display animation color (color 2).

[0081] 3.4 The overall calling relationship of the three functions can be found in the reference. Figure 12 .

[0082] 3.5 How to synchronize master and slave devices using windmill_seek_to.

[0083] Synchronization package format reference Figure 13 The master device sends a 5-byte synchronization packet to the slave device, with the core data including two parts: "color_unit_index" and "color_elapsed_ms".

[0084] The slave device does not need to know the master device's time. Each device's "wall time" is independent; the master device's 960ms and the slave device's 970ms are unrelated. The slave device only needs the "elapsed_ms" in the synchronization packet and the "seek_received_ms" (the time it recorded itself when it received the packet).

[0085] When the master device sends data to the slave device, network latency compensation has already been added in advance: slave_elapsed = color_elapsed_ms + SCENE_SHOW_SYNC_NET_LATENCY_MS; Assuming the master device currently has elapsed=460 and the estimated network latency is 200ms, then the slave device will receive slave_elapsed=460+200=660.

[0086] Once the device receives the packet, it can directly calculate the correct color_start using "now_ms - slave_elapsed" without needing to compensate for the transmission delay.

[0087] The equipment also needs to compensate for the delay between "receiving and processing" (poll_delay): poll_delay_ms = now_ms - seek_received_ms; / / 5ms; compensated_elapsed = elapsed_from_master + poll_delay_ms; color_start_time_ms = now_ms - compensated_elapsed; For a detailed timing diagram of the synchronization process, please refer to [reference needed]. Figure 14 .

[0088] IV. The comparison between the traditional frame control method and the control method of this invention is as follows.

[0089] V. The engine architecture of this invention is as follows.

[0090] refer to Figure 15 The engine architecture of this invention includes: APP layer: Users send control commands (play / pause / stop) through the APP / cloud, triggering the master and slave devices to start the rendering thread; Both the master and slave devices run the same rendering thread and execute tbl_scene_show_xxx_mode(RUNNING) to render each frame. Master device unique: The timer automatically calls tbl_scene_show_get_sync_info() every hour to get the current status and sends a 5-byte synchronization packet to the slave device; Device-specific: After receiving a synchronization packet, record the packet reception time seek_received_ms and set the resync_pending=1 flag; TBL rendering thread common logic: All devices share the same set of rendering logic - when resync_pending=1 is detected, SEEK synchronous jump is executed (only the status is updated and no output is performed), otherwise elapsed is calculated normally and rendered.

[0091] The detailed work process is described below: I. System Startup Process: 1. Configuration is distributed via APP / cloud. Users can select scene displays (such as "windmill mode") in the APP. The cloud will distribute the configuration to the master device and all slave devices; Configuration options include: mode ID, color, speed, canvas size, etc.

[0092] 2. Playback commands are sent from the APP / cloud.

[0093] The APP calls app_light_scene_show_dev_ctrl(1) to send the "play" command; After receiving the command, the master and slave devices call tbl_scene_show_start(); 3. Initialization phase.

[0094] Call the INIT state of the pattern function to initialize the internal state of the pattern; Create a rendering thread __scene_show_thread_func().

[0095] II. Rendering thread main loop: After the rendering thread starts, it enters the while(1) main loop and executes it every frame: 1. Get the thread state (thread_state).

[0096] STOP: Initialize the timer and switch to START; PAUSE: Continue after 100ms of sleep; RUNNING: Perform rendering.

[0097] 2. Handle synchronization requests (resync_pending).

[0098] This flag is set after the device receives the master device synchronization packet; Once the rendering thread detects this, it executes a SEEK jump (only updating the status, without outputting anything).

[0099] 3. Calculate the elapsed_ms of the current frame.

[0100] elapsed_ms = now_ms - color_start_time_ms.

[0101] 4. Check if the color unit needs to be switched.

[0102] if (elapsed_ms >= unit_time_ms) { color_start_time_ms += unit_time_ms; / / Incremental acceleration; cur_color_unit_index = (cur_color_unit_index + 1) % color_count; }

[0103] 5. Call the mode function to render.

[0104] tbl_scene_show_xxx_mode(RUNNING, &scene_info, &seek_info, NULL).

[0105] 6. Sleep until the next frame.

[0106] tal_system_sleep(frame_period_ms).

[0107] III. Master Equipment Synchronization Packet Sending Process.

[0108] 1. Timer trigger: Triggered once every 1 hour (SCENE_SHOW_SYNC_INTERVAL_MS = 3600000ms).

[0109] 2. Get the current state.

[0110] tbl_scene_show_get_sync_info(&color_unit_index, &color_elapsed_ms); Read the current color unit index from sg_scene_show.sync_info; Use now_ms - cur_color_start_ms to calculate the elapsed time in the current cell.

[0111] 3. Add network latency pre-compensation.

[0112] slave_elapsed = color_elapsed_ms + SCENE_SHOW_SYNC_NET_LATENCY_MS; / / +200ms; It was anticipated that the master device would take an extra 200ms to process the packet received from the device, so this was added in advance.

[0113] 4. Send synchronization packet.

[0114] scene_show_sync_pkg_send(color_unit_index, slave_elapsed); Synchronization packet format: head(1) + color_unit_index(1) + elapsed(2) + crc(1) = 5 bytes.

[0115] 5. The main device itself also performs SEEK.

[0116] tbl_scene_show_force_resync(color_unit_index, color_elapsed_ms); Eliminate the accumulated errors generated during its own operation.

[0117] IV. Device Synchronization Reception Process.

[0118] 1. Received synchronization package Call tbl_scene_show_force_resync(color_unit_index, elapsed_from_master); Record packet reception time: seek_received_ms = tal_system_get_millisecond(); Set the synchronization flag: resync_pending = 1.

[0119] 2. Synchronization of rendering thread processing.

[0120] Reading `resync_pending`, we find it equals 1. Calculate poll_delay: poll_delay = now_ms - seek_received_ms; Calculate the compensated elapsed: compensated = elapsed_from_master + poll_delay; Reverse color_start: color_start = now_ms - compensated; Call the mode function SEEK state: tbl_scene_show_xxx_mode(SEEK, ...); Clear the flag: resync_pending = 0.

[0121] V. Guarantee rendering consistency between master and slave devices.

[0122] The key lies in the "system time + incremental advancement" mechanism: 1. Main equipment maintenance: cur_color_start_ms: The start system time of the current color unit; cur_color_unit_index: The index of the current color unit.

[0123] 2. After receiving the synchronization packet from the device, the following formula is used to deduce: color_start = now_ms - compensated_elapsed; Get the same color_start as the master device.

[0124] 3. When rendering the next frame, both devices will use: elapsed = now_ms - color_start; The calculations yielded the same elapsed value, and the same mode function is called to produce the same pixel output.

[0125] 4. Sources of error: Network transmission latency (~200ms, already compensated); poll_delay (the delay from packet reception to processing, already compensated); The final error can be controlled within tens of milliseconds.

[0126] Obviously, the innovative contributions of this invention to the prior art include, but are not limited to: 1. Static frame rendering data: The rendering data for each frame is determined by the timestamp of the current moment, and is independent of the rendering time.

[0127] 2. Time-based rendering model: Calculates the position of the animation in the cycle based on the current system time, rather than relying on a frame counter.

[0128] 3. Time-driven state maintenance: Color unit switching is time-driven, and the switching time is recorded for each switch.

[0129] In summary, compared with the prior art, the present invention has the following beneficial effects: 1. Decoupling of rendering results from time: Static frame rendering data allows frames at any given time to be calculated independently.

[0130] 2. Supports precise jump at any time: Only the time parameter of the target time needs to be provided, and there is no need to save the state before the jump.

[0131] 3. Millisecond-level synchronization accuracy: Multiple devices can independently calculate based on the same time parameters without transmitting complete frame data.

[0132] 4. Automatic recovery upon thread restart: Automatically restores the correct animation state based on the current time.

[0133] Highly scalable: New scene modes only require the implementation of a rendering function based on time parameters.

[0134] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-RM, optical storage, etc.) containing computer-usable program code.

[0135] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0136] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0137] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0138] The background section of this invention may include background information about the problems or environment in which the invention is being developed, and is not necessarily a description of prior art. Therefore, the content included in the background section does not constitute an admission of prior art by the applicant.

[0139] The above description provides a further detailed explanation of the present invention in conjunction with specific / preferred embodiments, and it should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various substitutions or modifications can be made to these described embodiments without departing from the concept of the present invention, and all such substitutions or modifications should be considered within the scope of protection of the present invention. In the description of this specification, the reference to terms such as "an embodiment," "some embodiments," "preferred embodiment," "example," "specific example," or "some examples," etc., indicates that the specific features, structures, materials, or characteristics described in connection with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples. Although the embodiments of the present invention and their advantages have been described in detail, it should be understood that various changes, substitutions, and modifications can be made herein without departing from the scope of protection of the patent application.

Claims

1. A dynamic rendering engine, characterized in that, include: The scene mode registration module is used to register one or more scene modes, and each scene mode corresponds to a scene rendering function. A time management module is used to maintain a time base value and to update the time base value; The rendering scheduling module is used to calculate the progress parameters representing the animation process based on the current system time and the time base value, and to call the target scene rendering function to input the progress parameters into the function. A frame buffer module is used to store rendering data generated by the scene rendering function in response to the progress parameter; The scene rendering function is configured to output the same rendering data for the same progress parameters.

2. The dynamic rendering engine as described in claim 1, characterized in that, The dynamic rendering engine further includes a state machine module for managing the running state of the dynamic rendering engine; the running state includes at least one of the following: stopped state, initialization state, running state, paused state, and jump state.

3. The dynamic rendering engine as described in claim 1, characterized in that, The time management module is also used to maintain a color unit time, which is a preset duration of a color unit; the progress parameter consists of the current color unit index and the elapsed time within the current color unit; the rendering scheduling module calculates the progress parameter, including: calculating the elapsed time within the current color unit based on the difference between the current system time and the time base value; and determining the current color unit index based on the elapsed time within the current color unit and the color unit time.

4. The dynamic rendering engine as described in claim 3, characterized in that, The time base value maintained by the time management module is the start time of the current color unit; the rendering scheduling module calculates the elapsed time in the current color unit based on the difference between the current system time and the start time of the current color unit; when the elapsed time in the current color unit is greater than or equal to the color unit time, the start time is updated and the index of the current color unit is adjusted.

5. The dynamic rendering engine as described in claim 4, characterized in that, The time management module updates the time base value by: responding to an external jump instruction or synchronization instruction, the external instruction carrying a target color unit index and the elapsed time within the target color unit; the time management module calculates the start time of the target color unit based on the target color unit index, the elapsed time within the target color unit, and the color unit time, and updates the time base value to the start time of the target color unit.

6. A method for controlling intelligent lighting equipment, characterized in that, include: Register one or more scene modes, each scene mode corresponding to a scene rendering function; Maintain a time reference value; Based on the current system time and the time base value, the progress parameters representing the animation process are calculated; The target scene rendering function is invoked, and the progress parameter is input into the function to obtain rendering data; wherein, the scene rendering function is configured to output the same rendering data for the same progress parameter; The intelligent lighting equipment is controlled based on the rendered data.

7. The intelligent lighting device control method as described in claim 6, characterized in that, The intelligent lighting device control method further includes: managing the operating state of the intelligent lighting device control method; the operating state includes at least one of the following: stop state, initialization state, running state, paused state, and jump state.

8. The intelligent lighting device control method as described in claim 6, characterized in that, The intelligent lighting device control method further includes maintaining a color unit time, wherein the color unit time is a preset duration of a color unit; the progress parameter consists of the current color unit index and the elapsed time within the current color unit; the calculation of the progress parameter includes: calculating the elapsed time within the current color unit based on the difference between the current system time and the time reference value; and determining the current color unit index based on the elapsed time within the current color unit and the color unit time.

9. The intelligent lighting device control method as described in claim 8, characterized in that, The time base value is the start time of the current color unit; the calculation of the elapsed time in the current color unit is to calculate the difference between the current system time and the start time; when the elapsed time in the current color unit is greater than or equal to the color unit time, the start time is updated and the index of the current color unit is adjusted.

10. The intelligent lighting device control method as described in claim 9, characterized in that, The intelligent lighting device control method further includes the step of updating the time reference value: receiving an external jump instruction or synchronization instruction, the instruction carrying a target color unit index and the elapsed time within the target color unit; calculating the start time of the target color unit based on the target color unit index, the elapsed time within the target color unit, and the color unit time; and updating the maintained time reference value to the start time of the target color unit.

Images