Graphical rendering method, apparatus, electronic device, vehicle, and readable storage medium

Abstract

The present application relates to a kind of graphic rendering method, device, electronic equipment, vehicle and readable storage medium, the method includes: the three-dimensional model of target object, the configuration parameter of target object and the page function of model display page of mobile terminal are acquired;According to page function and configuration parameter, determine key shader and the key variant of key shader in the shader set corresponding to three-dimensional model;Key shader and the key variant of key shader are preprocessed operation, and preprocessing operation includes at least one of precompilation processing and preheating processing;From three-dimensional model, extract rendering object and store in to be rendered layer;Using the key shader and key variant of completing preprocessing operation, rendering is carried out to be rendered layer.The method can solve the first frame jitter problem when mobile terminal enters model display page for the first time and carries out three-dimensional model display, improve the rendering effect of three-dimensional model in mobile terminal.

Description

Technical Field

[0001] This invention relates to the field of image processing technology, and more specifically to a graphics rendering method, apparatus, electronic device, vehicle, and readable storage medium. Background Technology

[0002] In scenarios where users remotely view vehicles, the vehicle's 3D model is primarily loaded using real-time graphics rendering technology on mobile devices to enable interactive display of the vehicle's exterior, interior, and status. However, the graphics rendering performance of mobile devices is limited, so it is necessary to reduce the performance requirements of the 3D vehicle model to make it suitable for loading on mobile devices.

[0003] Currently, existing solutions mainly focus on model simplification, reducing the number of faces in 3D models, simplifying material and texture data, and thus reducing the size of 3D model resources to adapt to the graphics rendering performance of mobile devices.

[0004] However, the existing processing method still causes stuttering and unstable frame rates when mobile devices first enter the 3D model display screen, resulting in poor graphics rendering. Summary of the Invention

[0005] One objective of this invention is to provide a graphics rendering method to solve the problem of lag and poor graphics rendering effect when mobile devices first enter the 3D model display screen; a second objective is to provide a graphics rendering device; a third objective is to provide an electronic device; a fourth objective is to provide a vehicle; and a fifth objective is to provide a computer-readable storage medium.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A graphics rendering method, applied to a mobile device, the method comprising:

[0008] The page functions for acquiring the 3D model of the target object, the configuration parameters of the target object, and the model display page of the mobile terminal;

[0009] Based on the page functions and the configuration parameters, determine the key shader and the key variant of the key shader in the shader set corresponding to the 3D model;

[0010] Preprocessing operations are performed on the key shader and the key variants of the key shader, the preprocessing operations including at least one of pre-compilation processing and preheating processing;

[0011] Extract the target rendering object from the 3D model and store it in the layer to be rendered;

[0012] The layer to be rendered is rendered using the key shader and key variant that have completed the preprocessing operation.

[0013] Furthermore, the preprocessing operation on the key shader and its key variants includes:

[0014] Add the key shader to the pre-compilation queue;

[0015] Add the key variant to the warm-up queue;

[0016] The key shaders in the pre-compilation queue are pre-compiled during a target time period, which includes at least one of the following: the time period before the mobile device switches to displaying the model display page, the time period during which the mobile device loads the 3D model, and the idle time period of the mobile device.

[0017] The key variants in the preheating queue are preheated during the target time period.

[0018] Furthermore, the step of extracting the target rendering object from the 3D model and storing it in the layer to be rendered includes:

[0019] Detect whether each object to be rendered in the 3D model has dynamic change features, where the dynamic change features are the features that produce visual changes during the rendering and display process;

[0020] If the dynamic change characteristics exist, then the object to be rendered is determined to be a dynamic rendering object;

[0021] If the dynamic change feature does not exist, the object to be rendered is determined to be a static rendering object;

[0022] Extract the dynamic rendering object from the 3D model and store it in the dynamic layer to be rendered;

[0023] Extract the static rendering object from the 3D model and store it in the static layer to be rendered.

[0024] Furthermore, the rendering of the layer to be rendered includes: rendering the dynamic layer in real time using a real-time rendering strategy; and rendering the static layer in non-real-time using a cache reuse strategy or a low-frequency refresh strategy.

[0025] Furthermore, the step of employing a cache reuse strategy or a low-frequency refresh strategy to perform non-real-time rendering of the static layer includes:

[0026] If the target conditions corresponding to the low-frequency refresh strategy are met, the static layer will be re-rendered at preset intervals. The target conditions include at least one of the following: the configuration information of the target object is switched, the display perspective of the 3D model is adjusted, and the state of the static rendering object changes.

[0027] If the target condition is not met, the rendering result of the static layer at a historical moment is reused using the cache reuse strategy as the rendering result of the static layer at the current moment.

[0028] Furthermore, the above methods also include:

[0029] When rendering the static layer and / or the dynamic layer, the key performance indicators of the mobile device are obtained, including at least one of frame rate, number of drawing calls, memory usage, device temperature and battery status.

[0030] If the key performance indicators do not meet the preset rendering conditions, a dynamic adjustment operation of the rendering parameters is performed. The dynamic adjustment operation of the rendering parameters includes at least one of the following: reducing the refresh frequency of the static layer, turning off non-critical effects or reducing post-processing effects, switching to low-precision models or low-quality materials, reducing the environmental reflection level, and limiting the number of key variants loaded.

[0031] Furthermore, after rendering the layer to be rendered, the method further includes: superimposing the rendering result of the dynamic layer and the rendering result of the static layer to generate a three-dimensional model image; and displaying the three-dimensional model image on the model display page.

[0032] Furthermore, the above method also includes: acquiring the original three-dimensional model resource of the target object; and performing lightweight processing on the original three-dimensional model resource to generate the three-dimensional model.

[0033] Furthermore, the step of lightweighting the original 3D model resource to generate the 3D model includes:

[0034] Based on the analysis results obtained after structural analysis of the target object, the target structure in the original 3D model resource is removed or replaced to generate a target resource adapted to the mobile rendering; the target structure includes at least one of the following: a structure with visual sensitivity lower than a preset sensitivity threshold, an invisible structure, and a long-term occluded structure.

[0035] The target sub-mesh in the target resource is batched, and the target sub-mesh is a sub-mesh with the same material properties, the same shader configuration, or the same rendering state.

[0036] The target textures in the target resource are merged into a texture atlas, wherein the target textures are textures with a size smaller than a preset size threshold;

[0037] Based on the texture coordinates of each target texture, a unified texture coordinate system for the texture atlas is established to generate the 3D model.

[0038] A graphics rendering apparatus, comprising:

[0039] The acquisition module is used to acquire the 3D model of the target object, the configuration parameters of the target object, and the page functions of the model display page on the mobile terminal;

[0040] A determination module is used to determine, based on the page functions and the configuration parameters, a key shader and a key variant of the key shader in the shader set corresponding to the 3D model;

[0041] A processing module is configured to perform preprocessing operations on the key shader and the key variants of the key shader, the preprocessing operations including at least one of pre-compilation processing and preheating processing;

[0042] The extraction module is used to extract the target rendering object from the 3D model and store it in the layer to be rendered;

[0043] The rendering module is used to render the layer to be rendered using the key shaders and key variants that have completed the preprocessing operations.

[0044] An electronic device includes: a memory and at least one processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the method described above.

