Rendering method, device and vehicle

Abstract

The application provides a rendering method, device and vehicle; the method comprises the following steps: obtaining a real-time driving state of a vehicle and at least one to-be-rendered task; the to-be-rendered task has a corresponding safety semantic level, and the safety semantic level represents an influence degree of the to-be-rendered task on driving safety of the vehicle; determining a rendering parameter of each to-be-rendered task based on the real-time driving state and the safety semantic level corresponding to each to-be-rendered task; and rendering each to-be-rendered task based on the rendering parameter of each to-be-rendered task. By introducing the safety semantic level representing the influence degree of the to-be-rendered task on the driving safety and dynamically determining the rendering parameter in combination with the real-time driving state of the vehicle, the rendering strategy can be dynamically adjusted according to the change of the driving scene, the differentiated rendering resource allocation driven by the driving safety semantic is realized, and the rendering performance of the vehicle-mounted computing platform is optimized.

Description

Technical Field

[0001] This application relates to vehicle technology, and more particularly to a rendering method, device, and vehicle. Background Technology

[0002] With the development of intelligent vehicle cockpits, in-vehicle 3D rendering applications are becoming increasingly diverse. However, in-vehicle computing platforms have limited hardware resources. Traditional rendering methods mostly rely on pre-set fixed strategies, which are insufficient to handle the dynamic and complex scenes and real-time performance requirements of in-vehicle applications, leading to unreasonable allocation of rendering resources. Summary of the Invention

[0003] This application provides a rendering method, device, and vehicle that can dynamically adjust the rendering strategy according to changes in the driving scenario, realize differentiated rendering resource allocation driven by driving safety semantics, and optimize the rendering performance of the vehicle computing platform.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a rendering method, the method comprising: The system acquires the real-time driving status of the vehicle and at least one task to be rendered; the task to be rendered has a corresponding safety semantic level, which characterizes the degree of impact of the task to be rendered on the driving safety of the vehicle. Based on the real-time driving status and the security semantic level corresponding to each of the tasks to be rendered, the rendering parameters of each task to be rendered are determined. Render each of the tasks to be rendered based on its rendering parameters.

[0005] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the rendering method provided in the embodiments of this application.

[0006] This application provides a vehicle, which includes the electronic equipment provided in this application.

[0007] The embodiments of this application have the following beneficial effects: By acquiring the vehicle's real-time driving status and at least one task to be rendered with a safety semantic level, which characterizes the degree of impact of the task on driving safety, rendering parameters for each task are determined based on the real-time driving status and the safety semantic level. Rendering is then performed on each task based on these parameters. In this way, driving safety semantics are used as one of the bases for allocating rendering resources, and rendering parameters are dynamically determined in conjunction with the vehicle's current driving status. This allows the allocation of rendering resources to adapt to changes in the driving scenario, effectively overcoming the shortcomings of traditional methods in handling dynamic and complex scenarios. Furthermore, it achieves differentiated rendering resource allocation driven by driving safety semantics, optimizing the rendering performance of the onboard computing platform under limited hardware resources. Attached Figure Description

[0008] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application. Obviously, the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0009] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0010] Figure 1 This is one of the flowcharts illustrating a rendering method provided in an embodiment of this application; Figure 2 This is a second schematic flowchart of a rendering method provided in an embodiment of this application; Figure 3 This is the third flowchart illustrating a rendering method provided in an embodiment of this application; Figure 4 This is a schematic diagram of an in-vehicle rendering system architecture provided in an embodiment of this application; Figure 5 This is a schematic diagram of the rendering process of an in-vehicle rendering system architecture provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a rendering device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of this application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0013] In the following description, references to "some embodiments," "this embodiment," "this application embodiment," and examples, etc., describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments and may be combined with each other without conflict.

[0014] The terms "first," "second," and "third" appearing in the embodiments of this application do not have a specific meaning (e.g., there is no order, nor does it indicate a special limitation on the number of devices in the embodiments of this application), but are merely for the purpose of clearly describing the embodiments of this application and do not constitute any limitation on the embodiments of this application. The term "multiple" appearing in the embodiments of this application refers to two or more integers.

[0015] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies or terms of the embodiments of this application are described below. The following related technologies or related terms are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0016] With the rapid development of automotive intelligence and connectivity, intelligent cockpits have become a core component of modern automobiles. Users have increasingly higher demands for the in-vehicle infotainment (IVI) experience, especially for immersive, high-fidelity 3D human-machine interface (HMI). Unity3D, as a powerful real-time 3D content creation engine, is widely used in the development of automotive HMIs due to its cross-platform capabilities, rich development ecosystem, and excellent rendering effects.

[0017] However, the inventors of this application discovered during their research and analysis that in-vehicle computing platforms typically face the challenge of relatively limited hardware resources (such as Central Processing Unit (CPU), Graphics Processing Unit (GPU), and memory). When running complex Unity3D applications, such as high-precision maps, 3D navigation, virtual assistants, or immersive games, the rendering load on the GPU can increase dramatically, leading to unstable frame rates, stuttering, and severely impacting the user experience. Traditional rendering optimization methods, such as Static Batch Batching (SBB) and Level of Detail (LOD), while effectively reducing some rendering pressure, are often static or semi-static and struggle to cope with the dynamically changing complex scenes and real-time performance requirements of in-vehicle applications.

[0018] To address at least one of the aforementioned problems in the related technologies, embodiments of this application provide a rendering method that can dynamically adjust the rendering strategy according to changes in the driving scenario, realize differentiated rendering resource allocation driven by driving safety semantics, and optimize the rendering performance of the in-vehicle computing platform.

[0019] The rendering method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0020] Figure 1 This is one of the flowcharts illustrating a rendering method provided in an embodiment of this application; as shown... Figure 1 As shown, the method may include the following steps 101 to 103: Step 101: Obtain the real-time driving status of the vehicle and at least one task to be rendered; the task to be rendered has a corresponding safety semantic level, and the safety semantic level characterizes the degree of influence of the task to be rendered on the driving safety of the vehicle.

[0021] In some embodiments, obtaining the real-time driving status of the vehicle can be achieved by acquiring vehicle controller area network (CAN) data in real time through the CAN bus interface and standardizing it into parameters recognizable by the 3D rendering engine. This real-time driving status may include, but is not limited to, at least one of the following parameters: vehicle speed, gear position, steering angle, turn signal status, brake pressure, and Advanced Driver Assistance Systems (ADAS) warning signals. Specifically, vehicle speed reflects the dynamic level of the current driving; gear position determines whether the vehicle is stationary, reversing, or moving; turn signal status and steering angle reflect the driver's steering intention; brake pressure reflects the driver's braking intention; and ADAS warning signals determine the presence of an emergency.

[0022] It should be noted that the task to be rendered refers to the graphical content to be rendered in the 3D rendering engine, which may include, but is not limited to, dashboard UI elements, 3D navigation maps, Augmented Reality Head-Up Display (AR-HUD) overlay information, virtual assistant models, multimedia player interfaces, etc. Each task to be rendered is pre-marked with a corresponding safety semantic level, which is used to characterize the degree of impact or importance of the task to be rendered on driving safety.

[0023] In some embodiments, rendering tasks can be semantically tagged using Unity3D engine's GameObject.tag or Layer. For the same type of rendering task, the security semantic level can be pre-defined uniformly.