[0045] A vehicle includes: a vehicle body and the aforementioned electronic equipment disposed in the vehicle body.

[0046] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the above-described method.

[0047] The beneficial effects of this invention are:

[0048] (1) Smoother first frame experience: Reduce lag when mobile applications first enter the model display page to display 3D models by shader pre-compilation and key variant warm-up.

[0049] (2) More stable performance: By using separate layers for dynamic and static rendering objects, invalid rendering in static scenes is reduced, improving frame rate stability and reducing heat generation.

[0050] (3) More controllable resource size: By model lightweighting, mesh batch processing and texture merging, the package size, download time and memory consumption are reduced while ensuring the appearance.

[0051] (4) More versatile: It is applicable to Android operating system, iPhone operating system and open source HarmonyOS operating system, as well as different 3D engine architectures, and has good cross-platform capabilities.

[0052] (5) Higher project feasibility: It does not rely on specific business pages and can be directly adapted to various business scenarios such as vehicle marketing display, configurator, and vehicle condition display. Attached Figure Description

[0053] Figure 1 A schematic flowchart illustrating the graphics rendering method provided in an embodiment of this application;

[0054] Figure 2 A flowchart of shader pre-compilation and runtime scheduling provided for embodiments of this application;

[0055] Figure 3 This is a schematic diagram of layered rendering of dynamic and static layers provided in an embodiment of this application;

[0056] Figure 4 This is a diagram illustrating the architecture of a graphics rendering system provided in an embodiment of this application.

[0057] Figure 5 This is a flowchart of resource optimization and rendering provided for embodiments of this application;

[0058] Figure 6 This is a flowchart of the 3D car model rendering process provided in an embodiment of this application;

[0059] Figure 7 A schematic diagram of the graphics rendering apparatus provided in this application;

[0060] Figure 8 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0061] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0062] Mobile graphics rendering technology is widely used in business scenarios such as vehicle display, remote vehicle viewing, and vehicle configuration. It mainly consists of mobile application software (APP), 3D model resources, configuration parameters, and model display pages working together to achieve the visualization and interactive operation of vehicle exterior, interior, and status information.

[0063] In the aforementioned business scenarios, users often need to access the model display page on their mobile phones or tablets to rotate, zoom, switch configurations, or view the status of the 3D car model. Therefore, the mobile phone or tablet must not only load the 3D car model quickly, but also complete the corresponding graphic rendering processing in conjunction with the page functions.

[0064] In related technologies, many mobile car model display solutions often directly use models and materials from the design phase or high-precision resource links, performing unified frame-by-frame real-time rendering on mobile devices. While this approach can achieve good display effects on high-performance mobile devices, in actual business applications, it leads to problems such as large file sizes, long resource download times, noticeable lag upon initial page loading, unstable frame rates during continuous browsing, and high heat generation and power consumption over extended periods. This is especially problematic for vehicle marketing displays, remote car viewing, vehicle configurators, and car owner service apps, where users expect a stable and smooth car model browsing experience across different network conditions and performance levels on mobile devices.

[0065] Furthermore, in actual car model display businesses, users' perception of performance is not only reflected in whether the 3D car model "can be displayed," but also in "whether it opens instantly, whether it is smooth, whether it overheats, whether it consumes a lot of power, and whether it lags on the first launch." Therefore, if the aforementioned technologies are adopted, and the number of model faces is reduced from a data processing perspective, or placeholder images are introduced from an interface display perspective, although some problems can be alleviated locally, they cannot fundamentally improve the overall user experience of 3D car models in mobile apps.

[0066] To address the aforementioned issues, this application provides a high-performance graphics rendering solution for car models in mobile apps. This solution constructs a unified technical approach across three aspects: model resource optimization, rendering process optimization, and initialization optimization. It resolves the performance issues of car model display in various mobile operating systems (Android, iPhone, and open-source HarmonyOS, etc.), multi-engine environments (Web3D engine and C++ self-developed engine, etc.), and multi-scene scenarios (3D car model elements, special effects, car condition animations, parking reconstruction, rendering performance, etc.).

[0067] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0068] Figure 1 This is a flowchart illustrating the graphics rendering method provided in an embodiment of this application. This method can be applied to a mobile device, which acts as the execution terminal for the graphics rendering method, hosting the model display page and performing resource reading, shader processing, and graphics rendering. For example, the mobile device can be a smartphone, tablet, or an in-vehicle mobile terminal with graphics processing capabilities. Figure 1 As shown, the method may include:

[0069] Step 110: Obtain the 3D model of the target object, the configuration parameters of the target object, and the page functions of the model display page on the mobile device;

[0070] Step 120: Based on the page functions and configuration parameters, determine the key shader and key variants of the key shader in the shader set corresponding to the 3D model;

[0071] Step 130: Perform preprocessing operations on the key shader and its key variants. The preprocessing operations include at least one of pre-compilation processing and preheating processing.

[0072] Step 140: Extract the rendering object from the 3D model and save it to the layer to be rendered;

[0073] Step 150: Render the layer to be rendered using the key shader and key variant that have completed the preprocessing operation.

[0074] In this embodiment, the graphics rendering method can be used not only for vehicle marketing display pages, but also for vehicle configurators, vehicle control display pages, owner service pages, and other business scenarios involving 3D vehicle model displays.

[0075] In step 110 above, the target object can refer to a vehicle. In real life, vehicles have different configuration parameters, and vehicles with different configuration parameters have different corresponding 3D models.

[0076] The vehicle's configuration parameters reflect the configuration set in the current display state, which may include body color, wheel style, interior material, lighting status, open / closed status, or optional equipment status. The 3D model may include the vehicle's exterior model, interior model, or accessory models related to the configuration.

[0077] The 3D model includes multiple rendering objects; for example, the vehicle body can be one rendering object, and the headlights can be another.

[0078] In addition, the page functions of the model display page are used to represent the display and interaction capabilities supported by the current page, which may include functions such as whole vehicle browsing, partial zoom, configuration switching, appearance comparison, dynamic lighting effect display, and component visibility viewing.

[0079] In step 110, the mobile device can also work with the resource optimization device to implement the graphics rendering method provided in this application, so that the mobile device can directly obtain the three-dimensional model of the target object and the configuration parameters of the target object from the resource optimization device.

[0080] For example, taking a vehicle as the target object, the configuration parameters can refer to the vehicle model, while the 3D model can refer to the 3D car model corresponding to that model.

[0081] Resource optimization equipment can pre-optimize the resources of the initial 3D model corresponding to the vehicle to obtain a resource-slimmed 3D model, which makes it easier to transmit to the mobile terminal and reduces the resource consumption of the mobile terminal.

[0082] In addition to resource optimization devices, mobile devices can collect configuration parameters from multiple sources when retrieving them. Specifically, they can directly read the current vehicle model and default configuration from the page initialization parameters; or they can read configuration key-value pairs from the configuration results selected by the user on the previous page. After the configuration parameters enter the mobile device, they can be standardized according to preset fields, converting configuration content from different sources into configuration identifiers that the rendering engine can recognize.

[0083] When a mobile device retrieves page functionality, it can identify it based on the page template, front-end layout configuration, and function list. Specifically, the model display page can carry page function description data when loading, which records the display modules, interaction modules, and dynamic performance modules currently enabled on the page. After reading this description data, the mobile device parses the corresponding display capabilities into a set of function identifiers and binds this set to the vehicle's 3D model and configuration parameters. In this way, even if the same vehicle is displayed on the same model display page, different combinations of functions used by the user can produce different rendering effects.

[0084] In step 120 above, the critical shader is the shader selected from multiple candidate shaders in the shader set corresponding to the 3D model, based on the actual display requirements of the current page and the current configuration parameters of the target object. This shader is chosen to prioritize entering the rendering preparation process and is used to perform the core shading calculations that must be executed in the current scene. Critical variants are the specific compilation branches of the critical shader under different function switches, material combinations, lighting modes, or state configurations, used to adapt to the actual rendering requirements of different display configurations.

[0085] For example, continuing with the target object as a vehicle, the paint needs to be rendered as a key element in the 3D car model rendering process. Therefore, the "Paint Shader" can be selected as the key shader. If there is no "Paint Shader" during rendering, the final rendered 3D car model will be black, and the entire screen will crash.

[0086] Among them, the key shader "Car Paint Shader" may have 50 variants (such as red metallic, blue matte, white pearl, with normal and without normal). If the mobile device finds that the car is "red metallic" after reading the current configuration parameters and "normal mapping" is not enabled, it can directly discard 49 of the 50 variants, such as "blue matte", "white pearl", and "with normal", and perform subsequent preprocessing operations on the remaining key variant.

[0087] In addition, the page function in step 120 is used to limit which display capabilities the current model display page will actually trigger, and the configuration parameters are used to limit the appearance, material and state of the target object. Both participate in shader selection and variant convergence.

[0088] In the specific implementation of step 120, the mobile device, after obtaining the page functions and configuration parameters, first constructs a shader set for the 3D model. The shader set can come from the rendering engine's built-in shader library, the business shader list in the project resource package, and shader declaration information bound to the target object model's material.

[0089] Subsequently, the mobile app analyzes the page functionality and configuration parameters to determine the shading effects, material representations, and object states required for displaying the 3D model. After completing the above analysis, the mobile app selects key shaders from the shader set that correspond to the current page display requirements based on the page functionality and configuration parameters, and determines the key variants corresponding to each key shader.

[0090] In cases where there may be multiple candidate variants for the same key shader, mobile devices can retain only the key variants based on the actual display path that will be entered on the current page, thereby narrowing the scope of subsequent preprocessing.

[0091] In step 130 above, the preprocessing operation is used to process key shaders and key variants in advance before the actual rendering to reduce rendering blockage in the first frame. Pre-compilation processing is used to complete the compilation and linking of the corresponding program objects for key shaders and key variants in advance, while preheating processing is used to prepare key variants into a ready state that can be directly invoked, including establishing rendering state objects, driver-side cache records, material instance binding relationships, and necessary texture sampling states. In this step, key shaders and key variants can either enter the same preprocessing queue together or enter different queues according to their processing type, and be scheduled for execution by the mobile device based on the current load status.

[0092] When pre-compiling key shaders, mobile devices convert the text-based shaders into intermediate bytecode. This pre-compilation process primarily occurs before the 3D model is loaded. By translating human-written text code into an intermediate language (IR), the time-consuming "text reading, word segmentation, and syntax checking" during loading can be avoided. Without pre-compiling shaders, the first frame of the 3D model needs to be compiled on-site, which can easily lead to long loading times and "stuttering upon first loading," resulting in a poor user experience.

[0093] During the warm-up process for critical variants, the mobile device takes the pre-compiled intermediate language and calls the low-level interface of the Graphics Processing Unit (GPU) driver to compile it into directly executable "binary machine code," while simultaneously creating a complete rendering pipeline state object. This warm-up process is hardware-dependent and time-consuming. Without it, this process would occur during the DrawCall of the first frame, causing noticeable screen stuttering.

[0094] In step 130, before or during the user enters the model display page, the mobile device can determine the required shader set in advance based on the current vehicle configuration and page functions, and perform pre-compilation or preheating processing on the key shaders and high-frequency material variants (i.e., key variants) in the shader set.

[0095] For example, continuing with the target object as a vehicle, priority is given to preprocessing the shaders for vehicle paint, glass, shadows, ambient reflections, and key materials such as tires and interior trim. This process can be scheduled before page transitions, during resource loading, or during idle time to minimize first-frame blocking and improve initial scene initialization performance.

[0096] In practice, users are extremely sensitive to "first-time loading stuttering." Even when the frame rate is not low after stable operation in many scenarios, users still perceive the mobile application as unsmooth due to jitter or pauses when first entering the model display page. One major reason for this problem is that critical shaders and critical variants are only compiled or loaded upon first triggering. Therefore, step 130 pre-compiles critical shaders and warms up frequently used critical variants, moving the compilation work in the critical path forward to the loading stage, page transition stage, or idle time slice, reducing initial rendering blockage. While step 130 does not directly reduce model size or drawcalls, it can reduce jitter or pauses when the mobile app first enters the model display page, significantly improving the first frame experience and initialization experience.

[0097] In step 140 above, the rendering object refers to one or more objects selected from the 3D model of the target object that correspond to the current page functions and current configuration parameters.

[0098] For example, taking a vehicle as the target object, the rendering object can specifically be the entire vehicle body, wheels, windows, lights, interior panels, openable parts, or sub-objects corresponding to optional packages. The layer to be rendered is used to hold these rendering objects and receive subsequent rendering processing. In specific implementations, it can be a layer container in the rendering engine, a rendering queue group, a scene node set, or a list of objects corresponding to off-screen rendering targets. Storing rendering objects in the layer to be rendered essentially involves selecting and organizing objects for rendering based on the current display requirements before the actual drawing.

[0099] In step 150 above, the layer to be rendered is a set of rendering objects, providing the rendering engine with object references, material parameters, transformation matrices and shading path mappings; the key shaders and key variants that have completed the preprocessing operations are prepared shading resources and are directly bound to the drawing commands of the corresponding layer or the corresponding object to output graphic results consistent with the page functions and configuration parameters.

[0100] In practice, the mobile app first generates drawing batches sequentially based on the rendering order of the layers to be rendered. For each drawing batch, the rendering engine reads the mesh data, world transformation matrix, material instance, and key variant identifier of the rendered object from the layer entry, and queries the corresponding key shader program object in the shader cache. If the query result is marked as pre-compiled and pre-warmed, the program binding, constant buffer update, texture resource binding, and drawing command submission are completed directly. For multiple rendered objects in the base layer, if they share the same key shader and the same key variant, the mobile app can merge and submit them according to material instance and mesh batches to reduce state switching. For transparent and glowing layers, drawing is performed separately according to preset transparency sorting rules and glow overlay rules to ensure that the display results are consistent with the page's functional requirements.

[0101] The graphics rendering method provided in this application provides a way to filter out key shaders and key variants by using page functions and configuration parameters, and then perform preprocessing operations on the key shaders and key variants. This moves the initial shading preparation for graphics rendering forward, shortens the time when the mobile application first enters the model display page, avoids the "first entry lag" phenomenon during rendering, and improves the rendering effect.