[0024] In some embodiments, the safety semantic levels, ranked from highest to lowest impact on driving safety, can include at least the Safety-Critical level, Driving-Assist level, Interaction-Enhanced level, and Infotainment level. The Safety-Critical level corresponds to UI elements and 3D models with specific layers in Unity3D that are directly related to driving safety. These elements are typically driven directly by the vehicle's safety system, have their rendering priority set to the highest at the engine level, and may be bound to independent rendering queues to ensure they are not blocked by other rendering tasks. Examples include speedometers and malfunction warning lights. The Driving-Assist level corresponds to 3D models of navigation maps, overlay information from AR-HUDs, and real-time environmental perception rendering of Automatic Parking Assist (APA). The Interaction-Enhanced level corresponds to virtual assistant models and dynamic effects on the air conditioning control panel. The Infotainment level corresponds to multimedia player interfaces, 3D desktop backgrounds, and animations. The Interaction-Enhanced and Infotainment levels have relatively little impact on driving safety.

[0025] Step 102: Based on the real-time driving status and the security semantic level corresponding to each of the tasks to be rendered, determine the rendering parameters of each task to be rendered.

[0026] It should be noted that rendering parameters are key factors that determine rendering quality, and may include, but are not limited to, at least one of resolution, particle count, and frame rate.

[0027] In some embodiments, the safety semantic level can be used to determine the baseline priority or baseline rendering quality of each task to be rendered, and the real-time driving status can be used to dynamically adjust the baseline. For example, the higher the safety semantic level of a task to be rendered, the higher its corresponding rendering priority or baseline rendering quality; based on this, the baseline rendering quality or priority of each safety semantic level is dynamically adjusted according to changes in the real-time driving status, thereby determining the final rendering parameters.

[0028] In some embodiments, the initial rendering parameters of each task to be rendered can be determined based on the security semantic level corresponding to each task to be rendered, and then the initial rendering parameters can be adjusted in combination with the real-time driving status of the vehicle to obtain the final rendering parameters of each task to be rendered.

[0029] Step 103: Render each of the tasks to be rendered based on the rendering parameters of each task.

[0030] In some embodiments, the rendering parameters of each task to be rendered can be determined in step 102, and the rendering interface of the rendering engine can be called to render each task to be rendered and generate a rendered image.

[0031] In some embodiments, the rendering parameters of each task to be rendered can be configured into the corresponding rendering task, and the rendering pipeline can be executed by the 3D rendering engine to output the rendering results to the vehicle display device for display.

[0032] In this embodiment, the real-time driving status of the vehicle and at least one task to be rendered with a safety semantic level are obtained. This safety semantic level characterizes the degree of impact of the task on driving safety. Based on this, rendering parameters for each task are determined jointly based on the real-time driving status and the safety semantic level, and each task is rendered based on these parameters. Thus, by using driving safety semantics as one of the bases for allocating rendering resources and dynamically determining rendering parameters in conjunction with the vehicle's current driving status, the allocation of rendering resources can adapt to changes in the driving scenario. This effectively overcomes the shortcomings of traditional methods in dealing with dynamic and complex scenarios, and achieves differentiated rendering resource allocation driven by driving safety semantics, optimizing the rendering performance of the onboard computing platform under limited hardware resources.

[0033] In some embodiments, such as Figure 2 As shown, step 102 may further include steps 1021 to 1023: Step 1021: Based on the security semantic level corresponding to each of the tasks to be rendered, determine the first rendering weight corresponding to each of the security semantic levels; the security semantic level and the first rendering weight are positively correlated.

[0034] It should be noted that in this embodiment, the safety semantic level is positively correlated with the first rendering weight; that is, the higher the safety semantic level (i.e., the greater its impact on driving safety), the greater its corresponding first rendering weight. The first rendering weight can be a numerical value used to quantify the baseline rendering priority or baseline rendering quality of each safety semantic level.

[0035] In some embodiments, a baseline weight value (i.e., a first rendering weight) can be pre-set for each security semantic level. The higher the security semantic level, the larger the baseline weight value. For example, the first rendering weight corresponding to the security core level is 100, the first rendering weight corresponding to the driving assistance level is 80, the first rendering weight corresponding to the interaction enhancement level is 50, and the first rendering weight corresponding to the entertainment and leisure level is 20.

[0036] It should be noted that the first rendering weight can be predetermined based on the security semantic level of each task to be rendered during system initialization, or it can be dynamically determined at the start of each frame rendering.

[0037] Step 1022: Based on the real-time driving status, adjust the first rendering weights corresponding to each of the safety semantic levels to obtain the second rendering weights corresponding to each of the safety semantic levels.

[0038] It is understood that in this embodiment of the application, the second rendering weight is obtained by incorporating the real-time status of the vehicle based on the first rendering weight.

[0039] In some embodiments, different degrees of gain or penalty can be applied to the first rendering weights corresponding to different safety semantic levels according to different driving states. For example, when the real-time driving state indicates an increased driving risk (e.g., vehicle speed exceeds a preset threshold, ADAS warning is triggered, etc.), the first rendering weight corresponding to the higher safety semantic level can be increased, and the first rendering weight corresponding to the lower safety semantic level can be decreased; when the real-time driving state indicates a decreased driving risk (e.g., vehicle speed decreases below a preset threshold, vehicle is stationary, etc.), the first rendering weight corresponding to the higher safety semantic level can be decreased, and the first rendering weight corresponding to the lower safety semantic level can be increased.

[0040] In some embodiments, it can be done through formula Calculate the second rendering weight, where As the first rendering weight, For vehicle state coefficients, These are preset weighting coefficients. The value can be dynamically determined based on the current driving status of the vehicle. For example, under high-speed driving conditions, the values ​​corresponding to the safety core level and the driver assistance level are... For positive values ​​(e.g., +0.8 to +1.0), the corresponding entertainment / leisure level is... Negative values ​​(e.g., -0.8 to -1.0); In stationary or Park mode, the corresponding entertainment / leisure level... For positive values ​​(e.g., +0.5 to +0.8), the corresponding values ​​for Safety Core Level and Driver Assistance Level are... The value is 0; under ADAS warning trigger state, the corresponding safety core level It is +1.5, and the corresponding values ​​for other levels are... It is -1.0.

[0041] In some embodiments, the driver assistance level can be boosted based on the reversing status. When the gear is in reverse (R), the first rendering weight corresponding to the driver assistance level can be increased to ensure the clarity and real-time performance of the environmental perception rendering of parking assistance systems such as APA.

[0042] Step 1023: Determine the rendering parameters of each of the tasks to be rendered based on the second rendering weight corresponding to the security semantic level to which each task belongs.

[0043] It should be noted that, in the embodiments of this application, different tasks to be rendered that belong to the same security semantic level share the same second rendering weight. The level of the second rendering weight represents the rendering priority of the corresponding task to be rendered. The higher the second rendering weight, the higher the rendering priority of the corresponding task to be rendered, and the higher the priority guarantee it receives in the allocation of rendering resources; the lower the second rendering weight, the lower the rendering priority of the corresponding task to be rendered, and the lower its rendering quality is preferentially reduced when rendering resources are scarce.

[0044] In this embodiment of the application, when determining rendering parameters, different rendering parameters can be assigned to rendering tasks with different security semantic levels based on the rendering priority represented by the second rendering weight. Specifically, the higher the second rendering weight, the better the rendering parameters obtained by the corresponding rendering task (such as higher resolution, higher level of detail, and enabling post-processing effects); the lower the second rendering weight, the more conservative the rendering parameters obtained by the corresponding rendering task (such as lower resolution, lower level of detail, and cropping post-processing effects).

[0045] It is understood that this application embodiment determines the first rendering weight corresponding to each security semantic level based on the security semantic level of each task to be rendered, and establishes a positive correlation between the security semantic level and the first rendering weight, so that the task to be rendered with a higher security semantic level receives a higher first rendering weight. On this basis, the first rendering weight is further dynamically adjusted according to the real-time driving status of the vehicle to obtain a second rendering weight. In this way, the determination of rendering weight not only considers the impact of the task to be rendered on driving safety, but also incorporates the current real-time driving environment of the vehicle, so that the task to be rendered with a high security semantic level can obtain a higher rendering weight when the driving risk is high, and the task to be rendered with a low security semantic level can obtain a lower rendering weight when the driving risk is low. This realizes the dynamic adaptive adjustment of rendering priority according to the driving scenario, and provides a more reasonable basis for determining rendering parameters.

[0046] In some embodiments, adjusting the first rendering weights corresponding to each of the safety semantic levels based on the real-time driving state includes: When the real-time driving status indicates an increased driving risk for the vehicle, the first rendering weight corresponding to the first safety semantic level is increased, and the first rendering weight corresponding to the second safety semantic level is decreased; the first safety semantic level is greater than the second safety semantic level. When the real-time driving status indicates a reduction in the driving risk of the vehicle, the first rendering weight corresponding to the first safety semantic level is reduced, and the first rendering weight corresponding to the second safety semantic level is increased.

[0047] It should be noted that increased driving risk refers to an increase in the level of safety risk in the current driving environment of the vehicle, which may include, but is not limited to, the following situations: vehicle speed exceeding a preset threshold (such as 80km / h), ADAS warning signals being triggered (such as lane departure warning, forward collision warning), braking pressure exceeding a preset threshold, etc.; decreased driving risk refers to a decrease in the level of safety risk in the driving environment, which may include, but is not limited to, vehicle speed decreasing to below a preset threshold, vehicle gear shifting to P or N, vehicle approaching a standstill, etc.

[0048] It should be noted that the first safety semantic level and the second safety semantic level represent two different safety semantic levels, with the first safety semantic level being higher than the second safety semantic level, meaning that the first safety semantic level has a greater impact on driving safety.

[0049] In this embodiment, when driving risk increases, the first rendering weight corresponding to the high safety semantic level (i.e., the first safety semantic level) is increased and the first rendering weight corresponding to the low safety semantic level (i.e., the second safety semantic level) is decreased, so that the rendering quality and resources of the high safety semantic level rendering task are more fully guaranteed; when driving risk decreases, the first rendering weight corresponding to the high safety semantic level is decreased and the first rendering weight corresponding to the low safety semantic level is increased, so that the rendering resources of the high safety semantic level rendering task are released to improve the rendering quality of the low safety level rendering task.

[0050] It should be noted that the terms "increase" and "decrease" in this embodiment are relative. That is, under the same driving condition, the first rendering weights of different safety semantic levels are adjusted in opposite directions to dynamically adjust the difference in first rendering weights between different safety semantic levels. For example, when driving risk increases, the first rendering weight of the high safety semantic level increases while the first rendering weight of the low safety semantic level decreases, thereby widening the gap between the two and further emphasizing the priority of the high safety semantic level rendering task. Conversely, when driving risk decreases, the first rendering weight of the high safety semantic level decreases while the first rendering weight of the low safety semantic level increases, thereby narrowing the gap between the two and appropriately improving the rendering quality of the low safety level rendering task.

[0051] In some embodiments, when an ADAS warning signal is triggered, the first rendering weight of the safety core level can be increased to the highest value, while the first rendering weights of other safety semantic levels can be decreased to the lowest value or suspended to ensure zero-latency rendering and maximum clarity of safety warning information. In reversing mode, the first rendering weight of the driver assistance level can be increased to ensure the real-time performance and clarity of the environmental perception rendering of parking assistance systems such as APA.

[0052] In some embodiments, the magnitude of increase or decrease when driving risk increases, and the magnitude of decrease or increase when driving risk decreases, can be dynamically determined based on real-time status parameters such as vehicle speed and ADAS warning level, or can be adjusted using a preset fixed step size. This application does not specifically limit this.

[0053] It is understood that, in this embodiment, when driving risk increases, the first rendering weight corresponding to the high safety semantic level is increased while the first rendering weight corresponding to the low safety semantic level is decreased, thus ensuring more adequate rendering quality and resources for tasks with high safety semantic levels. Conversely, when driving risk decreases, the first rendering weight corresponding to the high safety semantic level is decreased while the first rendering weight corresponding to the low safety semantic level is increased, thereby freeing up rendering resources for tasks with high safety semantic levels to improve the rendering quality of tasks with low safety levels. This achieves a dynamic balance of rendering weights between safety semantic levels, ensuring sufficient rendering quality for tasks with high safety semantic levels in risky scenarios while reasonably improving the rendering quality of tasks with low safety semantic levels in safe scenarios, thereby enhancing the overall utilization efficiency of rendering resources.

[0054] In some embodiments, determining the rendering parameters of each of the tasks to be rendered based on the second rendering weight corresponding to the security semantic level to which each task belongs includes: Acquire driving intent information and / or user interaction information; the driving intent information is used to indicate driving operation events that will occur within a preset time period in the future; the user interaction information is used to indicate the user's interactive operations on the target task to be rendered. Based on the driving intention information and / or user interaction information, the second rendering weight is adjusted to obtain the third rendering weight; Based on the third rendering weight, the rendering parameters for each of the tasks to be rendered are determined.

[0055] It's important to note that driving intent information indicates upcoming driving events within a preset future timeframe. This information reflects the driving actions the driver might perform within that timeframe, such as turning, passing through intersections, or entering sharp curves. User interaction information indicates user interactions with a target task to be rendered. This information reflects which task the user is currently interacting with, such as touching a UI control or activating a voice assistant. The preset future timeframe refers to a pre-defined time window starting from the current moment. Its specific duration can be set according to the actual application scenario, such as 5 seconds or 10 seconds, or dynamically determined based on the current vehicle speed and distance to the driving event trigger point. For example, when navigation indicates a turn is needed 500 meters ahead, the time required to reach that location is calculated based on the current vehicle speed, and a certain percentage (e.g., 20%-30%) of that time is used as the preset timeframe to enable advance response to upcoming driving events.

[0056] In some embodiments, path planning information from a navigation system can be obtained, and then driving operation events that will occur within a preset time period can be predicted based on this path planning information, generating corresponding driving intention information. For example, when the navigation system indicates that there is a sharp bend or complex intersection 500 meters ahead, the upcoming driving operation event can be predicted, and corresponding driving intention information can be generated. The third rendering weight can be obtained by increasing the second rendering weight, which has a preset correspondence with the safety semantic level of the driving operation event.

[0057] In some embodiments, user interactions with the in-vehicle display interface can be detected, including but not limited to touch operations, voice interactions, and continuous interactions, and corresponding user interaction information can be generated. For example, when a user touches the navigation map interface, user interaction information for the task to be rendered corresponding to the navigation map can be generated. The third rendering weight can be obtained by increasing the second rendering weight based on the second rendering weight, by increasing the second rendering weight of the safety semantic level to which the target task to be rendered belongs.

[0058] It should be noted that, in this embodiment of the application, driving intent information and user interaction information can be acquired selectively, or simultaneously. When acquired simultaneously, the second rendering weight can be adjusted based on both, and a third rendering weight can be obtained by combining them.

[0059] It is understood that this application embodiment obtains a third rendering weight by acquiring driving intention information and / or user interaction information, and further introducing forward-looking predictive factors and / or real-time user interaction factors on the basis of the second rendering weight. Driving intention information can perceive the driver's future operational needs before the actual occurrence of a driving operation event, thereby pre-adjusting the rendering weights of relevant safety semantic levels and effectively overcoming the problem of delayed rendering resource response when the scene changes abruptly. User interaction information can promptly perceive the target task to be rendered that the user is currently focused on, improving the response speed and smoothness of interactive feedback. Therefore, the rendering parameters determined based on the third rendering weight not only consider the current driving state but also integrate future driving intentions and real-time user interaction needs, realizing forward-looking pre-allocation of rendering resources and optimization of interactive response, further improving the level of rendering intelligence and user experience.