[0102] In some embodiments, a key shader may be added to a pre-compilation queue; and a key shader may be added to a preheating queue; and the key shader in the pre-compilation queue may be pre-compiled during a target time period, and the key variant in the preheating queue may be preheated during a target time period.

[0103] The target time period includes at least one of the following: the time period before the mobile device switches to the display model page, the time period during which the mobile device loads the 3D model, and the idle time period of the mobile device.

[0104] In this embodiment, the pre-compilation queue may include multiple key shaders. Each key shader can be identified and distinguished by its shader identifier, and a priority flag can be configured for each key shader. Key shaders with higher priority can be pre-compiled first.

[0105] The preheating queue may include multiple critical variants, which can be identified and distinguished by variant identifiers. Priority tags can also be configured for each critical variant. Higher-priority critical variants can be preheated first.

[0106] During pre-compilation, the mobile app can read the source code of key shaders from the shader library, perform pre-compilation, and generate the compilation results corresponding to the key shaders. For scenarios where the graphics interface supports offline caching, the mobile app can write the compilation results to the local shader cache so that they can be reused when the same page functionality and configuration parameter combination re-enters the model display. For cases with many key variations, the mobile app can prioritize compiling key shaders directly related to the first frame, followed by key shaders related to configuration switching or local functions. After compilation, the mobile app can also record the compilation status, cache location, and availability flags of each key shader for direct querying in subsequent rendering stages.

[0107] Once the critical shaders in the pre-compilation queue have completed their pre-compilation, their compilation results (i.e., the executable code instructions generated by pre-compiling the critical shaders) can be directly used by the layers to be rendered.

[0108] During the warm-up process, the mobile device can create temporary material instances and a minimal rendering context, making a lightweight call on a critical variant unit. This lightweight call does not require outputting the result to the user-visible screen; instead, it completes shading procedural binding, rendering state assembly, texture slot binding, and driver resource preparation in the rendering backend. For example, a placeholder mesh or off-screen buffer can be used to trigger the initial binding process of the critical variant, allowing the driver layer to complete internal initialization before the actual rendering. If the critical variant depends on specific textures or material constants, the mobile device verifies whether the dependent resources have been loaded before warm-up. For dependent resources that have not yet been loaded, a placeholder binding can be established first, and an incremental warm-up can be performed after the resources arrive. In this way, when the actual rendering reaches the corresponding shading path, the critical variant is already in a directly callable state.

[0109] Once the critical variants in the preheating queue have completed their preheating, their corresponding rendering states can be directly reused during the first display.

[0110] This embodiment arranges the pre-compilation processing of key shaders and the pre-warming processing of key variants to be performed before page switching, during resource loading, or during idle time. This reduces the first-frame blocking when rendering the layers to be rendered and avoids the "first-entry stutter" phenomenon during rendering, thereby improving the rendering effect.

[0111] In other embodiments, it is possible to detect whether each object to be rendered in the 3D model has dynamic change features, which are features that produce visual changes during the rendering and display process; if dynamic change features exist, the object to be rendered is determined to be a dynamic rendering object; if no dynamic change features exist, the object to be rendered is determined to be a static rendering object; then the dynamic rendering objects in the 3D model are extracted and stored in the dynamic layer to be rendered; and the static rendering objects in the 3D model are extracted and stored in the static layer to be rendered.

[0112] In real-world 3D car model demonstrations, users spend most of their time browsing the car's exterior, changing colors, slowly rotating the view, or observing details. Only a portion of the rendered objects are constantly changing. If all rendered objects in the 3D car model were rendered frame-by-frame, it would not only waste CPU and GPU resources but also incur additional power consumption. Therefore, this embodiment uses layer splitting to separate dynamic and static rendered objects into different rendering layers. This allows for layered rendering, improving rendering flexibility and avoiding wasted graphics rendering performance on mobile devices.

[0113] In this embodiment, taking a vehicle as the target object as an example, after the 3D model (i.e. the 3D model of the vehicle) is loaded on the model display page of the mobile terminal, the mobile terminal can collect the state of the rendered object in the 3D model. The collected content includes the display and hiding state of the rendered object, position changes, angle changes, shape changes and visibility changes, and determines whether the rendered object has dynamic change characteristics based on the collection results.

[0114] The dynamic change characteristics can be represented by the object identifier, state value, change frequency, and change direction. The mobile device uses these to determine whether the rendered object needs to be updated in real time with user interaction or animation playback. For example, a rendered object that continuously performs opening and closing, blinking, rotation, or shape switching has dynamic change characteristics, is judged as a dynamic rendered object, and is written to a dynamic layer; while a rendered object that remains stable during the display process, such as the vehicle body, interior frame, and background decoration, does not have dynamic change characteristics, is judged as a static rendered object, and is written to a static layer.

[0115] In addition, after dynamic rendering objects and static rendering objects are encapsulated into independent rendering layers, the mobile device's layer manager organizes them according to the corresponding refresh strategy. The dynamic layer that encapsulates dynamic rendering objects participates in subsequent rendering in a real-time update manner, while the static layer that encapsulates static rendering objects supports cache reuse or low-frequency refresh.

[0116] For example, after loading 3D car model resources on a mobile device, layers are created based on whether the rendered objects in the 3D car model are continuously changing. Dynamic rendered objects such as flashing headlights, door and window opening animations, wheel rotations, partial transparency switching, particle effects, and the currently interacting focus object can be placed in dynamic layers; while static rendered objects such as the main body of the car body, static background, stable interior, and currently unchanged decorative objects are placed in static layers. This allows different refresh strategies to be used for different rendered objects.

[0117] In this embodiment, the rendered objects in the 3D model can be oriented and grouped according to the changing characteristics during the display process. Dynamic rendered objects and static rendered objects enter the corresponding layers respectively, thereby making the rendering preparation chain clearer, the layer processing during page switching and configuration display more concentrated, and further reducing the first frame rendering lag and local refresh fluctuations.

[0118] Furthermore, in some embodiments, after storing dynamic and static rendering objects in different layers, an appropriate rendering strategy can be applied to each layer. For example, a real-time rendering strategy can be used to render dynamic layers in real time; and a cache reuse strategy or a low-frequency refresh strategy can be used to render static layers in non-real-time.

[0119] In this embodiment, when the mobile rendering engine renders the dynamic rendering objects in the dynamic layer, it first draws the dynamic layer according to the current frame state, and updates its transformation matrix, material parameters or animation frame data in each rendering cycle, so that the dynamic rendering objects keep synchronized with the page interaction.

[0120] The static rendering objects in the static layer cache the corresponding frames in the graphics memory or texture cache after the first rendering is completed. When the cache reuse strategy is used to perform non-real-time rendering of the static rendering objects in the static layer, the cached result is directly read as the current frame output. When the low-frequency refresh strategy is used to perform non-real-time rendering of the static rendering objects in the static layer, the old cache is overwritten and re-rendered according to the preset cycle.

[0121] This embodiment enables static rendering objects to use cached result reuse or low-frequency refresh mechanisms, while dynamic rendering objects are kept updated in real time, thereby significantly improving performance efficiency while maintaining visual effects.

[0122] Specifically, in some implementations, a target condition corresponding to the low-frequency refresh strategy can be set. If the target condition is met, the static layer is re-rendered at preset intervals. If the target condition is not met, the rendering result of the static layer at a historical moment is reused as the rendering result of the static layer at the current moment using a cache reuse strategy.