[0060] In some embodiments, adjusting the second rendering weight based on the driving intent information and / or user interaction information includes: Based on the driving operation event indicated by the driving intent information, increase the second rendering weight of the safety semantic level corresponding to the driving operation event; and / or, based on the user's interactive operation on the target task to be rendered indicated by the user interaction information, increase the second rendering weight of the safety semantic level to which the target task to be rendered belongs.

[0061] It should be noted that the safety semantic level corresponding to a driving operation event refers to the safety semantic level of the rendering task that needs to be prioritized in advance, associated with the upcoming driving operation event predicted based on navigation route planning information. For example, when a sharp bend or complex intersection is predicted ahead, the navigation map and AR-HUD guidance information (belonging to the driver assistance level) need to have their rendering weight increased in advance to ensure that rendering resources are ready when arriving at that location. The target rendering task refers to the specific rendering task targeted by the user's interactive operation through touch, voice, etc. For example, if the user touches the navigation map interface, then the navigation map is the target rendering task.

[0062] In some embodiments, when adjusting the second rendering weight based on driving intent information, the driver can first determine the upcoming driving operation event (such as turning, passing through an intersection, or entering a sharp bend) based on the driving intent information, then determine the safety semantic level that has a preset correspondence with the driving operation event, and then increase the second rendering weight corresponding to the safety semantic level. For example, when the navigation system prompts that a right turn is required 500 meters ahead, it can be determined that the driving operation event corresponds to the driving assistance level (such as navigation map or AR-HUD guidance information), and the second rendering weight corresponding to the driving assistance level can be increased to pre-allocate rendering resources and ensure that the navigation guidance information has sufficient rendering resources when the turning operation occurs, avoiding screen stuttering or delay caused by resource loading lag.

[0063] In some embodiments, when determining the safety semantic level corresponding to a driving operation event, the corresponding safety semantic level can be determined based on the type of the driving operation event. For example, driving operation events related to changes in navigation routes, such as turning or passing through an intersection, can correspond to the driving assistance level (such as navigation maps, AR-HUD overlay information, etc.); driving operation events such as reaching the destination can correspond to the interaction enhancement level (such as parking assistance interfaces, payment interfaces, etc.). The above correspondence can be pre-configured in the system.

[0064] In some embodiments, when adjusting the second rendering weight based on user interaction information, the target task to be rendered can be determined first based on the user interaction information, then the safety semantic level to which the target task to be rendered belongs can be determined, and then the second rendering weight corresponding to the safety semantic level can be increased. For example, when a user clicks on the navigation map interface through a touch operation, the target task to be rendered can be determined to be the navigation map, its safety semantic level is driving assistance level, and the second rendering weight corresponding to driving assistance level can be increased; when a user wakes up the voice assistant, the target task to be rendered can be determined to be the virtual assistant model, its safety semantic level is interaction enhancement level, and the second rendering weight corresponding to interaction enhancement level can be increased.

[0065] In some embodiments, user interaction operations include, but are not limited to: active touch (such as screen clicks, swipes, etc.), voice interaction (such as voice wake-up, voice commands, etc.), and continuous operations (such as dragging a map, continuous clicks, etc.). Different interaction operations may have different corresponding rendering weight gain amplitudes and durations. For example, active touch can correspond to a larger rendering weight gain amplitude, while continuous operations can correspond to a longer rendering weight gain duration to ensure the smoothness and stability of the interaction feedback.

[0066] In some embodiments, for rendering weight adjustment based on driving intent information, a pre-trigger time can be pre-calculated. Specifically, the pre-trigger time is dynamically calculated based on the current vehicle speed and the distance to the trigger point of the driving operation event; when the pre-trigger time is reached, an operation to increase the second rendering weight corresponding to the safety semantic level is performed. For example, when the navigation system prompts that a turn is needed 500 meters ahead, the time required to reach that location is calculated based on the current vehicle speed, and a rendering weight gain operation is performed at 20%-30% of this time window (configurable) to reserve rendering resources in advance.

[0067] It is understood that, by increasing the second rendering weight of the safety semantic level corresponding to the driving operation event indicated by the driving intention information, the embodiments of this application can pre-allocate resources for the relevant tasks to be rendered before the actual occurrence of the driving operation event, effectively overcoming the stuttering problem caused by the lag in rendering resource loading when the scene changes abruptly. Simultaneously, by increasing the second rendering weight of the safety semantic level of the target task to be rendered based on the user's interactive operations indicated by user interaction information, the system can respond promptly to the user's real-time interaction needs and improve the smoothness of interactive feedback. Thus, it achieves proactive pre-allocation of rendering resources and timely optimization of interactive responses, further improving the level of rendering intelligence and user experience.

[0068] In some embodiments, such as Figure 3 As shown, step 103 may further include steps 1031 to 1033: Step 1031: Obtain the real-time rendering load.

[0069] It should be noted that real-time rendering load refers to the rendering engine's rendering performance metrics at the current moment, including at least one of GPU frame time, CPU frame time, GPU utilization, and frame rate. This real-time rendering load reflects the current system's rendering resource usage.