[0123] The target conditions include at least one of the following: the configuration information of the target object is switched, the display perspective of the 3D model is adjusted, and the state of the static rendering object changes.

[0124] When no configuration parameter switching, display view adjustment, or static rendering object state change is detected (i.e., the target conditions are not met), the cached result is directly read as the current rendering output. When the target conditions are met, the static layer is re-rendered according to the preset cycle, overwriting the old cache. If a low-frequency refresh strategy is adopted for the static layer, its refresh cycle can be set according to mobile performance, page display complexity, and layer update requirements, so that the static layer only participates in redrawing when needed.

[0125] In this embodiment, the static layer can have its corresponding frame buffer data and texture data stored in the image caching unit of the mobile device. The caching control unit of the mobile device periodically checks whether the target condition is met. When the target condition is met, the caching control unit triggers a re-rendering of the static layer after a preset period, and overwrites or appends the new rendering result to the cache. When the target condition is not met, the caching control unit directly reads the most recent valid cache and outputs it to the model display page as the static layer rendering result at the current moment. The preset period can be configured according to the terminal performance, page refresh rate, and probability of change of the static rendering object. In practical applications, this period parameter can also be selected with other values, which are not limited in this application.

[0126] In this embodiment, a caching and reuse strategy is used to enable static layers to reuse existing rendering results when the content is stable, and to perform low-frequency updates when the content changes and the target conditions are met, thereby maintaining the visual consistency of static rendering objects while reducing the overhead of repeated rendering.

[0127] This implementation reduces the number of recalculations for static layers, allows for direct output of historical rendering results when the cache is hit, and enables timely synchronization of the display status through low-frequency refreshes when content changes and target conditions are met, thereby reducing the graphics rendering load on mobile devices and maintaining page display continuity.

[0128] In some embodiments, when rendering static and / or dynamic layers, key performance indicators of the mobile device are obtained; if the key performance indicators do not meet the preset rendering conditions, dynamic adjustment of rendering parameters is performed.

[0129] The key performance indicators include at least one of frame rate, number of draw calls, memory usage, device temperature and battery status. Dynamic adjustment of rendering parameters includes at least one of reducing the refresh rate of static layers, turning off non-critical effects or reducing post-processing effects, switching to low-precision models or low-quality materials, reducing the level of environmental reflections and limiting the number of critical variants loaded.

[0130] In this embodiment, the mobile device can simultaneously collect the current running frame rate, number of drawing calls, available memory, temperature sensor readings, and battery percentage during rendering, and compare the collected results with preset rendering conditions.

[0131] For example, failing to meet preset rendering conditions includes situations such as when the current frame rate is consistently lower than a set value, memory usage is close to the upper limit, or the device temperature rises. In such cases, the mobile device will adjust rendering parameters through parameter adjustment commands. For example, it may reduce the refresh rate of static layers, or turn off non-critical effects such as particles and halos, or reduce post-processing effects such as screen space reflections, depth of field, and anti-aliasing, or switch high-order reflections to low-order reflection modes, or replace high-precision models with low-precision models, etc., to ensure the overall smoothness of interaction between the user and the mobile application and the controllable power consumption of the mobile device.

[0132] For example, Figure 2 The shader pre-compilation and runtime scheduling flowchart provided for embodiments of this application is as follows: Figure 2 As shown, taking a vehicle as the target object, the display of a 3D vehicle model on a mobile device requires two processing steps: (1) pre-compilation or preheating before loading; (2) dynamic rendering at runtime.

[0133] The "pre-compilation or preheating before loading" step is completed before the 3D car model is loaded, ensuring that the pre-compiled or preheated results can be reused directly when the first frame enters the scene, avoiding page lag. The "runtime dynamic rendering" step is executed dynamically during the rendering process. It collects performance metrics in real time and adjusts and updates rendering parameters when the mobile device's graphics rendering performance is insufficient or power consumption is too high, allowing the mobile device's rendering module to continue rendering the 3D car model based on the updated rendering parameters.

[0134] By pre-compiling key shaders and warming up key variants, performance on mobile devices can be optimized when entering the scene in the first frame, avoiding page stuttering by waiting for the first rendering trigger to compile. During operation, performance metrics are continuously monitored, and resources and rendering strategies are dynamically adjusted to ensure a stable experience under different device conditions.

[0135] Furthermore, in some embodiments, after rendering the dynamic and static layers, the mobile device can overlay the dynamic and static layers to output the final image. Specifically, the rendering results of the dynamic and static layers can be overlaid to generate a 3D model image; then, the 3D model image can be displayed on the model display page.

[0136] In this embodiment, when rendering results are overlaid, the rendering engine combines the real-time pixel data corresponding to the dynamic layer with the historical cached pixel data or the currently refreshed pixel data corresponding to the static layer according to the layer hierarchy.

[0137] During compositing, the pixel coverage order can be processed based on transparency, depth information, and occlusion relationships to ensure that dynamic foreground components and static background components form a consistent 3D model image within the same frame. The composited image is written to the frame buffer and submitted to the model display page via the mobile graphics display interface.

[0138] After receiving frame data on the model display page, it is drawn onto the display area to achieve synchronized display of dynamic images such as vehicle appearance, tire rotation, light flashing, and door and window opening and closing with images of the vehicle body, interior, and fixed background.

[0139] In practical implementation, dynamic layers can correspond to areas such as wheels, headlights, door opening / closing areas, or status animation areas, while static layers can correspond to the main body of the vehicle, fixed structures of the cabin, basic base maps, or component images that do not change frequently with configuration. When dynamic and static layers are overlaid, mobile devices can composite the static layer as the bottom layer and the dynamic layer as the top layer according to a preset rendering order. When the dynamic layer is updated, the overlay is re-applied and output, ensuring that the 3D model image on the model display page remains consistent with the current interactive state.

[0140] In addition, the layer compositing process can be completed by the mobile GPU, or the graphics engine can complete pixel-level blending before submission for display. The specific implementation method can be configured according to the terminal's graphics interface capabilities.

[0141] For example, Figure 3 This is a schematic diagram of the layered rendering of dynamic and static layers provided in the embodiments of this application, such as... Figure 3 As shown, when users browse 3D car models on mobile devices, there is a characteristic of "partial dynamics and overall static". By dividing the rendering objects in the 3D car model into dynamic rendering objects and static rendering objects and performing differentiated rendering, the repeated rendering calculations of static rendering objects during the rendering process can be reduced.

[0142] This application embodiment separates and renders dynamic and static layers and overlays them before output. This allows the real-time changing parts and the reused parts to adopt appropriate rendering strategies. The overlaid 3D model image can be directly presented on the model display page, thereby maintaining the continuity and structural integrity of the image and ensuring that the display results after configuration switching, state changes and display perspective adjustments are consistent with the current data.

[0143] Furthermore, as mentioned above, the mobile device can also collaborate with the resource optimization device to implement the graphics rendering method provided in this application. Specifically, the resource optimization device and the mobile device work together to form the entire graphics rendering system architecture, which mainly includes three core parts: a resource optimization module, a mobile rendering execution module, and a runtime performance scheduling module.

[0144] In some embodiments, the resource optimization module can acquire the original 3D model resources of the target object and perform lightweight processing on the original 3D model resources to generate a 3D model.

[0145] The resource optimization module can run in development or asset creation environments to perform model structure analysis, mesh reduction, material refinement, mesh batching, and texture merging. Its goal is to slim down and refine the resources to suit mobile operating conditions before the 3D model assets are deployed to mobile devices.

[0146] During the lightweighting process, the resource optimization module can perform structural analysis on the original 3D model resources to identify target structures that can be removed, replaced, or merged, and perform batch processing on different sub-meshes to merge multiple drawing units into fewer rendering units; at the same time, it merges texture resources and establishes unified texture coordinates to reduce the number of texture switching times and memory usage.

[0147] In practical applications, lightweight 3D models can reduce resource size, reduce the number of rendering calls, and compress runtime memory usage while maintaining the vehicle body outline, key decorations, and main material representation.

[0148] This application embodiment reduces model complexity before rendering by acquiring the original 3D model resources and performing lightweight processing, making the 3D model more suitable for the graphics processing capabilities and storage conditions of mobile devices. This reduces resource loading pressure, lowers rendering overhead, and shortens model preparation time during subsequent display, thereby improving the rendering continuity and display smoothness of the 3D model page.

[0149] Furthermore, lightweighting can specifically include the following steps:

[0150] Step (1) Based on the analysis results obtained after structural analysis of the target object, the target structure in the original 3D model resource is removed or replaced to generate target resources adapted for mobile rendering.

[0151] The target structure includes at least one of the following: a structure with visual sensitivity below a preset sensitivity threshold, an invisible structure, and a long-term occluded structure.

[0152] Step (2) Batch processing of target sub-mesh in target resource. Target sub-mesh are sub-mesh with the same material properties, the same shader configuration, or the same rendering state.

[0153] Step (3) merge each target texture in the target resource into a texture atlas. The target texture is a texture whose size is smaller than a preset size threshold.

[0154] Step (4) Based on the texture coordinates of each target texture, establish a unified texture coordinate system for the texture atlas to generate a 3D model.

[0155] In step (1) above, a structural scan can be performed on the high-precision original car model based on the 3D car model resource to be displayed, to obtain the number of model faces, the number of materials, texture size, node level and visibility information. Then, a lightweight processing is performed based on this information, including deleting invisible structures inside the chassis, compressing the geometric precision of low-interest parts, and retaining the details of high-interest areas, to form mobile-adapted resources.

[0156] The target object can be structurally analyzed by the model processor. The structural analysis results can be generated by occlusion detection, view analysis and saliency evaluation. Based on this, the target structure can be deleted from the original resource or replaced with a low-face-count, low-skeleton-complexity or low-detail-level structure to obtain the target resource.

[0157] In step (2) above, multiple meshes are batch-processed and merged according to material properties and rendering status for the optimized target resource in order to reduce the number of rendering instructions.

[0158] Among them, target sub-mesh can be merged into the same batch according to the mesh grouping rules. When their material properties, shader configurations or rendering states are consistent, the batching can be completed through shared drawing commands.

[0159] In steps (3) and (4) above, while performing batch merging, multiple small textures can be integrated into one or more texture atlases and the corresponding UV coordinate data can be reconstructed.

[0160] The target texture can be selected by the texture filtering module based on a preset size threshold and packaged into a texture atlas. Then, the texture coordinate mapping relationship is reconstructed based on the layout position of each texture in the atlas, so that the model surface sampling can correctly point to the merged texture area. After step (4) is completed, material switching, texture binding and runtime DrawCall can be significantly reduced.

[0161] Furthermore, Figure 4 The graphics rendering system architecture diagram provided in the embodiments of this application is as follows: Figure 4As shown, after the resource optimization module completes the resource optimization process, the mobile rendering execution module continues the rendering process. The mobile rendering execution module runs in the mobile app and is responsible for loading the optimized target car model resources and dividing the object into dynamic and static layers according to preset rules. It is responsible for driving the local 3D engine to perform rendering and performs real-time rendering, cache reuse, and low-frequency refresh based on user interaction and object change states.

[0162] After the rendering execution module on the mobile device completes the rendering process, the runtime performance scheduling module performs dynamic scheduling. It is responsible for collecting key performance indicators during the scene operation, such as frame rate, number of draw calls, memory usage, device temperature and battery status, and dynamically adjusting model accuracy, effect level, layer refresh rate and shader variant loading strategy based on these indicators.

[0163] In this embodiment, the entire rendering process of the 3D model is not an optimization of a single rendering module, but a full-link collaborative architecture from before the resources enter the mobile device to the actual operation process on the mobile device.

[0164] For example, Figure 5 The resource optimization and rendering flowchart provided for the embodiments of this application is as follows: Figure 5 As shown, "resource optimization" and "runtime rendering" are continuous processes, not two separate stages. The aforementioned "resource optimization" determines the rendering efficiency of the subsequent processes.

[0165] This application's embodiments first eliminate or replace low-value structures, then merge mergeable sub-meshes and small-sized textures, and simultaneously reconstruct unified texture coordinates. This allows the generated 3D model to maintain the main appearance features of the target object while reducing resource size and rendering overhead, thus adapting to the loading and rendering capabilities of mobile devices. Because it reduces invalid structures, drawing calls, and texture switching, the rendering preparation time for the model when displayed on mobile devices is shorter, the first frame presentation is more stable, and the overall interactive response is more continuous.

[0166] In some implementations, the target object is still a vehicle, Figure 6 This is a flowchart of the 3D car model rendering process provided in the embodiments of this application, such as... Figure 6 As shown, it includes the following steps:

[0167] Step 1: Car model resource analysis and model optimization;

[0168] Based on the vehicle model resources to be displayed, a structural scan is performed on the high-precision original vehicle model resources to obtain information such as the number of facets, the number of materials, texture sizes, node levels, and visibility. Subsequently, lightweight processing is performed based on this information, including removing invisible structures inside the chassis, compressing the geometric precision of low-interest parts, and retaining details in high-interest areas, to create mobile-adapted resources.

[0169] Step 2: Mesh Batch and Texture Merge Processing;

[0170] For the optimized target resource, multiple meshes are batch-merged according to material properties and rendering status to reduce the number of rendering commands; at the same time, multiple small textures are integrated into one or more texture atlases, and the corresponding UV coordinate data is reconstructed. After this step, material switching, texture binding, and runtime draw calls can be significantly reduced.

[0171] Step 3: Separating static and dynamic scenes and constructing layers;

[0172] After loading the target car model resources on the mobile device, the layers are created based on whether the rendered objects are constantly changing. Dynamic rendered objects such as flashing headlights, animated parts, particle effects, and transparent transition objects can be placed in dynamic layers; static rendered objects such as the main body of the car body, background, and stable interior are placed in static layers. This allows different objects to use different refresh strategies.

[0173] Step 4: Perform layered rendering;

[0174] Dynamic layers are rendered in real time to ensure smooth animation and interactive effects; static layers are only re-rendered when configurations change, the viewpoint changes significantly, or the object's state changes, otherwise existing results are reused. Finally, the rendering and compositing module overlays the dynamic and static layers to output the final image.

[0175] Step 5: Precompile key shaders and warm up key variants;