[0070] In some embodiments, real-time rendering load can be obtained through performance monitoring interfaces provided by the rendering engine (such as Unity3D's FrameTimingManager).

[0071] Step 1032: Based on the real-time rendering load, adjust the rendering parameters of each of the tasks to be rendered.

[0072] In this embodiment of the application, the rendering parameters of each task to be rendered, which have been determined in step 102, can be dynamically adjusted or corrected based on the real-time rendering load so that the rendering quality is adapted to the current load capacity.

[0073] In some embodiments, when the real-time rendering load is detected to exceed a preset threshold, a rendering parameter degradation operation can be triggered, which means reducing the rendering quality of the task to be rendered; when the real-time rendering load is detected to be below the preset threshold, a rendering parameter recovery operation can be triggered, which means improving the rendering quality of the task to be rendered. The preset threshold can be adaptively set based on the actual application.

[0074] Step 1033: Render each of the tasks to be rendered based on the adjusted rendering parameters of each task to be rendered.

[0075] In this embodiment of the application, the rendering interface of the rendering engine can be called based on the adjusted rendering parameters of each task to be rendered to render each task and generate a rendered image.

[0076] In some embodiments, during the rendering process, the real-time rendering load can be obtained, and the rendering parameters can be dynamically adjusted according to the real-time rendering load, and then rendering can be performed based on the adjusted rendering parameters.

[0077] It is understood that the embodiments of this application obtain the real-time rendering load and dynamically adjust the rendering parameters of each task to be rendered based on the real-time rendering load, so that the rendering quality can be adaptively adjusted according to the changes in rendering load, effectively avoiding frame rate drop and screen stuttering caused by sudden increase in rendering load, and ensuring the stability of rendering performance.

[0078] In some embodiments, adjusting the rendering parameters of each of the tasks to be rendered based on the real-time rendering load includes: When the real-time rendering load is greater than the first preset value, the rendering parameters of the corresponding task to be rendered are adjusted step by step in order of security semantic level from low to high, until the real-time rendering load is less than or equal to the first preset value. When the real-time rendering load is less than the second preset value, the rendering parameters of the corresponding task to be rendered are adjusted step by step in order of the security semantic level from high to low, until the real-time rendering load is greater than or equal to the second preset value. Wherein, the second preset value is less than the first preset value.

[0079] It's important to note that the first preset value is the threshold for triggering rendering degradation adjustments. When the real-time rendering load exceeds this value, it indicates excessive rendering pressure, requiring a reduction in rendering quality to alleviate the load. The second preset value is the threshold for triggering rendering upgrade adjustments. When the real-time rendering load is below this value, it indicates sufficient rendering resources, allowing for an improvement in rendering quality to enhance the user's visual experience. The second preset value is lower than the first preset value, creating a hysteresis range between them. When the real-time rendering load falls between the first and second preset values, no adjustment is triggered, maintaining the current rendering quality and avoiding frequent adjustments caused by fluctuations in the real-time rendering load around a single threshold. Alternatively, the first and second preset values ​​can be equal if frequent adjustments are not a concern.

[0080] It should be noted that adjusting the rendering parameters of the corresponding tasks to be rendered level by level, from lowest to highest security semantic level, means first adjusting the rendering parameters of the tasks corresponding to the lowest security semantic level (e.g., first reducing the rendering quality of the entertainment / leisure level). If the real-time rendering load is still not up to standard, then adjusting the rendering parameters of the tasks corresponding to the next lowest security semantic level (e.g., further reducing the rendering quality of the interactive enhancement level), and so on, until the real-time rendering load is up to standard. Here, "corresponding tasks to be rendered" refers to all tasks belonging to the corresponding security semantic level.

[0081] In some embodiments, the first preset value and the second preset value can be set based on the target frame rate. For example, when the target frame rate is 60 FPS, the corresponding target frame time threshold is approximately 16.67 ms. The first preset value can be set to this target frame time threshold (e.g., 16.67 ms), and the second preset value can be set to a value less than the first preset value (e.g., 14 ms) to form a hysteresis interval. In practical applications, the specific values ​​of the first preset value and the second preset value can be configured and adjusted according to factors such as the performance of the vehicle hardware platform, the target frame rate, and user preferences. This application embodiment does not impose specific limitations on this.

[0082] In some embodiments, when the real-time rendering load exceeds a first preset value, a degradation adjustment is performed. The degradation adjustment is performed step by step according to the security semantic level from low to high. Specifically, firstly, the rendering quality of the task to be rendered corresponding to the lowest security semantic level (such as the entertainment level) is reduced, and then the real-time rendering load is re-acquired and it is determined whether it is still greater than the first preset value; if it is still greater than the first preset value, the rendering quality of the task to be rendered corresponding to the next lowest security semantic level (such as the interactive enhancement level) is reduced, and so on, until the real-time rendering load is less than or equal to the first preset value.

[0083] In some embodiments, when the real-time rendering load is less than a second preset value, an upgrade adjustment is performed. The upgrade adjustment is performed step by step in descending order of security semantic level. Specifically, firstly, the rendering quality of the task to be rendered corresponding to the highest security semantic level (such as security core level) is improved, and then the real-time rendering load is re-acquired and it is determined whether it is still less than the second preset value; if it is still less than the second preset value, the rendering quality of the task to be rendered corresponding to the second highest security semantic level (such as driving assistance level) is improved, and so on, until the real-time rendering load is greater than or equal to the second preset value.

[0084] In some embodiments, the rendering parameters of each task to be rendered are adjusted, including but not limited to at least one of the following operations: reducing or increasing resolution, reducing or increasing level of detail, cropping or restoring post-processing effects, and reducing or increasing the number of particles. When performing downgrade adjustments, the rendering quality can be gradually reduced according to a preset adjustment step size. For example, the resolution can be reduced first, and if the load is still not up to standard, the level of detail can be reduced, and then the post-processing effects can be cropped, and so on.

[0085] In some embodiments, rendering tasks belonging to the highest security semantic level (such as security kernel level) will not have their rendering quality reduced under any circumstances (including when the real-time rendering load exceeds a first preset value). During upgrades and adjustments, the rendering quality of rendering tasks belonging to the highest security semantic level can be prioritized for improvement.

[0086] It is understood that in this embodiment, when the real-time rendering load exceeds a first preset value, the rendering quality of the corresponding task to be rendered is progressively reduced in order of increasing security semantic level until the real-time rendering load falls below the first preset value; when the real-time rendering load is less than a second preset value, the rendering quality of the corresponding task to be rendered is progressively increased in order of decreasing security semantic level until the load rises above the second preset value. This ensures that rendering tasks with high security semantic levels receive maximum protection during the downgrade process, while rendering tasks with low security semantic levels are downgraded first, achieving a balance between rendering performance and driving safety.

[0087] In some embodiments, the method further includes: During the rendering process of each of the aforementioned tasks, the visual elements of a preset type in each of the aforementioned tasks are enhanced to ensure the clarity of the visual elements of the preset type.

[0088] It should be noted that preset visual elements refer to predefined visual information elements that have a significant impact on driving safety. These elements carry critical driving safety or navigation guidance information and need to maintain high visual clarity during rendering, without becoming blurry or distorted even if the overall rendering quality is reduced. Enhanced rendering refers to using specific rendering techniques to ensure that these preset visual elements maintain high visual clarity in the rendered result.

[0089] In some embodiments, the preset type of visual elements may include at least one of the following: road signs, speed limit signs, navigation arrows, lane guide lines, ADAS warning icons, vehicle speed figures, and other visual elements that carry driving safety information or navigation guidance information. These elements may be pre-labeled or configured, for example, by setting specific GameObject tags or layers.

[0090] In some embodiments, enhanced rendering may include at least one of the following methods: high-resolution texture sampling, edge enhancement shaders, and independent channel rendering. High-resolution texture sampling refers to forcing the use of original high-resolution textures for texture sampling of these visual elements during the rendering process, rather than downgraded low-resolution textures; edge enhancement shaders refer to applying a lightweight edge enhancement post-processing shader specifically for sharpening the edges of the rendered results of these visual elements, thereby improving contrast; independent channel rendering refers to placing these visual elements in independent rendering channels, rendering them at full resolution, and then overlaying them onto the scene.

[0091] In some embodiments, when a degradation adjustment is performed, the rendering quality of other tasks to be rendered may be reduced, but for visual elements of a preset type, their visual clarity can be maintained by enhancing the rendering. Specifically, when a degradation adjustment is performed on tasks to be rendered that belong to the safety core level or driver assistance level, the visual elements of the preset type in these tasks are not affected by the degradation adjustment and are still rendered with a higher rendering quality.

[0092] In some embodiments, enhanced rendering of preset types of visual elements can be performed during each frame of rendering, regardless of the real-time rendering load. That is, these visual elements are always rendered in an enhanced rendering manner, regardless of the current rendering load, to ensure their clarity in any scene.

[0093] It is understood that, in the process of rendering each task to be rendered, the visual elements of the preset type are enhanced, so that these visual elements carrying driving safety information always receive targeted rendering enhancement during the rendering process. Even if the rendering quality of other visual elements in the task to be rendered is reduced due to load adjustment, the visual elements of the preset type can still remain clear and distinguishable, thus ensuring the effective communication of driving safety information.

[0094] The following examples illustrate possible implementation schemes of the rendering method described in one or more of the above embodiments.

[0095] This solution introduces a driving scene semantic parsing module and a vehicle state perception module to acquire real-time vehicle driving data (such as vehicle speed, turn signal signals, gear position, ADAS warning status, etc.) and divides the current Unity3D rendering task into different safety semantic levels (such as safety core level, driving assistance level, interaction enhancement level, and entertainment level). The load balancing decision system adjusts the rendering priority weight of each safety semantic level in real time according to the dynamic changes in the vehicle's real-time driving status. For example, during high-speed driving or emergency obstacle avoidance, the system automatically suppresses the rendering load of entertainment content to ensure the absolute smoothness of safety core level content (such as key information on the dashboard) and driving assistance level content (such as AR-HUD guidance); while when the vehicle is stationary or in Park mode, it releases the rendering potential to provide the ultimate entertainment visual experience. In addition, this solution also introduces a user intent prediction mechanism, which analyzes vehicle control signals (such as the turn signal that is about to be activated or navigation route planning) to pre-allocate rendering resources, achieving an integrated dynamic balance of "perception-prediction-allocation".

[0096] For example, Figure 4 This is a schematic diagram of an in-vehicle rendering system architecture provided in an embodiment of this application, such as... Figure 4 As shown, the system includes an input layer 401, a perception and analysis layer 402, a decision layer 403, an execution layer 404, and a monitoring layer 405. The input layer 401 includes an in-vehicle CAN bus 4011 and a navigation system 4012. The perception and analysis layer 402 includes a vehicle state perception module 4021 and a semantic hierarchical engine 4022. The decision layer 403 includes an intent prediction module 4031 and a dynamic load decision center 4032. The execution layer 404 includes a rendering execution unit 4041. The monitoring layer 405 includes a GPU frame time monitoring module 4051 and a CPU frame time monitoring module 4052. This system is deeply integrated into the in-vehicle Unity3D engine architecture and interacts with the vehicle's underlying data through the in-vehicle CAN bus 4011.

[0097] The vehicle status perception module 4021 acquires real-time vehicle controller local area network data via the vehicle CAN bus 4011 and standardizes it into parameters recognizable by Unity3D. These parameters may include: Vehicle speed: measured in km / h, directly affects the dynamic judgment of driving scenarios; Gear selection: P / R / N / D, used to determine whether the vehicle is stationary, reversing, or moving; Steering angle: reflects the driver's steering intention and can be used to predict steering behavior when combined with vehicle speed; Turn signal status: The on / off status of the left and right turn signals is an important signal that a turn is imminent; Braking pressure: reflects the driver's braking intention and is used to judge emergency situations; ADAS warning signals, such as lane departure warning and forward collision warning, directly trigger the highest priority of L1 level rendering tasks.

[0098] Semantic Hierarchy Engine 4022 is used to semantically tag and classify rendering tasks in Unity3D applications in the following ways: L1 - Safety Core Level: Corresponds to UI elements and 3D models with specific layers in Unity3D. These elements are typically driven directly by the vehicle's safety system, and their rendering priority is set to the highest at the engine level. They may also be bound to a separate rendering queue to ensure they are not blocked by other rendering tasks. Examples include speedometers and malfunction warning lights.

[0099] Level 2 (L2) driver assistance: This includes 3D models of navigation maps, overlaid information from AR-HUD, and real-time environmental perception rendering for APA (Automatic Parking). These elements can be tagged using Unity3D's GameObject.tag.

[0100] L3 - Enhanced Interaction Level: Corresponds to virtual assistant models, dynamic effects of air conditioning control panels, etc. These elements typically have high visual complexity but have minimal impact on driving safety and can be identified through their parent GameObject.

[0101] L4 - Entertainment & Leisure Level: Corresponds to multimedia player interfaces, 3D desktop backgrounds, and animations. These elements are placed in independent scenes or sub-scenes and managed through specific Root GameObjects, making them easy for the system to recognize and control as a whole.

[0102] The intent prediction module 4031 uses data provided by the vehicle state perception module 4021 and path planning information from the navigation system 4012 to predict the driver's intent and upcoming scene changes through the following algorithm: Navigation system path analysis: By combining navigation path data, when a sharp bend or complex intersection is detected ahead, the preloading and rendering resource reservation of relevant areas (such as local high-precision models of 3D maps and path indications of AR navigation) are triggered in advance.

[0103] Speed ​​and distance matching: When the navigation prompts "Turn right in 500 meters," the system calculates the time required for the driver to reach that location based on the current vehicle speed. At 20%-30% of this time window (configurable), the priority of L2-level navigation-assisted rendering is increased, and GPU resources are pre-allocated.

[0104] The system associates turn signals with turning intentions: When the vehicle speed is below a certain threshold (such as 30km / h) and the turn signal is on, the system determines that the driver is about to make a turning operation and immediately increases the rendering priority of the 3D navigation instructions in the corresponding direction.

[0105] The Dynamic Load Decision Center 4032 is the core intelligent unit of this solution. Its decision-making basis includes real-time performance data, driving scenario semantics, and vehicle driving status. The Dynamic Load Decision Center 4032 dynamically calculates a rendering weight matrix, where each element W_{I, j} represents the rendering priority weight of safety semantic level j under the current vehicle driving status I. The weight calculation formula is shown in equation (1): (1) in, This represents the total weight, indicating the final rendering priority weight. The baseline weights are based on the L1-L4 security semantic levels, with L1 being the highest and L4 the lowest. The preset values ​​are L1=100, L2=80, L3=50, and L4=20. This is the vehicle's driving state coefficient, calculated from dynamic parameters such as vehicle speed, gear position, and ADAS warnings. For example, the higher the vehicle speed, the better. The greater the weight gain for L1 and L2, the greater the weight penalty for L4. As an intent prediction factor, when the intent prediction module 4031 identifies an impending scene change, it temporarily adjusts the weights of the relevant security semantic levels. This is a user interaction factor that temporarily increases the weight of an application when a user actively interacts with it at level L3 or L4. , , and These are configurable weighting coefficients used to balance the influence of various factors. The default values ​​are: (As a core benchmark) (The driving force for strengthening the security status) (Enhancing the sense of responsiveness of the system) (Balancing interactive experience and system load) is determined through experimental optimization in actual engineering.

[0106] GPU frame time monitor 4051 and CPU frame time monitor 4052 continuously monitor GPU frame time (FrameTimingManager.gpuFrameTime) and CPU frame time (FrameTimingManager.cpuFrameTime). A target frame rate is set (e.g., 60 FPS). If the actual frame time consistently exceeds the target frame time threshold (e.g., 16.67ms), the dynamic load decision center 4032 determines that a performance bottleneck exists. When a performance bottleneck is detected, the dynamic load decision center 4032, based on the currently calculated rendering weight matrix, gradually executes degradation instructions starting from the lowest priority semantic level (L4). For example, it first reduces the rendering resolution of L4 level applications. If the target frame rate still cannot be achieved, it then trims L4 level post-processing effects, then reduces the refresh rate of L3 level, and so on, until L2 level is reached. L1 level rendering tasks are never degraded under any circumstances. When the performance bottleneck is resolved, i.e., when the frame time consistently falls below the target frame time threshold, the dynamic load decision center 4032 will gradually restore the rendering quality in reverse order (from L2 to L4) to provide the best visual experience.

[0107] The rendering execution unit 4041 receives instructions from the dynamic load decision center 4032 and calls the Unity3D engine's API or custom rendering pipeline functions to make the following fine-tuning adjustments: Dynamic resolution: The ScalableBufferManager.ResizeBuffers(widthScale, heightScale) interface is used to scale the resolution of non-L1 level rendering tasks. For example, the resolution of an L4 level application can be reduced from 100% to 50%.

[0108] Level of Detail (LOD): Dynamically adjusts the LOD level of L2 and L3 objects in the scene. For example, distant building models in a navigation map can be switched to low-poly and their shadow rendering can be turned off.

[0109] Post-processing effect cropping: For L3 and L4 level applications, dynamically turn off or reduce the intensity of post-processing effects such as anti-aliasing, ambient light occlusion, floodlight, and depth of field.

[0110] Particle system optimization: For particle effects in L3 and L4 level applications, dynamically reduce the number of particles, lower the emission rate, or shorten the particle life cycle.

[0111] Semantic preservation degradation: For key visual elements (such as road signs, speed limit signs, and navigation arrows) contained in L2 level (such as navigation maps), even if the overall rendering resolution of the area where they are located is reduced, the rendering execution unit 4041 will ensure their visual clarity in the following ways: (1) High-resolution texture sampling: In the shader, the texture sampling of these key elements is forced to use the original high-resolution texture, rather than the downgraded low-resolution texture; (2) Edge enhancement shader: A lightweight edge enhancement post-processing shader is applied to sharpen the edges of the rendering results of these key visual elements and improve the contrast. (3) Independent rendering channel: For a very small number of the most important L2 visual elements, they can be placed in an independent rendering channel and rendered at full resolution before being superimposed on the downgraded scene.

[0112] Tables 1 to 3 below show the dynamic adjustment strategy of this scheme under different typical driving scenarios, as well as the value specifications of each factor in formula (1), which are used to convert vehicle physical signals into Unity3D permission weights. Table 1 shows the vehicle's driving state coefficients. The mapping specification, Table 2 shows the intention prediction factors. The mapping specification, Table 3 shows the user interaction factors. The mapping specification.

[0113] Table 1

[0114] Table 2

[0115] Table 3

[0116] Figure 5 This is a schematic diagram of the rendering process of an in-vehicle rendering system architecture provided in an embodiment of this application, such as... Figure 5 As shown, the process includes steps 501 to 510: Step 501, Multi-dimensional data synchronization: The system synchronously collects vehicle CAN bus data, Unity3D rendering pipeline status, and user interaction intent.

[0117] Step 502, Semantic Scene Recognition: Combining the vehicle's driving status (such as speed and gear) and the current application status, identify the semantics of the current driving scene, that is, identify which safety semantic level (L1 / L2 / L3 / L4) the current rendering task belongs to.

[0118] Step 503, Dynamic Priority Reconstruction: Based on the semantics of the driving scene, reconstruct the priority queue of rendering tasks in real time.

[0119] Step 504, Intent Look-Ahead Compensation: Check if there are any upcoming scene changes (such as an upcoming turn). If so, reserve rendering resources in advance.

[0120] Step 505, determine if the load is excessive: assess the current GPU / CPU load. If it is excessive, proceed to step 506; if the load is sufficient, proceed to step 507.

[0121] Step 506, Degradation Execution: Degradation is performed starting from the lower priority semantic layer (e.g., first reduce the resolution of L4, then trim the effects of L3).

[0122] Step 507, Image Quality Restoration: Restore image quality starting from the high-priority semantic layer.

[0123] Step 508, Semantic Preservation Rendering: When adjusting parameters, the rendering execution unit applies a semantic preservation algorithm to ensure that key visual elements or symbols (such as speed limit signs) are not blurred due to degradation.

[0124] Step 509, Closed-loop feedback: After rendering is completed, the actual frame time is fed back to the dynamic load decision center for strategy correction in the next frame.

[0125] Step 510: Determine whether to continue processing the next frame: if yes, return to step 501; if no, end the process.

[0126] Understandably, this solution proposes a dynamic rendering load balancing method based on semantic perception of driving scenarios and vehicle driving status. This method no longer relies solely on the "complexity" or "visual salience" of the rendering layer, but instead prioritizes "driving safety semantics" as the first priority indicator for allocating rendering resources. This ensures that 3D rendering applications can maintain smooth and stable rendering performance in various complex scenarios under limited onboard hardware resources, while also taking into account visual effects.

[0127] It's important to note that purely static optimization schemes in related technologies fix the rendering quality before application release by manually adjusting detail levels, baking lighting, optimizing models and textures, and using static batch processing during the development phase. For example, a fixed detail level is preset for all objects, or all post-processing effects are directly disabled to ensure basic performance. However, this approach lacks dynamic adaptability. In simple scenes, it may waste hardware performance and fail to provide optimal visual effects; while in complex scenes, insufficient preset optimization may lead to frame rate drops, failing to intelligently adjust according to real-time changes in scene complexity and system load. For simple dynamic resolution schemes based on fixed thresholds in related technologies, the system compares only one or a few performance metrics (such as GPU frame time) with a fixed threshold. Once the threshold is exceeded, the global rendering resolution is reduced; below the threshold, it is restored. For example, when the frame rate is below 30 FPS, the resolution is reduced by 10%. However, while this scheme has some dynamism, the adjustment is too coarse. It does not consider the priority of different elements in the scene, which may lead to a decrease in the display quality of critical information (such as the dashboard), affecting driving safety. Meanwhile, a single adjustment method may be insufficient to address all complex performance bottlenecks, and the adjustment process may not be smooth enough, easily causing abrupt changes in the visuals. This solution, however, achieves more refined, intelligent, and secure dynamic load balancing by introducing scene priority evaluation and multi-dimensional rendering parameter collaborative adjustment. This not only ensures the display quality of critical information but also achieves a better balance between performance and visual effects, while reducing reliance on high-end hardware, thus possessing greater practical value and market competitiveness.

[0128] It is understood that, compared with related technologies, this application has the following significant advantages: (1) Deep semantic association: Related technologies only start from the "rendering task" itself, while this application deeply binds rendering load balancing with "driving safety semantics". By distinguishing different levels of safety semantics, it ensures that rendering tasks involving driving safety always receive the highest resource guarantee under any extreme load.

[0129] (2) Dynamics driven by vehicle driving status: The vehicle driving status (speed, gear, steering, etc.) is introduced as the core triggering condition for load balancing, so that the rendering performance can be dynamically adjusted adaptively with the changes in the driving environment, and true vehicle environment adaptation is achieved.

[0130] (3) Proactive resource allocation: Through the intention prediction mechanism, the response lag problem of traditional load balancing technology when the scene changes suddenly (such as entering a complex tunnel or overpass) is solved, and the instantaneous lag is effectively eliminated.

[0131] (4) Semantic preservation degradation mechanism: Unlike traditional global degradation, this application can protect the visual clarity of key visual elements (such as navigation arrows and warning icons) in a targeted manner while reducing the load, achieving a better balance between performance optimization and information delivery.

[0132] (5) Improve driving safety: By suppressing non-critical entertainment loads to ensure the real-time nature of driving assistance information, the risk of driver distraction or misjudgment caused by HMI lag is directly reduced.

[0133] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps; or steps from different embodiments may be combined into a new technical solution.

[0134] Figure 6 This is a schematic diagram of the structure of a rendering device provided in an embodiment of this application, such as... Figure 6 As shown, the rendering apparatus 600 includes: an acquisition module 610, a determination module 620, and a rendering module 630; wherein: The acquisition module 610 is used to acquire the real-time driving status of the vehicle and at least one task to be rendered; the task to be rendered has a corresponding safety semantic level, and the safety semantic level characterizes the degree of influence of the task to be rendered on the driving safety of the vehicle. The determining module 620 is used to determine the rendering parameters of each of the tasks to be rendered based on the real-time driving status and the security semantic level corresponding to each of the tasks to be rendered. The rendering module 630 is used to render each of the tasks to be rendered based on the rendering parameters of each task to be rendered.

[0135] In some embodiments, the determining module 620 is further configured to: determine a first rendering weight corresponding to each of the security semantic levels based on the security semantic levels corresponding to each of the tasks to be rendered; the security semantic level and the first rendering weight are positively correlated; adjust the first rendering weight corresponding to each of the security semantic levels based on the real-time driving state to obtain a second rendering weight corresponding to each of the security semantic levels; and determine the rendering parameters of each task to be rendered based on the second rendering weight corresponding to the security semantic level to which each task to be rendered belongs.

[0136] In some embodiments, the determining module 620 is further configured to: increase the first rendering weight corresponding to the first safety semantic level and decrease the first rendering weight corresponding to the second safety semantic level when the real-time driving state indicates that the driving risk of the vehicle has increased; the first safety semantic level is greater than the second safety semantic level; and decrease the first rendering weight corresponding to the first safety semantic level and increase the first rendering weight corresponding to the second safety semantic level when the real-time driving state indicates that the driving risk of the vehicle has decreased.

[0137] In some embodiments, the determining module 620 is further configured to: acquire driving intention information and / or user interaction information; the driving intention information is used to indicate a driving operation event that will occur within a preset time period in the future; the user interaction information is used to indicate the user's interactive operation for the target task to be rendered; adjust the second rendering weight based on the driving intention information and / or user interaction information to obtain a third rendering weight; and determine the rendering parameters of each of the tasks to be rendered based on the third rendering weight.

[0138] In some embodiments, the determining module 620 is further configured to: increase the second rendering weight of the safety semantic level corresponding to the driving operation event based on the driving operation event indicated by the driving intention information; and / or, increase the second rendering weight of the safety semantic level to which the target task to be rendered belongs based on the user's interactive operation performed on the target task to be rendered as indicated by the user interaction information.

[0139] In some embodiments, the rendering module 630 is further configured to: acquire real-time rendering load; adjust the rendering parameters of each of the tasks to be rendered based on the real-time rendering load; and render each of the tasks to be rendered based on the adjusted rendering parameters.

[0140] In some embodiments, the rendering module 630 is further configured to: when the real-time rendering load is greater than a first preset value, adjust the rendering parameters of the corresponding task to be rendered step by step according to the security semantic level from low to high, until the real-time rendering load is less than or equal to the first preset value; when the real-time rendering load is less than a second preset value, adjust the rendering parameters of the corresponding task to be rendered step by step according to the security semantic level from high to low, until the real-time rendering load is greater than or equal to the second preset value; wherein the second preset value is less than the first preset value.

[0141] In some embodiments, the rendering module 630 is further configured to: enhance the rendering of visual elements of a preset type in each of the tasks to be rendered during the rendering process, so as to ensure the clarity of the visual elements of the preset type.

[0142] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0143] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 The illustrated electronic device 700 includes a processor 701, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0144] Optionally, such as Figure 7 As shown, the electronic device 700 may further include a memory 702. The processor 701 can retrieve and run computer programs from the memory 702 to implement the methods described in the embodiments of this application.