[0176] Before a user enters the car model page, the system pre-determines the required set of shaders based on the current car model configuration and page functions. Key shaders related to paint, glass, reflections, shadows, and core materials are prioritized for pre-compilation or warm-up. This process can be scheduled before page transitions, during resource loading, or during idle time to minimize first-frame blocking.

[0177] Step 6: Runtime performance monitoring and dynamic scheduling;

[0178] During the rendering process, mobile device performance data is collected in real time. When insufficient performance or increased power consumption is detected, the system dynamically reduces the static layer refresh rate, disables non-critical effects, adjusts the reflection level, switches to a low-precision model, or reduces some post-processing effects to ensure overall stability.

[0179] Step 7: Configure the corresponding parameters for different platforms, engines, and business scenarios.

[0180] For different operating systems such as Android, iPhone, and open-source HarmonyOS, as well as different operating environments such as Web3D engines and self-developed C++ engines, the corresponding model accuracy level, layer refresh threshold, shader warm-up range, and material compression strategy can be configured according to the device capabilities to adapt to different edge performance conditions.

[0181] This implementation starts from the complete rendering chain. First, it controls the model complexity and the number of materials in the resource production stage to achieve model lightweighting. Then, it reduces the meaningless redrawing of static rendering objects by splitting layers in the runtime stage. Finally, it reduces the lag caused by the first initialization by shader preheating, so that the resource side, rendering side and initialization side form a collaborative optimization relationship.

[0182] Lightweighting the model is not simply about indiscriminately reducing polygon count; rather, it emphasizes the principle of "preserving quality in user-perceptible areas and reducing complexity in non-perceptible areas." For example, areas such as the car body outline, headlight edges, logos, and wheel rim appearance have a significant impact on user visual perception and should maintain relatively high precision. Meanwhile, the internal structure of the chassis, small parts that are frequently obscured, and decorative elements that are difficult to detect at mobile scaling can be replaced with low-poly models or eliminated entirely. This approach controls resource size without significantly sacrificing display quality.

[0183] In the rendering optimization section, this implementation method specifically addresses the typical business characteristics of "partially dynamic, overall static" in mobile vehicle model scenarios. Users spend most of their time browsing the vehicle's exterior, changing colors, slowly rotating the view, or observing local details; only a portion of the objects are truly constantly changing. If the entire scene is still rendered frame-by-frame, it not only wastes CPU and GPU resources but also incurs continuous additional power consumption. Therefore, by splitting layers, static rendering objects utilize cached results for reuse or a low-frequency refresh mechanism, while dynamic rendering objects are kept updated in real-time, thereby significantly improving performance efficiency while maintaining visual appeal.

[0184] In the shader initialization optimization section, this implementation assumes that users are extremely sensitive to the perception of "first-time loading stuttering." Many scenarios, even after stable operation, do not have low frame rates, but users may still perceive the application as unsmooth due to jitter or pauses upon first page loading. One major reason for this issue is that critical shaders and material variants are only compiled or loaded upon first triggering. Therefore, by preheating high-frequency variants, the compilation work in the critical path is moved forward to the loading phase, page transition phase, or idle time slice, reducing initial rendering blockage and significantly improving the first frame experience and initialization experience.

[0185] This implementation method is designed around the complete rendering link of the car model in the mobile app. It mainly includes: (1) combining model lightweighting, Mesh Batch and texture Merge into a unified resource optimization link; (2) proposing dynamic and static separation rendering in combination with business scenarios to reduce the invalid rendering of static content; (3) incorporating Shader pre-compilation into the car model display initialization process to improve the performance of the first scene; (4) through the runtime dynamic scheduling mechanism, the same solution can be compatible with devices of different performance levels.

[0186] The core of this implementation method is not to optimize a single step, but to form a complete closed loop through a combination of "model lightweighting + rendering optimization + shader initialization optimization". Its advantages are reflected in the following aspects: (1) Through model lightweighting, Mesh Batch and texture Merge technology, the model size can be reduced, network download and disk loading speed can be improved, and runtime memory overhead during rendering can be reduced. (2) Through the dynamic and static separation rendering method, the continuously changing content and static content are separated and processed separately, reducing DrawCall and GPU repetitive calculation in static browsing scenes, saving performance and reducing App power consumption. (3) Through Shader pre-compilation and key variant preheating mechanism, the initialization lag problem when entering the scene for the first time can be significantly improved, and the user's subjective feeling of smoothness can be improved.

[0187] Figure 7 A schematic diagram of the structure of the graphics rendering apparatus provided in this application is shown below. Figure 7 As shown, the graphics rendering apparatus 70 provided in this embodiment includes:

[0188] The acquisition module 710 is used to acquire the 3D model of the target object, the configuration parameters of the target object, and the page functions of the model display page on the mobile terminal;

[0189] The determination module 720 is used to determine the key shader and the key variant of the key shader in the shader set corresponding to the 3D model based on the page function and configuration parameters.

[0190] Processing module 730 is used to perform preprocessing operations on key shaders and key variants of key shaders, the preprocessing operations including at least one of pre-compilation processing and preheating processing;

[0191] Extraction module 740 is used to extract rendering objects from the 3D model and store them into the layer to be rendered.

[0192] Rendering module 750 is used to render the layers to be rendered using key shaders and key variants that have completed preprocessing operations.

[0193] Optionally, the processing module may be specifically used to: add key shaders to the pre-compilation queue; add key variants to the warm-up queue; perform pre-compilation processing on the key shaders in the pre-compilation queue during a target time period, the target time period including at least one of the time period before the mobile device switches to the display model page, the time period during which the mobile device loads the 3D model, and the idle time period of the mobile device; and perform warm-up processing on the key variants in the warm-up queue during the target time period.

[0194] Optionally, the extraction module can be specifically used for:

[0195] Detect whether there are dynamic change features in each object to be rendered in the 3D model. Dynamic change features are the features that produce visual changes during the rendering and display process.

[0196] If dynamic changes exist, the object to be rendered is determined to be a dynamically rendered object;

[0197] If there are no dynamic change characteristics, then the object to be rendered is determined to be a static rendering object;

[0198] Extract the dynamic rendering objects from the 3D model and store them in the dynamic layer to be rendered;

[0199] Extract static rendering objects from the 3D model and save them to the static layer to be rendered.

[0200] Optionally, the rendering module can be used to: render dynamic layers in real time using a real-time rendering strategy; and render static layers in non-real-time using a cache reuse strategy or a low-frequency refresh strategy.

[0201] Optionally, the rendering module can be used to re-render the static layer at preset intervals if the target conditions corresponding to the low-frequency refresh strategy are met; if the target conditions are not met, the rendering result of the static layer at a historical moment is reused using a cache reuse strategy as the rendering result of the static layer at the current moment.

[0202] The target conditions include at least one of the following: the configuration information of the target object is switched, the display perspective of the 3D model is adjusted, and the state of the static rendering object changes.

[0203] Optionally, the graphics rendering device also includes an overlay module for overlaying the rendering results of dynamic layers and static layers to generate a 3D model image; and displaying the 3D model image on the model display page.