[0145] The memory 702 can be a separate device independent of the processor 701, or it can be integrated into the processor 701.

[0146] Optionally, such as Figure 7 As shown, the electronic device 700 may also include a transceiver 703, which the processor 701 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0147] The transceiver 703 may include a transmitter and a receiver. The transceiver 703 may further include an antenna, which may be one or more.

[0148] This application also provides a vehicle, including the electronic equipment described in this application, which will not be described in detail here for the sake of brevity.

[0149] This application also provides a computer-readable storage medium for storing computer programs.

[0150] Optionally, the computer-readable storage medium can be applied to the electronic device in the embodiments of this application, and the computer program causes the processor or electronic device to perform the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0151] This application also provides a computer program product, including computer program instructions.

[0152] Optionally, the computer program product can be applied to the electronic device in the embodiments of this application, and the computer program instructions cause the processor or electronic device to execute the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0153] This application also provides a computer program.

[0154] Optionally, the computer program can be applied to the electronic device in the embodiments of this application. When the computer program runs on the processor or electronic device, it causes the processor or electronic device to execute the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0155] It should be noted that the descriptions of the devices, storage media, computer program products, and computer program embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the device, storage media, computer program products, and computer program embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0156] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0157] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0158] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0159] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0160] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0161] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0162] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0163] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0164] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a vehicle to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0165] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A rendering method, characterized in that, The method includes: The system acquires the real-time driving status of the vehicle and at least one task to be rendered; the task to be rendered has a corresponding safety semantic level, which characterizes the degree of impact of the task to be rendered on the driving safety of the vehicle. Based on the real-time driving status and the security semantic level corresponding to each of the tasks to be rendered, the rendering parameters of each task to be rendered are determined. Render each of the tasks to be rendered based on its rendering parameters.

2. The method according to claim 1, characterized in that, The step of determining the rendering parameters for each of the tasks to be rendered based on the real-time driving state and the security semantic level corresponding to each task to be rendered includes: Based on the security semantic level corresponding to each of the aforementioned tasks to be rendered, a first rendering weight corresponding to each of the aforementioned security semantic levels is determined; the security semantic level and the first rendering weight are positively correlated. Based on the real-time driving status, the first rendering weights corresponding to each of the safety semantic levels are adjusted to obtain the second rendering weights corresponding to each of the safety semantic levels. The rendering parameters of each of the tasks to be rendered are determined based on the second rendering weight corresponding to the security semantic level to which each task belongs.

3. The method according to claim 2, characterized in that, The adjustment of the first rendering weight corresponding to each of the safety semantic levels based on the real-time driving status includes: When the real-time driving status indicates an increased driving risk for the vehicle, the first rendering weight corresponding to the first safety semantic level is increased, and the first rendering weight corresponding to the second safety semantic level is decreased; the first safety semantic level is greater than the second safety semantic level. When the real-time driving status indicates a reduction in the driving risk of the vehicle, the first rendering weight corresponding to the first safety semantic level is reduced, and the first rendering weight corresponding to the second safety semantic level is increased.

4. The method according to claim 2, characterized in that, The step of determining the rendering parameters of each of the tasks to be rendered based on the second rendering weight corresponding to the security semantic level to which each task belongs includes: Acquire driving intent information and / or user interaction information; the driving intent information is used to indicate driving operation events that will occur within a preset time period in the future; the user interaction information is used to indicate the user's interactive operations on the target task to be rendered. Based on the driving intention information and / or user interaction information, the second rendering weight is adjusted to obtain the third rendering weight; Based on the third rendering weight, the rendering parameters for each of the tasks to be rendered are determined.