[0204] Optionally, the graphics rendering apparatus further includes a parameter update module for obtaining key performance indicators of the mobile device when rendering static and / or dynamic layers. The key performance indicators include at least one of frame rate, number of draw calls, memory usage, device temperature, and battery status. If the key performance indicators do not meet the preset rendering conditions, dynamic adjustment of rendering parameters is performed. The dynamic adjustment of rendering parameters includes at least one of reducing the refresh rate of static layers, turning off non-critical effects or reducing post-processing effects, switching to low-precision models or low-quality materials, reducing the level of environmental reflection, and limiting the number of key variants loaded.

[0205] Optionally, the graphics rendering apparatus also includes a lightweight module for: acquiring the original 3D model resources of the target object; and performing lightweight processing on the original 3D model resources to generate a 3D model.

[0206] Optionally, the lightweight module can be used specifically for:

[0207] Based on the analysis results obtained after structural analysis of the target object, the target structure in the original 3D model resource is removed or replaced to generate a target resource adapted for mobile rendering; the target structure includes at least one of the following: a structure with visual sensitivity lower than a preset sensitivity threshold, an invisible structure, and a long-term occluded structure.

[0208] Batch processing of target sub-mesh in target resource, where target sub-mesh are sub-mesh with the same material properties, shader configuration, or rendering state;

[0209] Merge each target texture in the target resource into a texture atlas. The target texture is a texture whose size is smaller than a preset size threshold.

[0210] Based on the texture coordinates of each target texture, a unified texture coordinate system for the texture atlas is established to generate a 3D model.

[0211] The graphics rendering device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0212] Figure 8 A schematic diagram of the structure of the electronic device provided in this application. Figure 8As shown, the electronic device 80 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the electronic device 80 further includes a communication interface 803. The processor 801, memory 802, and communication interface 803 are connected via a bus 804.

[0213] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0214] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0215] In the above embodiments, it should be understood that the processor can be a central processing unit, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0216] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0217] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0218] This application also provides a vehicle including a vehicle body and the aforementioned electronic device disposed on the vehicle body, the electronic device performing the aforementioned method on the vehicle body.

[0219] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0220] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0221] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0222] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0223] The division of units is merely a logical functional division; 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 indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0224] 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.

[0225] In addition, the functional units in the various embodiments of the present invention 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.

[0226] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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 computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. 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.

[0227] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0228] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

[0229] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A graphics rendering method, characterized in that, Applied to mobile devices, the method includes: The page functions for acquiring the 3D model of the target object, the configuration parameters of the target object, and the model display page of the mobile terminal; Based on the page functions and the configuration parameters, determine the key shader and the key variant of the key shader in the shader set corresponding to the 3D model; Preprocessing operations are performed on the key shader and the key variants of the key shader, the preprocessing operations including at least one of pre-compilation processing and preheating processing; Extract the rendering object from the 3D model and store it in the layer to be rendered; The layer to be rendered is rendered using the key shader and key variant that have completed the preprocessing operation.

2. The method according to claim 1, characterized in that, The preprocessing operation on the key shader and its key variants includes: Add the key shader to the pre-compilation queue; Add the key variant to the warm-up queue; The key shaders in the pre-compilation queue are pre-compiled during a target time period, which includes at least one of the following: the time period before the mobile device switches to displaying the model display page, the time period during which the mobile device loads the 3D model, and the idle time period of the mobile device. The key variants in the preheating queue are preheated during the target time period.

3. The method according to claim 1, characterized in that, The step of extracting the rendering object from the 3D model and storing it in the layer to be rendered includes: Detect whether each object to be rendered in the 3D model has dynamic change features, where the dynamic change features are the features that produce visual changes during the rendering and display process; If the dynamic change characteristics exist, then the object to be rendered is determined to be a dynamic rendering object; If the dynamic change feature does not exist, the object to be rendered is determined to be a static rendering object; Extract the dynamic rendering object from the 3D model and store it in the dynamic layer to be rendered; Extract the static rendering object from the 3D model and store it in the static layer to be rendered.

4. The method according to claim 3, characterized in that, The rendering of the layer to be rendered includes: The dynamic layer is rendered in real time using a real-time rendering strategy. The static layer is rendered in non-real-time using a cache reuse strategy or a low-frequency refresh strategy.

5. The method according to claim 4, characterized in that, The step of using a cache reuse strategy or a low-frequency refresh strategy to perform non-real-time rendering of the static layer includes: If the target conditions corresponding to the low-frequency refresh strategy are met, the static layer is re-rendered at preset intervals. The target conditions include at least one of the following: the configuration information of the target object is switched, the display perspective of the 3D model is adjusted, and the state of the static rendering object changes. If the target condition is not met, the rendering result of the static layer at a historical moment is reused using the cache reuse strategy as the rendering result of the static layer at the current moment.

6. The method according to claim 3, characterized in that, Also includes: When rendering the static layer and / or the dynamic layer, the key performance indicators of the mobile device are obtained, including at least one of frame rate, number of drawing calls, memory usage, device temperature and battery status. If the key performance indicators do not meet the preset rendering conditions, a dynamic adjustment operation of the rendering parameters is performed. The dynamic adjustment operation of the rendering parameters includes at least one of the following: reducing the refresh frequency of the static layer, turning off non-critical effects or reducing post-processing effects, switching to low-precision models or low-quality materials, reducing the environmental reflection level, and limiting the number of key variants loaded.

7. The method according to any one of claims 3-6, characterized in that, After rendering the layer to be rendered, the method further includes: The rendering results of the dynamic layer and the rendering results of the static layer are superimposed to generate a 3D model image; The 3D model is displayed on the model display page.

8. The method according to any one of claims 1-6, characterized in that, Also includes: Obtain the original 3D model resource of the target object; The original 3D model resource is lightweighted to generate the 3D model.

9. The method according to claim 8, characterized in that, The process of lightweighting the original 3D model resource to generate the 3D model includes: Based on the analysis results obtained after structural analysis of the target object, the target structure in the original 3D model resource is removed or replaced to generate a target resource adapted to the mobile rendering; the target structure includes at least one of the following: a structure with visual sensitivity lower than a preset sensitivity threshold, an invisible structure, and a long-term occluded structure. The target sub-mesh in the target resource is batched, and the target sub-mesh is a sub-mesh with the same material properties, the same shader configuration, or the same rendering state. The target textures in the target resource are merged into a texture atlas, wherein the target textures are textures with a size smaller than a preset size threshold; Based on the texture coordinates of each target texture, a unified texture coordinate system for the texture atlas is established to generate the 3D model.

10. A graphics rendering apparatus, characterized in that, include: The acquisition module is used to acquire the 3D model of the target object, the configuration parameters of the target object, and the page functions of the model display page on the mobile terminal; A determination module is used to determine, based on the page functions and the configuration parameters, a key shader and a key variant of the key shader in the shader set corresponding to the 3D model; A processing module is configured to perform preprocessing operations on the key shader and the key variants of the key shader, the preprocessing operations including at least one of pre-compilation processing and preheating processing; The extraction module is used to extract the target rendering object from the 3D model and store it in the layer to be rendered; The rendering module is used to render the layer to be rendered using the key shaders and key variants that have completed the preprocessing operations.

11. An electronic device, characterized in that, include: Memory and at least one processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

12. A vehicle, characterized in that, include: The vehicle body and the electronic device as described in claim 11 disposed in the vehicle body.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

Images