5. The method according to claim 4, characterized in that, The adjustment of the second rendering weight based on the driving intent information and / or user interaction information includes: Based on the driving operation event indicated by the driving intent information, increase the second rendering weight of the safety semantic level corresponding to the driving operation event; and / or, based on the user's interactive operation on the target task to be rendered indicated by the user interaction information, increase the second rendering weight of the safety semantic level to which the target task to be rendered belongs.

6. The method according to claim 1, characterized in that, The rendering of each of the tasks to be rendered based on the rendering parameters of each task to be rendered includes: Get real-time rendering load; Based on the real-time rendering load, the rendering parameters of each of the tasks to be rendered are adjusted; Based on the adjusted rendering parameters of each of the tasks to be rendered, each of the tasks to be rendered is rendered.

7. The method according to claim 6, characterized in that, The adjustment of rendering parameters for each of the tasks to be rendered based on the real-time rendering load includes: When the real-time rendering load is greater than the first preset value, the rendering parameters of the corresponding task to be rendered are adjusted step by step in order of security semantic level from low to high, until the real-time rendering load is less than or equal to the first preset value. When the real-time rendering load is less than the second preset value, the rendering parameters of the corresponding task to be rendered are adjusted step by step in order of the security semantic level from high to low, until the real-time rendering load is greater than or equal to the second preset value. Wherein, the second preset value is less than the first preset value.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: During the rendering process of each of the aforementioned tasks, the visual elements of a preset type in each of the aforementioned tasks are enhanced to ensure the clarity of the visual elements of the preset type.

9. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 8.

10. A vehicle, characterized in that, Includes the electronic device as described in claim 9.

Images