Terrain rendering method and device, electronic equipment and storage medium

Abstract

The invention relates to a terrain rendering method and device, electronic equipment and a storage medium, and the method comprises the steps: constructing terrain grid data corresponding to a plurality of hierarchies in an offline manner, the terrain grid data corresponding to the plurality of hierarchies being used for describing a basic terrain and a mountain range in the basic terrain; performing bidirectional grid vertex alignment processing between adjacent hierarchies on the terrain grid data corresponding to the plurality of hierarchies offline to obtain multi-level terrain grid data; and performing online rendering based on camera parameters and the multi-level terrain grid data. According to the invention, both high-precision terrain presentation and high-performance cross-view smooth zooming are realized.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a terrain rendering method, apparatus, electronic device, and storage medium. Background Technology

[0002] Hardware limitations are a major bottleneck when rendering terrain on mobile devices. The relatively low performance of GPUs makes it difficult to efficiently handle complex graphics computations, resulting in rendering effects that fall short of high precision requirements. Simultaneously, limited memory resources pose a significant challenge to loading and storing terrain data. These factors combined make it extremely difficult to achieve both high-precision terrain rendering and high-performance, smooth cross-view scaling on mobile devices. Currently, existing technologies struggle to achieve a balance between "high-precision terrain rendering" and "high-performance, smooth cross-view scaling." Summary of the Invention

[0003] This disclosure provides a terrain rendering method, apparatus, electronic device, and storage medium to solve problems in related technologies. The technical solution of this disclosure is as follows: According to a first aspect of the present disclosure, a terrain rendering method is provided, the method comprising: Offline construction of terrain grid data corresponding to multiple levels, the terrain grid data corresponding to multiple levels are used to describe the basic terrain and the mountains in the basic terrain; Offline bidirectional grid vertex alignment processing is performed on the terrain grid data corresponding to the multiple levels to obtain multi-level terrain grid data; Online rendering is performed based on camera parameters and the multi-level terrain mesh data.

[0004] In one exemplary embodiment, the offline process performs bidirectional grid vertex alignment processing between adjacent levels on the terrain grid data corresponding to the multiple levels to obtain multi-level terrain grid data, including performing the following operation on any two adjacent levels of terrain grid data: Insert some boundary vertices of the first grid into the corresponding positions of the boundary of the second grid, and use them as new vertices in the second grid; Based on the vertices in the first grid and the vertices in the second grid, a target vertex is determined, and the target vertex is deleted from the first grid; Wherein, the first grid refers to the grid indicated by the terrain grid data corresponding to the lower level among any two adjacent levels, and the second grid refers to the grid indicated by the terrain grid data corresponding to the higher level among any two adjacent levels.

[0005] In one exemplary implementation, determining the target vertex based on the vertices in the first grid and the vertices in the second grid includes: For any vertex in the first grid, determine the corresponding mapping position of the vertex in the second grid, and determine the two vertices in the second grid that are adjacent to the mapping position as the first vertex and the second vertex, respectively; The height difference between the vertex and the first vertex is taken as the first height difference, and the height difference between the vertex and the second vertex is taken as the second height difference; If the difference between the first height difference and the second height difference is less than a preset threshold, and the vertex, the first vertex and the second vertex are collinear, the vertex is determined as the target vertex.

[0006] In one exemplary embodiment, the method further includes: Points in the first grid that are within the outer contour boundary are taken as vertices of the first grid, and points in the second grid that are within the outer contour boundary are taken as vertices of the second grid.

[0007] In one exemplary implementation, the offline construction of terrain grid data corresponding to multiple levels includes: Based on the topographic elevation map representing the basic terrain, the topographic elevation map is baked into a topographic mesh to obtain a multi-resolution topographic mesh; The 3D mountain model is placed in the terrain scene and the scene is baked. During the scene baking process, the multi-resolution terrain mesh and the 3D mountain model are loaded simultaneously to obtain mixed data. The mixed data includes multi-resolution terrain mesh data and height map. The multi-resolution terrain mesh data includes mountain texture map. Based on the mixed data, terrain grid data corresponding to the multiple levels are obtained respectively.

[0008] In one exemplary embodiment, the camera parameters include camera height, and the online rendering based on the camera parameters and the multi-level terrain mesh data includes: When the camera height is less than the preset height, render a 3D mountain model located within the field of view; When the camera height is greater than or equal to the preset height, target data located within the field of view is rendered. The target data comes from the multi-level terrain mesh data and includes the mountain texture map.

[0009] In one exemplary implementation, rendering the target data located within the field of view includes: Based on the camera height, determine the layer to be rendered; Based on the layer to be rendered, the target data within the field of view is extracted from the multi-level terrain mesh data, and the texture resources of the target layer are extracted from the multi-level terrain mesh data based on the field of view. The target layer is the upper level of the layer to be rendered. Render the target data.

[0010] In one exemplary implementation, the field of view is determined based on the camera height and camera position, and the extraction of the target data within the field of view based on the multi-level terrain mesh data includes: Each level from the level to be rendered to the highest level is determined as a valid level; Within the field of view, multiple grids are determined for each effective level; The data corresponding to the grids under each effective level are used as the target data.

[0011] In one exemplary implementation, the online rendering based on camera parameters and the multi-level terrain mesh data includes: If the highest-level terrain grid data needs to be loaded based on the camera parameters, the highest-level terrain grid data is loaded synchronously. If it is determined based on the camera parameters that non-highest level terrain grid data needs to be loaded, the non-highest level terrain grid data is loaded asynchronously. Always retain the highest-level terrain grid data from the most recently loaded layer.

[0012] In one exemplary implementation, the online rendering based on camera parameters and the multi-level terrain mesh data includes: If the conditions for rendering from high level to low level are met, and all fourth grids corresponding to the third grid are loaded, all fourth grids are displayed and the third grid is hidden. The third grid is any grid belonging to the high level within the field of view, and the fourth grid is a grid in the adjacent low level. The terrain range formed by the third grid coincides with the terrain range formed by all fourth grids.

[0013] According to a second aspect of the present disclosure, a terrain rendering apparatus is provided, the apparatus comprising: The basic data construction module is configured to perform offline construction of terrain grid data corresponding to multiple levels, which are used to describe the basic terrain and the mountains in the basic terrain. The vertex alignment module is configured to perform offline bidirectional grid vertex alignment processing between adjacent levels on the terrain grid data corresponding to the multiple levels respectively, to obtain multi-level terrain grid data; The rendering module is configured to perform online rendering based on camera parameters and the multi-level terrain mesh data.

[0014] In one exemplary embodiment, the vertex alignment module is configured to perform the following operation for any two adjacent levels of terrain mesh data: Insert some boundary vertices of the first grid into the corresponding positions of the boundary of the second grid, and use them as new vertices in the second grid; Based on the vertices in the first grid and the vertices in the second grid, a target vertex is determined, and the target vertex is deleted from the first grid; Wherein, the first grid refers to the grid indicated by the terrain grid data corresponding to the lower level among any two adjacent levels, and the second grid refers to the grid indicated by the terrain grid data corresponding to the higher level among any two adjacent levels.

[0015] In one exemplary implementation, the vertex alignment module is configured to perform: For any vertex in the first grid, determine the corresponding mapping position of the vertex in the second grid, and determine the two vertices in the second grid that are adjacent to the mapping position as the first vertex and the second vertex, respectively; The height difference between the vertex and the first vertex is taken as the first height difference, and the height difference between the vertex and the second vertex is taken as the second height difference; If the difference between the first height difference and the second height difference is less than a preset threshold, and the vertex, the first vertex and the second vertex are collinear, the vertex is determined as the target vertex.

[0016] In one exemplary implementation, the vertex alignment module is configured to perform: Points in the first grid that are within the outer contour boundary are taken as vertices of the first grid, and points in the second grid that are within the outer contour boundary are taken as vertices of the second grid.

[0017] In one exemplary implementation, the underlying data construction module is configured to perform: Based on the topographic elevation map representing the basic terrain, the topographic elevation map is baked into a topographic mesh to obtain a multi-resolution topographic mesh; The 3D mountain model is placed in the terrain scene and the scene is baked. During the scene baking process, the multi-resolution terrain mesh and the 3D mountain model are loaded simultaneously to obtain mixed data. The mixed data includes multi-resolution terrain mesh data and height map. The multi-resolution terrain mesh data includes mountain texture map. Based on the mixed data, terrain grid data corresponding to the multiple levels are obtained respectively.

[0018] In one exemplary implementation, the camera parameters include camera height, and the rendering module is configured to perform: When the camera height is less than the preset height, render a 3D mountain model located within the field of view; When the camera height is greater than or equal to the preset height, target data located within the field of view is rendered. The target data comes from the multi-level terrain mesh data and includes the mountain texture map.

[0019] In one exemplary implementation, the rendering module is configured to perform: Based on the camera height, determine the layer to be rendered; Based on the layer to be rendered, the target data within the field of view is extracted from the multi-level terrain mesh data, and the texture resources of the target layer are extracted from the multi-level terrain mesh data based on the field of view. The target layer is the upper level of the layer to be rendered. Render the target data.

[0020] In one exemplary implementation, the field of view is determined based on the camera height and camera position, and the rendering module is configured to perform: Each level from the level to be rendered to the highest level is determined as a valid level; Within the field of view, multiple grids are determined for each effective level; The data corresponding to the grids under each effective level are used as the target data.

[0021] In one exemplary implementation, the rendering module is configured to perform: If the highest-level terrain grid data needs to be loaded based on the camera parameters, the highest-level terrain grid data is loaded synchronously. If it is determined based on the camera parameters that non-highest level terrain grid data needs to be loaded, the non-highest level terrain grid data is loaded asynchronously. Always retain the highest-level terrain grid data from the most recently loaded layer.

[0022] In one exemplary implementation, the rendering module is configured to perform: If the conditions for rendering from high level to low level are met, and all fourth grids corresponding to the third grid are loaded, all fourth grids are displayed and the third grid is hidden. The third grid is any grid belonging to the high level within the field of view, and the fourth grid is a grid in the adjacent low level. The terrain range formed by the third grid coincides with the terrain range formed by all fourth grids.

[0023] According to a third aspect of the present disclosure, an electronic device is provided, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the terrain rendering method as described in any of the above embodiments.

[0024] According to a fourth aspect of the present disclosure, a computer storage medium is provided, wherein when instructions in the computer storage medium are executed by a processor of an electronic device, the electronic device performs the terrain rendering method described in any of the above embodiments.

[0025] According to a fifth aspect of the present disclosure, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the terrain rendering method described in any of the above embodiments.

[0026] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: The terrain rendering method provided in this disclosure can achieve a balance between "high-precision terrain presentation" and "high-performance, smooth cross-view scaling" by constructing multi-level terrain grid data offline and performing online rendering based on this data. Specifically, high-level terrain grid data can provide the macroscopic terrain of a large-scale map, while low-level grid data provides the detailed terrain of a small-scale map. Using multi-level terrain data for online rendering allows for dynamic loading of grid data at corresponding levels based on specific field-of-view requirements determined by camera parameters, ensuring rapid response during zooming in or out and avoiding stuttering or image distortion. By combining offline mapping with online rendering, high visual quality and operational smoothness are maintained whether observing from close range or from a distant perspective, providing users with a superior experience.

[0027] Furthermore, this disclosure solves the seam problem at the splicing point of mesh data at different levels during rendering by performing bidirectional mesh vertex alignment between adjacent levels during the offline mapping stage, ensuring a natural and seamless transition between adjacent levels. This enables the rendering of high-quality terrain and supports high-performance, smooth scaling across different viewpoints.

[0028] Overall, this disclosure uses multi-level terrain mesh data to support online rendering that "shows details from a low angle, preserves transitions from a mid-range angle, and controls performance from a high angle." It not only meets the display requirements for high-precision art assets (such as sharp mountains and vegetation details) but also takes into account the running performance and smoothness in large map scenes, filling the gap in related technologies in "balancing high precision and high performance".

[0029] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0030] The accompanying drawings, which are incorporated in and form part of this disclosure, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0031] Figure 1 This is a flowchart illustrating a terrain rendering method according to an exemplary embodiment; Figure 2 This is a schematic diagram of terrain baking according to an exemplary embodiment; Figure 3 This is a schematic diagram illustrating the splicing seam problem between different levels of meshes in the related art according to an exemplary embodiment; Figure 4 This is a schematic diagram illustrating a bidirectional mesh vertex alignment process according to an exemplary embodiment; Figure 5 This is a schematic diagram illustrating the target vertex determination process according to an exemplary embodiment; Figure 6 This is a schematic diagram illustrating the implementation effect of a full-link bidirectional mesh vertex alignment scheme according to an exemplary embodiment; Figure 7 This is a schematic diagram illustrating the process of obtaining multi-level terrain grid data in an offline phase according to an exemplary embodiment; Figure 8 This is a schematic diagram of a rendering process according to an exemplary embodiment. Figure 1 ; Figure 9 This is a schematic diagram of a rendering process according to an exemplary embodiment. Figure 2 ; Figure 10This is a block diagram of a terrain rendering apparatus according to an exemplary embodiment; Figure 11 This is a structural block diagram of a computer device according to an exemplary embodiment. Figure 1 ; Figure 12 This is a structural block diagram of a computer device according to an exemplary embodiment. Figure 2 . Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0033] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims. First, the technical terms involved in this disclosure are explained below: SLG: Strategy & Simulation Game, refers to strategy simulation games, such as games whose core gameplay revolves around "strategic planning" and "simulation management". LOD stands for Level of Detail. In this disclosure, it refers to a technique that optimizes rendering performance by dynamically adjusting the detail precision of the model / mesh. GPU: refers to Graphics Processing Unit, which in this disclosure is the hardware core responsible for performing graphics rendering calculations. MipMap: Multi-resolution ParvoMap, which discloses a method to generate "texture pyramids" of different resolutions for the same texture. High-resolution textures are used for near-field rendering, while low-resolution textures are used for far-field rendering. This not only improves the efficiency of far-field rendering but also avoids texture "aliasing" and "flickering" problems.

[0034] DrawCall: Drawing Call. In this disclosure, the central processing unit (CPU) can send a request to the GPU to trigger its rendering (such as rendering a terrain tile or a mountain model). Each request is a DrawCall. The GPU has limited capacity to process DrawCalls, and too many DrawCalls can lead to "waiting" and cause stuttering.

[0035] To facilitate understanding of this disclosure, a brief introduction to the background technology of this disclosure is provided first: As SLG games evolve, the demands on terrain rendering technology are gradually increasing, with the core development trajectory as follows: Early technology stage: Mainstream SLG games mainly use 2D static maps or simple 3D terrain. The map size is ≤10km×10km. The terrain uses a fixed precision grid + a single low-resolution height map, which can only present basic undulations (such as plains and gentle hills). There is no need to consider LOD switching. Because the coverage area is small and the precision requirements are low, the rendering pressure can be ignored, and there is no need to balance performance and precision.

[0036] Demand Upgrade Phase: SLGs have entered the "3D Large Map Era," with map sizes expanding to over 16km x 16km. This necessitates supporting switching between "low-angle observation of terrain details" and "high-angle viewing of the overall terrain landscape." At this point, a technical contradiction emerges: low-angle views require high-precision meshes and textures to depict subtle undulations, while high-angle views need to cover an extremely large area. Directly retaining the precision of low-angle views would lead to excessive GPU load and memory consumption on mobile devices, resulting in unsmooth gameplay.

[0037] Currently, there are two main types of terrain rendering solutions, but both have significant drawbacks: one drastically simplifies the performance control of high-view terrain precision, while the other simply copies desktop high-precision rendering solutions. Neither can balance "high-precision terrain" and "unlimited scaling smoothness" under the hardware limitations of mobile devices, becoming a key obstacle to upgrading the terrain experience in mobile SLG games. Take the core gameplay of a mobile SLG game as an example: players need to observe the distribution of various resources and the positions of enemy and friendly forces from a low perspective (camera height ≤ 50 meters). From this perspective, the terrain needs to show subtle undulations and texture details to reflect the game's high-quality art style. Then, players quickly switch to a high perspective (camera height ≥ 1000 meters) to view the global distribution of mountains and rivers and marching routes. From this perspective, the entire map's terrain layout needs to be fully presented, without any jumps or glitches during camera movement. This gameplay requires the terrain rendering solution to retain low-view detail while ensuring smooth high-view performance under the limited hardware resources of mobile devices, a core requirement that neither of the aforementioned solutions can meet.

[0038] For terrain rendering solutions that drastically simplify high-view terrain precision control performance, these solutions adapt to low-end mobile hardware through extreme simplification. This type of solution is the mainstream approach in mobile SLG games. The following key design considerations exist in the specific implementation of this type of solution: Terrain Mesh Precision Control: To maintain visual consistency of the terrain mesh as the camera moves near and far, this approach uses the same or similar terrain mesh polygon count at different camera heights. However, to ensure that the number of polygons rendered on screen at high angles remains within the capacity of mobile devices, the overall terrain mesh precision is controlled at a low level and is only used for rendering flat areas, rivers, and other gently undulating regions in the scene—by avoiding scenes with drastic terrain undulations, the deficiency in terrain mesh precision is masked. For terrain areas such as mountains that require rich vertex data, normal information, and texture details, this approach does not use terrain mesh rendering but instead displays them through independent 3D models. However, as the camera height increases, the number of mountains in the field of view increases exponentially, and mobile devices cannot handle the DrawCalls and rendering polygon counts of a large number of mountain models. Therefore, a "camera height threshold" is set: when the camera reaches this threshold, the mountain model is automatically switched to a simplified model with a very low polygon count, or a texture is directly used to replace the mountain model for display. This type of technical solution has the following disadvantages: Poor visual coordination: When switching the mountain model from high-poly to low-poly / texture, the difference in the visual effects before and after is obvious, which can easily lead to visual disharmony for players. Switching delay issue: Mobile devices have a lower resource loading rate. During the switching of mountain models, there is often a delay phenomenon where "the high-poly mountain is hidden, and the low-poly mountain / alternative texture takes a while to load and be displayed," which disrupts the continuity of scene rendering.

[0039] For solutions porting high-precision rendering from desktop to mobile, the core design concept is to directly adopt the PC-based framework of "uniformly tiled terrain mesh blocks + terrain heightmap sampling" to visualize various terrain types such as flatlands, highlands, rivers, and mountains within the scene. Only basic compression adaptation (such as slightly reducing texture resolution) is performed for mobile devices to match their hardware performance. The implementation of this type of solution is divided into an "art production stage" and a "rendering and execution stage," with the specific process as follows: Art production stage: Terrain details are directly sculpted using tools such as height brushes to generate the target terrain shape; terrain data is uniformly stored in a height map, where the RG channel records surface height information and the BA channel records terrain normal information, ensuring the basic data support for the three-dimensional shape of the terrain and the light and shadow reflection effects. Rendering execution phase: Instantiated rendering method is adopted to repeatedly render the preset uniformly tiled terrain mesh to cover the entire screen; in the vertex shader, each terrain mesh block samples the data of the corresponding position of the height map according to its own coordinates, and obtains the height fluctuation value and normal orientation of the vertex by decoding the height information, and finally presents the three-dimensional shape of the terrain. As the camera's field of view shifts from near to far, the vertex density of the uniformly tiled mesh is dynamically adjusted to achieve a smooth transition of the Level of Detail (LOD) across the global view. Different levels of the terrain heightmap's mipmap are sampled to maintain visual consistency in the terrain's visual appeal across different viewpoints. This type of solution suffers from three drawbacks due to its direct adoption of PC-based technical frameworks and lack of deep optimization for mobile devices: 1. The contradiction between data storage and rendering performance is prominent. When using heightmaps to store terrain data, mobile devices experience a significant burden on both file size and memory. For example, with a terrain precision of "1 meter / pixel," if the entire scene size is 16km × 16km, the terrain data alone would occupy over 1.5GB of space. During the rendering stage, all heightmap data within the visible area needs to be loaded, further exacerbating memory consumption. Simultaneously, the uniformly tiled terrain mesh generates a high number of rendered faces, directly causing fluctuations in the mobile rendering frame rate and even resulting in stuttering. 2. Poor mobile hardware compatibility The solution relies on real-time sampling of height maps by vertex shaders, resulting in extremely high GPU bandwidth overhead. While PC GPUs have sufficient bandwidth to handle this overhead, mobile GPUs generally have limited bandwidth, easily leading to a surge in device power consumption and overheating. Furthermore, this type of solution typically requires the use of Compute Shaders to implement core logic such as view frustum culling and LOD selection. However, most mobile devices have poor compatibility with Compute Shaders and insufficient computational performance, further degrading rendering efficiency. 3. Lack of high-precision mountain detail representation. Natural mountain ranges simultaneously contain flat areas, sharp ridgelines, and rich surface / rock details. However, this solution is limited by the precision of the uniformly tiled terrain mesh (typically supporting only 1 meter / pixel terrain resolution), making it unable to fully render these details. This results in a significant loss of information such as mountain sharpness and surface texture. To retain high-precision details, the number of polygons in the terrain mesh needs to be increased by tens of times, causing a sharp increase in the overall polygon count. Furthermore, because the terrain mesh is designed to be "uniformly tiled," flat areas and gently undulating areas such as rivers in the scene also incur high polygon count costs, creating an irreconcilable contradiction of "sacrificing global performance for local details."

[0040] In view of this, this disclosure proposes that it is necessary to focus on the field of computer graphics technology, specifically on the terrain rendering of mobile 3D strategy games (SLG), and to strive to solve the core contradiction in the "unlimited terrain scaling" scenario of mobile SLG games—to achieve a balance between "high-precision terrain rendering" and "smooth scaling across perspectives" under the conditions of low GPU performance, insufficient bandwidth, and limited memory on mobile hardware, so as to adapt to the rendering requirements of mobile 3D SLG games that support the switching between "microscopic detail observation and macro strategic view".

[0041] This disclosure addresses the core shortcomings of the aforementioned two types of terrain rendering schemes in the "unlimited scaling of terrain in mobile SLG games" scenario, proposing a targeted solution that balances "high-precision art asset display with mobile performance," and outlining the following design objectives: 1. Regarding the first type of solution mentioned above, the core problem lies in "sacrificing image quality for performance." Specifically, to adapt to low-end mobile devices, a large number of scene objects (such as vegetation and resource points) are directly hidden when the camera zooms out, and the terrain mesh and texture accuracy are drastically simplified. Simultaneously, a strategy of "replacing with low-polygon mountain models or pure textures at high angles" is adopted. This approach leads to two major drawbacks: first, a "sudden drop in image quality at high angles," resulting in a strong visual discontinuity from low to high angles, with players clearly perceiving a loss of scene details; second, "LOD switching delay," due to the limitations of mobile device resource loading speed, after high-poly mountains are hidden, low-poly mountains or alternative textures require a certain interval to appear, disrupting the continuity of scene rendering. Based on this, this disclosure proposes to construct a new terrain rendering solution. This new terrain rendering solution should avoid the visual discontinuity caused by object hiding and model simplification when zooming out, while eliminating the phenomenon of "low-poly delayed display after high-poly hiding" caused by slow mobile device resource loading, ensuring that the scene image quality maintains basic integrity and rendering continuity at high angles. 2. Regarding the second type of solution mentioned above, the core problem with this type of solution is that it is "not deeply optimized for mobile device characteristics": directly copying the "uniformly dense terrain grid blocks + terrain height map sampling" technology from the PC version, and only performing basic compression and adaptation on resources such as textures, resulting in three typical defects. First, "Memory / Package Overload": Taking a 16km×16km SLG game scene as an example, when using heightmaps to store terrain data, the terrain data alone occupies more than 1.5GB of space. During the rendering stage, all heightmap data within the visible range also needs to be loaded, further aggravating memory consumption, far exceeding the storage and memory capacity of mobile devices. Second, "Poor Mobile Hardware Adaptation": The solution relies on vertex shaders to sample heightmaps in real time, which consumes a lot of GPU bandwidth. However, mobile GPU bandwidth is generally limited, which can easily lead to a surge in device power consumption and overheating. At the same time, the solution often uses ComputeShader to implement logic such as view frustum culling and LOD selection, but most Android models have poor compatibility with ComputeShader and low computing performance, resulting in a decrease in rendering efficiency. Third, "Loss of Mountain Detail": The uniformly tiled terrain mesh used in the solution only supports a terrain resolution of 1 meter / pixel, which cannot fully present the sharp ridge lines of natural mountains, surface rock textures, and details such as vegetation on mountains. If the number of mesh faces is increased to retain details, it will lead to a large number of redundant faces in flat areas such as plains and rivers, further increasing the performance burden.

[0042] Based on this, the design goals of the new terrain rendering scheme proposed in this disclosure include reducing the size of the terrain data package for a 16km×16km scene to less than 300MB and the memory usage to less than 50MB; avoiding dependence on vertex shader sampling and Compute Shader, reducing the GPU bandwidth overhead and device heat generation on mobile devices; and fully preserving the sharp ridge lines of mountains and details such as vegetation on mountains at a resolution of 1 meter / pixel, while avoiding redundancy in the number of terrain mesh faces in flat areas.

[0043] Furthermore, this disclosure also proposes that the newly designed terrain rendering scheme based on the aforementioned first and second schemes should avoid the following defects: First, "uncontrolled DrawCalls and polygon counts," for example, DrawCalls may easily exceed the mobile GPU's capacity due to operations such as switching mountain models, or due to redundant polygon counts in uniform meshes, both of which cause fluctuations in mobile frame rates; Second, "abrupt visual transitions," due to reasons such as coarse LOD switching logic, it is impossible to achieve a smooth scaling from a low-angle view (high-precision detail observation) to a high-angle view (global sandbox view), and players can clearly perceive a "sudden jump." Therefore, this disclosure proposes that the design goals of the constructed new terrain rendering scheme also include: ensuring that the number of terrain-related DrawCalls does not change abruptly under all views, and that the number of DrawCalls does not exceed the mobile GPU's capacity due to uncontrolled DrawCalls, and that the number of polygons rendered on the same screen is always less than 50,000, ensuring stable mobile frame rates; achieving a smooth scaling transition from a low-angle view to a high-angle view, eliminating the visual discomfort of "sudden jumps." In summary, the main design goals of the new terrain rendering solution disclosed herein include: to build a terrain scaling system in mobile SLG games that "shows details from a low angle, maintains transitions from a medium angle, and controls performance from a high angle," which not only meets the display requirements of high-precision art assets (such as sharp mountains and vegetation details) but also takes into account the running performance and smoothness in large map scenes, filling the gap in the "balance between high precision and high performance" of related technologies.

[0044] Figure 1 This is a flowchart illustrating a terrain rendering method according to an exemplary embodiment. The terrain rendering method can be applied to an electronic device, which can be implemented independently by a server or a terminal, or collaboratively by a terminal and a server. The terminal can be, but is not limited to, physical devices such as smartphones, tablets, laptops, desktop computers, smart speakers, smart wearable devices, digital assistants, augmented reality devices, and virtual reality devices, and can also include software such as applications running on the physical device. The server can be, but is not limited to, a standalone server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms, etc. (Refer to...) Figure 1 As shown, the method includes the following steps.

[0045] In S110, terrain grid data corresponding to multiple levels are constructed offline. The terrain grid data corresponding to multiple levels are used to describe the basic terrain and the mountains in the basic terrain.

[0046] The process of building terrain mesh data offline involves dividing geographic information into different levels, each corresponding to a specific level of precision and detail. This layered design effectively reduces data redundancy while improving rendering efficiency. When describing basic terrain, higher-level data can provide overall landform features, while lower levels progressively refine the details to specific terrain features.

[0047] In one exemplary implementation, the offline construction of terrain grid data corresponding to multiple levels includes: First, based on the topographic elevation map representing the basic terrain, the topographic elevation map is baked into a terrain grid to obtain a multi-resolution terrain grid.

[0048] To facilitate art production and avoid learning new tools that could reduce scene editing efficiency, conventional terrain brush tools can be used for scene creation at this stage. Artists use brushes to draw scene heights and generate normals to finely refine the terrain, storing the terrain data in a terrain heightmap. However, this approach introduces an additional terrain mesh baking step to convert the terrain heightmap data into terrain mesh data. Specifically, map mesh baking first involves a comprehensive analysis of the terrain heightmap data to identify key feature points and regions. Next, using heightfield multi-resolution modeling technology, terrain models with different levels of detail are constructed based on the importance of feature points. Then, a simplification algorithm is used to optimize the constructed multi-resolution model, removing redundant vertices and faces to reduce complexity. During simplification, it is crucial to ensure that the overall shape and key features of the terrain remain unaffected, ultimately generating a multi-resolution terrain mesh.

[0049] Please refer to Figure 2 This illustrates a schematic diagram of terrain baking in this disclosure. Figure 2 (a) shows the input for terrain baking, which characterizes a uniformly tessellated grid and a height map. Figure 2 (b) shows the terrain mesh model obtained by terrain baking. Figure 2 (c) shows the rendering effect of the actual rendering of the terrain mesh model obtained by baking.

[0050] This disclosure proposes generating Level-of-Depth (LOD) terrain meshes to ensure consistent polygon count across different viewpoints from lowest to highest, while also guaranteeing smooth transitions. In a specific example, a 16km x 16km scene can be divided into 7 LODs. In LOD6, each terrain tile is 2000 meters long, resulting in an 8x8 LOD6 mesh across the entire scene. In LOD0, each terrain tile is 31.25 meters long, resulting in a 512x512 LOD0 mesh across the entire scene. Different polygon reduction parameters are configured for each LOD during generation. Compared to using terrain heightmap data to store the scene's terrain, this design requires only 300MB of overall package size (80% reduction compared to heightmaps) and only 50MB of memory (90% reduction compared to heightmaps). Furthermore, the terrain baking process can reduce the number of polygons rendered on screen. In areas with relatively flat terrain, fewer polygons are used, while in areas with rich detail such as slopes, riverbanks, and mountains, more polygons are retained. This design can achieve a polygon reduction rate of 90% in flat areas. Because the multi-resolution terrain mesh data obtained through terrain baking can support the use of conventional mesh rendering schemes during the rendering stage, avoiding vertex shader sampling, it is more friendly to mobile device performance.

[0051] Then, the 3D mountain model is placed in the terrain scene and scene baking is performed. During scene baking, the multi-resolution terrain mesh and the 3D mountain model are loaded simultaneously to obtain hybrid data. The hybrid data includes multi-resolution terrain mesh data and a height map. The multi-resolution terrain mesh data includes mountain texture maps. Furthermore, based on the hybrid data, terrain mesh data corresponding to the multiple layers is obtained.

[0052] In the terrain scaling system of SLG games, mountains, as a core visual element, always face the core contradiction between "rendering accuracy" and "mobile performance": low-angle views need to show sharp ridgelines and details such as vegetation on the mountains, while high-angle views need to control the polygon count and DrawCall to avoid lag. This paper proposes that if neither "model mountains" nor "terrain mountains" can be used alone, this contradiction should be completely resolved through a hybrid design of offline preprocessing and dynamic switching at runtime. This disclosure points out that current mainstream mountain rendering solutions fall into two categories, but both have fatal flaws in mobile SLG full-view scenes: Pure model mountain solution: Mountain details (such as sharp ridge lines and vegetation) are achieved through independent 3D models. The low-angle visual effect is excellent, but as the camera is raised, the number of mountain models in the field of view increases exponentially. Test data shows that the number of polygons on the screen can exceed 10 million at high angles. Even if the simplified model or pure texture is replaced, the excessive number of models still causes the DrawCall to exceed 2,000, far exceeding the GPU load limit of mobile devices (the recommended DrawCall for a single scene on mobile devices is usually <100), which directly causes a sharp drop in frame rate and device overheating. Pure terrain mountain solution: Artists sculpt mountain heights and normals using terrain brushes, storing the data in a terrain heightmap. At high viewpoints, this can be uniformly rendered using a terrain mesh, with controllable polygon count and draw calls. However, limited by the heightmap resolution (typically 1 meter / pixel), fine details cannot be rendered at low viewpoints. Issues arise such as sharp ridgelines showing noticeable misalignment due to insufficient heightmap sampling accuracy, and the inability to store vegetation details (the heightmap can only record the highest point of each pixel), resulting in a severe degradation in artistic quality. To preserve both low-angle detail and high-angle performance, this disclosure breaks down mountain processing into two main stages: "offline preprocessing" and "runtime rendering." The core is to generate "terrain data with integrated mountain details" in the offline stage to support the runtime switching. Then, in the rendering stage, depending on the viewpoint, the rendering option is to render a 3D mountain model or "terrain data with integrated mountain details."

[0053] In this disclosure, firstly, during the scene editing stage, the artists do not need to rely on complex brushes to sculpt mountains. Instead, they directly create a 3D mountain mesh model with complete details (including ridgelines, vegetation, and rock textures) and place it in the corresponding position in the scene. After entering the scene baking stage, the "top-view orthographic camera" is called (parameters match the scene scale: orthographic size 2000m, resolution 4096×4096, ensuring coverage of LOD6 mesh blocks). The multi-resolution terrain mesh and the 3D mountain model are loaded simultaneously, and the height data and normal data of both are rendered in real time and merged into the same rendering target. The final output is "mixed data containing basic terrain and mountain details". This process eliminates the need for artists to manually adjust the connection between terrain and mountains, while preserving the detailed advantages of the mountain model. Although the heightmap only stores the highest point, the details of the 3D model, such as vegetation and rocks, have already been integrated into the texture resources associated with the terrain mesh data through scene baking, solving the pain point of "detail loss" in pure terrain mountains. Specifically, a "hierarchical generation" logic is executed during scene baking. Since the mountain details are already integrated into the terrain mesh, there is no need to load a separate mountain model. This hierarchical design allows the logic of low-angle views relying on model detail preservation and high-angle views relying on terrain performance control to achieve a closed loop at the data level. S120. Offline, perform bidirectional grid vertex alignment processing between adjacent levels on the terrain grid data corresponding to the multiple levels to obtain multi-level terrain grid data.

[0054] The terrain mesh data corresponding to the multiple levels obtained in S110 can form LOD mesh data. However, if the rendering is performed directly based on this LOD mesh, seam problems will occur, resulting in poor rendering effect. Therefore, S120 performs bidirectional mesh vertex alignment processing between adjacent levels on the terrain mesh data corresponding to the multiple levels to obtain multi-level terrain mesh data. The multi-level terrain mesh data can be understood as an optimized LOD mesh data proposed in this disclosure.

[0055] This disclosure proposes that in a terrain scaling system, the connection between different Level of Dimension (LOD) meshes is crucial to visual smoothness. Due to the difference in vertex density among LOD meshes (e.g., LOD0 contains 1024 faces per block, while LOD1 contains only 512 faces per block), direct splicing easily leads to seam problems. Please refer to [reference needed]. Figure 3 It shows a schematic diagram of the splicing seam problem between different levels of mesh in the related technology proposed in this disclosure, which can be seen that Figure 3 Obvious seams appeared in the data. Therefore, this disclosure proposes that the seam problem should be completely resolved during the offline phase by optimizing the LOD mesh data. This disclosure proposes that current terrain rendering solutions generally require the mesh to simplify linearly with increasing LOD level. Seam problems are then addressed through vertex interpolation deformation or vertex snapping. However, both of these methods rely heavily on real-time calculations by the vertex shader, making them unsuitable for mobile games, and both require uniform meshes. To control the number of faces on mobile devices, this disclosure uses mostly irregular triangles in the simplified mesh, such as numerous merged triangles in flat areas, which do not meet the "uniform mesh" condition and cannot perform vertex snapping. Therefore, this disclosure provides a dedicated solution to address the seam problem: end-to-end bidirectional mesh vertex alignment from the lowest to the highest LOD level. Since it is impossible to predict which two mesh levels will be adjacent and connected at runtime, this disclosure establishes an end-to-end alignment logic that aligns from the lowest LOD level all the way to the highest LOD level. This ensures that the boundary vertices of any two adjacent LOD mesh levels match, avoiding uncontrollable seams at runtime. Alignment is performed offline and does not affect online rendering.

[0056] In the process of aligning low-level meshes to high-level meshes, the proposed technology typically uses linear interpolation to fit the redundant vertices at the boundary of the low-level mesh compared to the boundary of the high-level mesh between two adjacent vertices of the high-level mesh. This minimizes the number of newly added faces, but it may cause "abnormal protrusions" at the boundary vertices. If the low-level mesh is forced to align with these protrusions, the protrusions will propagate to the lower level, resulting in obvious terrain defects (such as abrupt small mounds) from a low-view perspective. To avoid the propagation of protrusions, the overall mesh face count will surge (more than 40% increase in tests), violating the face count control target for mobile devices. To address seam issues while minimizing the transmission of "abnormal protrusions" and preventing "facet surges," this disclosure proposes a specific alignment method for a full-link alignment logic that aligns from the lowest-level LOD to the highest-level LOD. In an exemplary implementation, please refer to... Figure 4 The diagram illustrates the bidirectional mesh vertex alignment process of this disclosure. The offline bidirectional mesh vertex alignment process is performed on the terrain mesh data corresponding to the multiple levels to obtain multi-level terrain mesh data. This includes performing the following operations on any two adjacent levels of terrain mesh data: S410. Insert some boundary vertices of the first grid into the corresponding positions of the boundary of the second grid, as new vertices in the second grid; wherein, the first grid refers to the grid indicated by the terrain grid data corresponding to the lower level in any two adjacent levels, and the second grid refers to the grid indicated by the terrain grid data corresponding to the higher level in any two adjacent levels.

[0057] The first mesh in the lower level and the second mesh in the higher level of any two adjacent levels have a corresponding relationship. The boundary vertices of the first mesh are inserted into the corresponding boundary positions of the second mesh to ensure that the second mesh does not lose its core details. S420. Based on the vertices in the first grid and the vertices in the second grid, determine the target vertex and delete the target vertex in the first grid.

[0058] In one exemplary implementation, please refer to Figure 5 This diagram illustrates the target vertex determination process of this disclosure. The determination of the target vertex based on the vertices in the first grid and the vertices in the second grid includes: S510. For any vertex in the first grid, determine the corresponding mapping position of the vertex in the second grid, and determine the two vertices in the second grid that are adjacent to the mapping position as the first vertex and the second vertex, respectively; take the height difference between the vertex and the first vertex as the first height difference, and take the height difference between the vertex and the second vertex as the second height difference; S520. If the difference between the first height difference and the second height difference is less than a preset threshold, and the vertex, the first vertex and the second vertex are collinear, the vertex is determined as the target vertex.

[0059] S510-S520 are used to filter out "redundant vertices" (target vertices) that need to be deleted. This process introduces a "height error threshold" (preset threshold), the size of which is not limited in this disclosure. By filtering the "redundant vertices" in the first grid after executing S510: a certain vertex in the first grid, and the first and second vertices in the second grid related to that vertex are determined, and then the first height difference and the second height difference in S510 are determined. For example, if the height difference between the first height difference and the second height difference is <0.5m, and the three vertices are "collinear" on the plane (without obvious terrain undulations), then the vertex is considered a target vertex and can be directly deleted; if the height difference is ≥0.5m or they are not collinear (such as the vertex in the first grid corresponding to ridge lines, slopes, or other details), then the vertex is retained. This step avoids convexity propagation (only retaining vertices with actual terrain significance), controls the increase in face count by deleting redundant vertices (the increase in face count can be controlled within 10% in the test), and solves the seam problem.

[0060] In one exemplary embodiment, the method further includes: using points in the first grid that are located within the outer contour boundary as vertices of the first grid, and using points in the second grid that are located within the outer contour boundary as vertices of the second grid.

[0061] In this implementation, points in the first grid that are located within the outer contour boundary are used as vertices of the first grid to perform S510-S520, and points in the second grid that are located within the outer contour boundary are used as vertices of the second grid to perform S510-S520.

[0062] This implementation takes into account that mesh alignment will inevitably increase the number of faces slightly, so it adds "boundary filtering" logic to reduce unnecessary alignment operations: the boundaries of each level of LOD mesh are divided into "outer contour boundaries", which are the boundaries that are not adjacent to the scene edge or other terrain blocks, and "inner boundaries" (the boundaries that connect with adjacent meshes of the same level). When aligning, only the "outer contour boundaries" are processed, and the inner boundaries are ignored. Taking the alignment of LOD0 and LOD1 as an example: LOD0 contains 4 adjacent terrain tiles (Tile_lb, Tile_lt, Tile_rb, Tile_rt). The right boundary of Tile_lb and the left boundary of Tile_rb, and the top boundary of Tile_lb and the bottom boundary of Tile_lt are "internal boundaries" (only connecting between grids of the same level, and are not related to higher-level LODs). When aligning, only the left boundary (left edge of the scene) and bottom boundary (bottom edge of the scene) of Tile_lb, the left boundary (left edge of the scene) and top boundary (top edge of the scene) of Tile_lt, the bottom boundary (bottom edge of the scene) of Tile_rb, and the top boundary (top edge of the scene) of Tile_rt need to be processed. This step can reduce the alignment calculation by 60%. When LOD1 and LOD2 are aligned, only the outer contour boundary of LOD1 is processed. Since the alignment is "transitive" (LOD0 has been aligned with LOD1, and LOD1 has been aligned with LOD2), no additional calculation is needed when LOD0 and LOD2 are connected. The previous alignment result can be used directly, which further reduces the cost of offline processing. By executing S510-S520 of this disclosure, and combining outer contour filtering during execution to reduce unnecessary alignment operations, and achieving end-to-end alignment, it can output LOD mesh data optimized to level 7, resulting in multi-level terrain mesh data in S120. In this multi-level terrain mesh data, there are no visible seams when meshes are connected between any adjacent levels, and the increase in the number of faces is controlled within 10%, perfectly adapting to the performance and accuracy requirements of mobile SLG.

[0063] Please refer to Figure 6 The diagram illustrates the implementation effect of the full-link bidirectional mesh vertex alignment scheme in this disclosure. Figure 6 (a) does not use the full-link bidirectional mesh vertex alignment scheme of this disclosure for LOD mesh optimization, so there are obvious seams in the rendering effect. Figure 6 (b) illustrates the optimization results after adopting the scheme of this disclosure. The seam problem is effectively eliminated, and the visual effect is smoother and more natural. Through comparison, it can be intuitively seen that the terrain mesh after the full-link bidirectional mesh vertex alignment process is more accurate in detail and the overall rendering quality is significantly improved. Moreover, the rendering of multi-level terrain mesh data optimized by the full-link bidirectional mesh vertex alignment scheme of this disclosure does not require real-time calculation by the vertex shader. This full-link bidirectional mesh vertex alignment scheme is applied to the irregular triangular mesh in this disclosure, avoiding "convexity propagation" and "face count surge".

[0064] Please refer to Figure 7This diagram illustrates the process of obtaining multi-level terrain mesh data in the offline phase of this disclosure. The diagram demonstrates the generation and optimization process of multi-level terrain mesh data. The flowchart on the left illustrates the process of creating multi-resolution terrain meshes: 1. Sculpting the basic terrain of the scene with brushes: Use terrain editing tools (such as terrain brushes in game engines) to sculpt the basic terrain undulations of the scene (such as the general shape of plains and hills).

[0065] 2. Terrain height map: The sculpted base terrain is converted into a "height map" (a grayscale image where pixel brightness corresponds to terrain height) to serve as the height data source for subsequent mesh generation.

[0066] 3. Create multi-resolution terrain meshes offline.

[0067] The flowchart on the right illustrates the process of creating hybrid data with mountain details: 1. Create a 3D mountain model and place it in the scene: Create a separate 3D mountain model with detailed structure and place it in the terrain scene to enhance terrain details (such as mountains and canyons).

[0068] 2. Scene baking: The height information of the 3D mountain model is fused with the terrain information represented by the multi-resolution terrain mesh of the basic terrain to generate hybrid data; 3. Construct terrain grid data corresponding to multiple levels.

[0069] The bottom process illustrates the optimization process for LOD mesh data: this process achieves alignment of low-level meshes to high-level meshes and smoothing of high-level meshes to low-level meshes.

[0070] all in all, Figure 7 It demonstrates the complete process of creating multi-level terrain mesh data offline, which not only achieves the design goal of reducing the storage size of the package, but also avoids the propagation of bulges and the surge in the number of faces, and solves the seam problem. Furthermore, the generated multi-level terrain mesh data also includes multi-scale information related to basic terrain and mountain details, which is sufficient to support online rendering on mobile devices.

[0071] S130. Perform online rendering based on camera parameters and the multi-level terrain mesh data.

[0072] During the rendering process, camera parameters play a crucial guiding role. They not only determine the position and direction of the viewpoint but also influence the selection of the rendering area and the level of detail. By using camera parameters, the system can intelligently determine which terrain mesh data needs to be loaded and rendered, effectively reducing unnecessary computational overhead. Furthermore, the application of multi-level terrain mesh data further optimizes this process, dynamically adjusting the required mesh precision based on changes in camera parameters. When the camera approaches a region, the system automatically switches to a higher-precision mesh to render more detail; conversely, when the camera moves away, a lower-precision mesh is used to conserve resources. This mechanism ensures a balance between rendering efficiency and visual effects, providing users with a smooth and realistic terrain display experience.

[0073] The terrain rendering method provided in this disclosure can achieve a balance between "high-precision terrain presentation" and "high-performance, smooth cross-view scaling" by constructing multi-level terrain grid data offline and performing online rendering based on this data. Specifically, high-level terrain grid data can provide the macroscopic terrain of a large-scale map, while low-level grid data provides the detailed terrain of a small-scale map. Using multi-level terrain data for online rendering allows for dynamic loading of grid data at the corresponding level based on the specific field of view requirements determined by camera parameters, ensuring rapid response when zooming in or out and avoiding stuttering or image distortion. By combining offline mapping with online rendering, high visual quality and operational smoothness are maintained whether observing from close range or from a distant perspective, providing users with a superior experience.

[0074] Furthermore, this disclosure solves the seam problem at the splicing point of mesh data at different levels during rendering by performing bidirectional mesh vertex alignment between adjacent levels during the offline mapping stage, ensuring a natural and seamless transition between adjacent levels. This enables the rendering of high-quality terrain and supports high-performance, smooth scaling across different viewpoints.

[0075] Overall, this disclosure uses multi-level terrain mesh data to support online rendering that "shows details from a low angle, preserves transitions from a mid-range angle, and controls performance from a high angle." It not only meets the display requirements for high-precision art assets (such as sharp mountains and vegetation details) but also takes into account the running performance and smoothness in large map scenes, filling the gap in related technologies in "balancing high precision and high performance".

[0076] In one exemplary embodiment, the camera parameters include camera height, and the online rendering based on the camera parameters and the multi-level terrain mesh data includes: rendering a 3D mountain model within the field of view when the camera height is less than a preset height; and rendering target data within the field of view when the camera height is greater than or equal to the preset height, wherein the target data comes from the multi-level terrain mesh data and the target data includes the mountain texture map.

[0077] This disclosure does not limit the preset height and can be adjusted according to actual conditions. For example, when the camera height is <900m, the data to be rendered corresponds to LOD0-2 level. At LOD0-2 level, mountain details need to be presented. The system renders a 3D mountain model while disabling terrain-related texture resources to ensure that vegetation and sharp ridgelines can be observed at low altitudes. When the camera height is ≥900m, the data to be rendered corresponds to LOD3-6 level. In this case, there is no need to display mountain details, so the 3D mountain model can be immediately disabled, and the mountain texture maps recorded in the multi-level terrain mesh data can be enabled. The advantage of this design is that it can dynamically adjust the rendering content according to the camera height, thereby optimizing rendering performance while ensuring visual effects. In this way, the system can flexibly switch between using 3D models and texture maps according to actual needs, avoiding unnecessary resource consumption. For example, at lower altitudes, users need to observe more detailed terrain features, and rendering a 3D mountain model can provide a more realistic visual experience; while at higher altitudes, the user's field of view expands, and the focus on details decreases. Switching to texture maps can not only maintain the overall visual experience but also significantly reduce the computational burden. This strategy is particularly well-suited for running on devices with limited hardware performance, such as mobile devices, making terrain rendering technology more universal and practical.

[0078] This design allows for complete mountain detail (preserving vegetation and ridgelines) in low-altitude perspectives (LOD0-2), and DrawCalls <20 and on-screen polygon count <50,000 in high-altitude perspectives (LOD3-6), while reducing terrain mesh volume by 25%. It perfectly solves the industry pain point of "the trade-off between accuracy and performance" in mobile SLG mountain rendering. Compared to pure model-based mountain solutions, this disclosure reduces DrawCalls by 99% in high-altitude perspectives, lowering the polygon count from tens of millions to 50,000. Compared to pure terrain-based mountain solutions, this disclosure preserves ridgelines and vegetation details in low-altitude perspectives, improving artistic precision by 300%. In one exemplary embodiment, rendering target data within the field of view includes: determining a rendering layer based on the camera height; extracting the target data within the field of view from the multi-level terrain mesh data based on the rendering layer, and extracting texture resources of the target layer from the multi-level terrain mesh data based on the field of view, wherein the target layer is the upper level of the rendering layer; and rendering the target data.

[0079] This disclosure proposes that, based on the determination of the rendering level, not only the target data to be rendered can be extracted, but also the texture resources (mountain texture maps) of the upper level of the rendering level can be extracted at the same time. This design is to avoid the error caused by "the terrain mountains are displayed but the textures are not loaded". The texture resources will be loaded one level in advance, for example, the LOD4 decals are loaded when LOD3, to ensure a smooth transition. In one exemplary implementation, please refer to Figure 8 It illustrates the rendering process of this disclosure. Figure 1 The field of view is determined based on the camera height and camera position. Extracting the target data within the field of view from the multi-level terrain mesh data based on the rendering layer includes: S810. Determine each level from the level to be rendered to the highest level as a valid level; S820. Within the field of view, determine multiple grids under each effective level; S830. The data corresponding to the grid under each effective level is taken as the target data.

[0080] In a mobile game application scenario, the solution disclosed herein can achieve the technical effects of real-time response to camera status, precise control of loading range and priority, and seamless switching between visible and invisible modes under the guidance of the game client's terrain loading and LOD management system. Moreover, this process is "uninterrupted, lag-free, and visually smooth". To achieve this goal, the rendering process disclosed herein can be divided into four stages: "state judgment → mesh loading → visible / invisible switching → resource recycling".

[0081] In the state determination phase, it is necessary to determine the effective layer and loading range in real time. Specifically, the system continuously monitors two key camera states: the current coordinates of the camera's center point (corresponding to its position on the terrain) and the camera's height (vertical distance from the ground) to determine the field of view to be rendered, and based on this field of view, determines which meshes of which LOD levels should be loaded.

[0082] Specifically, the "to-be-rendered level" can be calculated first. For example, based on the preset "camera height - to-be-rendered level" correspondence rule (e.g., height < 300 meters corresponds to LOD0, 300-600 meters corresponds to LOD1, and so on up to the highest LOD6), the LODN of the currently loading to-be-rendered level can be calculated. Then, to avoid the "unloaded mesh at the edge of the view" discontinuity when the camera moves, the system determines "LODN to the highest LOD6" as valid levels and loads the mesh data in these levels according to the view. The view to be rendered can be slightly larger than the actual view to be displayed, for example, it can be 1.2 times the actual view to be displayed, ensuring that new data loading and rendering are not frequently triggered when the camera moves slightly. For example, if the camera height is 900 meters (corresponding to LOD3), the system will load meshes at four levels: LOD3, LOD4, LOD5, and LOD6, ensuring the accuracy of the current view while reserving resources for higher LOD levels when the camera is raised.

[0083] In one exemplary embodiment, a rendering process of this disclosure is illustrated. Figure 2 The online rendering based on camera parameters and the multi-level terrain mesh data includes: S910. If it is determined based on the camera parameters that the highest-level terrain grid data needs to be loaded, the highest-level terrain grid data is loaded synchronously. S920. If it is determined based on the camera parameters that non-highest level terrain grid data needs to be loaded, the non-highest level terrain grid data is loaded asynchronously; S930. Always retain the highest-level terrain grid data from the most recently loaded layer.

[0084] This disclosure proposes prioritizing resources during the grid loading process. Specifically, the system prioritizes resources based on their Level of Detail (LOD) importance to avoid lag caused by loading all resources simultaneously. The core principle stems from the logic that "high LOD determines the overall framework, while low LOD supplements details." Highest priority: LOD6 mesh synchronous loading For example, if the multi-level map mesh data includes 7 levels from LOD0 to LOD6, LOD6 is the simplest mesh in the entire scene (e.g., only 8×8 blocks, each with only 16 faces), responsible for building the "global outline" of the terrain from a high perspective. If LOD6 is not loaded in time, a "terrain blank" will appear when the camera zooms out. Therefore, the system will force "synchronous loading" of LOD6—that is, suspend other non-critical operations and prioritize ensuring that the LOD6 mesh and basic textures are loaded, completely avoiding the high-view-angle artifacts. Normal priority: Asynchronous loading of non-LOD6 meshes Except for LOD6, all other mesh levels use "asynchronous loading": the system loads the resources of these meshes (including mesh models, terrain textures, detailed textures, etc.) in the background frame by frame, without affecting the player's current operation. At the same time, they are loaded in descending order of LOD level—for example, LOD5 is loaded first, then LOD4, ensuring that when the camera slowly pans down from a high angle, the next higher LOD level is ready in advance, preventing details from suddenly popping up. During the loading process, the system will also check the resource loading status in real time. Only when all associated resources (mesh + texture + control data) of a mesh are loaded will it be marked as "displayable" and the mesh can be considered to be loaded. In one exemplary implementation, the online rendering based on camera parameters and the multi-level terrain mesh data includes: If the conditions for rendering from high level to low level are met, and all fourth grids corresponding to the third grid are loaded, all fourth grids are displayed and the third grid is hidden. The third grid is any grid belonging to the high level within the field of view, and the fourth grid is a grid in the adjacent low level. The terrain range formed by the third grid coincides with the terrain range formed by all fourth grids.

[0085] This implementation embodies the visibility switching logic of this disclosure. After the low-level LOD mesh is loaded, the system will automatically trigger the "visibility switching between the high-level parent mesh and the low-level child mesh". The core logic is to "replace the simplified parent mesh with a more refined child mesh" to ensure that details naturally emerge when the view is zoomed in.

[0086] For example, if a parent grid (e.g., a grid in LOD1) corresponds to four child grids (e.g., four grids in LOD0), and their coverage areas overlap, if all four child grids are marked as "displayable," then once they are all loaded, the system will immediately hide the parent grid and simultaneously display these four child LOD grids. For instance, when four child grids of LOD0 covering the same geographic area under a grid in LOD1 are loaded, when the player zooms in on the corresponding area, they will see the terrain smoothly transition from the simplified effect of LOD1 to the refined effect of LOD0 (e.g., seeing more slope textures and small undulations), without any "jump." The system will periodically iterate through all loaded LOD grids, checking the loading progress of the child grids (e.g., by iterating through the child grid list to determine if all are in a displayable state). Once the condition is met, the switching will be performed automatically, without requiring manual triggering by the player. In some implementations, during the resource reclamation phase, as the camera moves, some previously loaded meshes may extend beyond the screen's display area. In such cases, the system will automatically execute "unloading logic": Determine the unloading range: Based on the new center point of the camera, recalculate the current field of view that should be retained. Grids that are outside the field of view (regardless of LOD level) will be marked as "to be unloaded". Safe resource uninstallation: The system will first hide the mesh to be uninstalled, and then release the memory it occupies (including mesh data, texture resources, etc.) in the background to avoid screen flickering caused by directly uninstalling the displayed mesh. At the same time, the "most recently loaded LOD6 mesh" will be retained - because LOD6 has very few polygons, retaining it can avoid reloading when the camera zooms up quickly, further improving smoothness. In summary, the terrain rendering solution provided in this disclosure has the following unique and beneficial effects: 1. Significantly reduced memory and package resource consumption, alleviating storage pressure on mobile devices. Qualitative results: It breaks through the resource bottleneck of "height map storage" in traditional PC porting solutions, and achieves lightweight storage of terrain data through offline grid baking and LOD grading; Quantitative results: For a 16km×16km SLG game scene, the package size is reduced from 1.5GB of the traditional height map solution to less than 300MB (reduction of 80%), and the runtime memory usage is reduced from hundreds of MB to less than 50MB (reduction of 90%), adapting to the storage and memory limitations of low-end mobile devices. 2. Significantly improved rendering performance, ensuring smooth operation on mobile devices. Qualitative effect: By using "differentiated LOD polygon reduction", "mountain blending rendering", and "DrawCall merging", a balance is achieved between "global view" and "performance consumption"; Quantitative results: The number of polygons rendered on the same screen for terrain is stably controlled within 50,000 polygons under full view (over 10 million polygons under high view in traditional pure model solution), the number of terrain-related draw calls is ≤20 (over 2000 under high view in traditional pure model solution), the frame rate on mobile devices is stable at ≥30fps, and there is no stuttering; at the same time, real-time calculation of vertex shaders is avoided, reducing GPU bandwidth overhead by 30%, reducing device heat generation and power consumption. 3. Improved image quality and smoother scaling transitions enhance the player experience. Qualitative effect: It solves the three major visual problems of related technologies, namely "sudden drop in image quality at high viewing angles", "LOD switching delay" and "seam flaws", and achieves a stepless scaling experience of "showing details at low viewing angles and preserving the overall picture at high viewing angles". Quantitative effects: The sharp ridgelines of mountains and high-precision details such as vegetation on mountains are preserved at low angles (the artistic precision is improved by 300% compared to the pure terrain solution); the LOD switching latency rate is reduced from 20% in the current solution to 0%, with no "sudden jumps"; the terrain seam defect rate is reduced from 15% in the traditional solution to 0%, and the visual transition smoothness is improved by 100%. 4. Improved art production efficiency reduces the cost of creating ultra-large maps. Qualitative effect: Replacing the traditional "manual brush sculpting of terrain mountains" with "automated mountain merging and baking" reduces repetitive work for artists; Quantitative effect: The production time for mountains in a 16km×16km scene is reduced by 80% and no art adjustments are needed for LOD transition details, improving the efficiency of later iterations by 60%. 5. Highly compatible, adaptable to all types of mobile SLG game scenarios. Qualitative effects: It does not rely on Compute Shader, supports mixed rendering of more than 16 surface textures, and can adapt to complex SLG terrains such as "plains, mountains, rivers, cities"; Quantitative results: 100% compatibility with mid-to-low-end models such as Snapdragon 660 and iPhone 6s, and stable performance even in complex terrain scenarios. In general, the terrain rendering provided in this disclosure features the following innovative designs: 1. A hybrid rendering scheme of "mountain model + hybrid data" was proposed. Related technologies only include simple mountain model solutions or simple terrain mountain solutions. The former will cause DrawCall and polygon count to explode at high altitudes, while the latter will cause loss of detail at low altitudes. This disclosure obtains multi-level map mesh data including mountain textures through baking in the "offline" stage, which supports flexible switching between different levels at runtime. It realizes "displaying 3D models (preserving details) at low altitudes (LOD0-2) and displaying terrain mountains (controlling performance) at high altitudes (LOD3-6)", and loads mountain texture maps one level in advance to avoid errors, fundamentally solving the core contradiction between "accuracy and performance". 2. A joint treatment scheme for offline bidirectional alignment is proposed. Related technologies are not suitable for handling seams in irregular meshes. This disclosure provides a solution for handling irregular meshes. This solution performs bidirectional alignment of vertices between adjacent layers to eliminate seams. In addition, it reduces invalid alignment by 90% by combining "boundary filtering". It both convex transfer and controls the increase in the number of faces to ≤10%, which is very suitable for the alignment of offline simplified irregular meshes. 3. Propose a priority-based LOD loading scheduling logic. Current solutions mostly use "single priority asynchronous loading" (which is prone to errors in high-angle shots or delays in low-angle shots); this disclosure proposes to load multiple effective layers according to different priorities based on the camera height, and set the highest layer to be loaded synchronously (to prevent errors), and the rest to be loaded asynchronously (sorted by level)", thus satisfying both "no delay" and "no errors".

[0087] 4. Propose an offline baking solution. This disclosure can perform terrain baking and scene baking to obtain terrain mesh data corresponding to multiple levels. During the scene baking process, the height / normal data of the 3D mountain model is automatically merged with the basic terrain into "hybrid data", realizing the automatic generation of mountain data and LOD adaptation. Figure 10 This is a block diagram illustrating a terrain rendering apparatus according to an exemplary embodiment. The apparatus includes: The basic data construction module 1010 is configured to perform offline construction of terrain grid data corresponding to multiple levels, which are used to describe the basic terrain and the mountains in the basic terrain. Vertex alignment module 1020 is configured to perform offline bidirectional grid vertex alignment processing between adjacent levels on the terrain grid data corresponding to the multiple levels respectively, to obtain multi-level terrain grid data; The rendering module 1030 is configured to perform online rendering based on camera parameters and the multi-level terrain mesh data.

[0088] In one exemplary embodiment, the vertex alignment module 1020 is configured to perform the following operations for any two adjacent levels of terrain mesh data: Insert some boundary vertices of the first grid into the corresponding positions of the boundary of the second grid, and use them as new vertices in the second grid; Based on the vertices in the first grid and the vertices in the second grid, a target vertex is determined, and the target vertex is deleted from the first grid; Wherein, the first grid refers to the grid indicated by the terrain grid data corresponding to the lower level among any two adjacent levels, and the second grid refers to the grid indicated by the terrain grid data corresponding to the higher level among any two adjacent levels.

[0089] In one exemplary embodiment, the vertex alignment module 1020 is configured to perform: For any vertex in the first grid, determine the corresponding mapping position of the vertex in the second grid, and determine the two vertices in the second grid that are adjacent to the mapping position as the first vertex and the second vertex, respectively; The height difference between the vertex and the first vertex is taken as the first height difference, and the height difference between the vertex and the second vertex is taken as the second height difference; If the difference between the first height difference and the second height difference is less than a preset threshold, and the vertex, the first vertex and the second vertex are collinear, the vertex is determined as the target vertex.

[0090] In one exemplary embodiment, the vertex alignment module 1020 is configured to perform: Points in the first grid that are within the outer contour boundary are taken as vertices of the first grid, and points in the second grid that are within the outer contour boundary are taken as vertices of the second grid.

[0091] In one exemplary implementation, the basic data construction module 1010 is configured to perform: Based on the topographic elevation map representing the basic terrain, the topographic elevation map is baked into a topographic mesh to obtain a multi-resolution topographic mesh; The 3D mountain model is placed in the terrain scene and the scene is baked. During the scene baking process, the multi-resolution terrain mesh and the 3D mountain model are loaded simultaneously to obtain mixed data. The mixed data includes multi-resolution terrain mesh data and height map. The multi-resolution terrain mesh data includes mountain texture map. Based on the mixed data, terrain grid data corresponding to the multiple levels are obtained respectively.

[0092] In one exemplary implementation, the camera parameters include camera height, and the rendering module 1030 is configured to perform: When the camera height is less than the preset height, render a 3D mountain model located within the field of view; When the camera height is greater than or equal to the preset height, target data located within the field of view is rendered. The target data comes from the multi-level terrain mesh data and includes the mountain texture map.

[0093] In one exemplary embodiment, the rendering module 1030 is configured to perform: Based on the camera height, determine the layer to be rendered; Based on the layer to be rendered, the target data within the field of view is extracted from the multi-level terrain mesh data, and the texture resources of the target layer are extracted from the multi-level terrain mesh data based on the field of view. The target layer is the upper level of the layer to be rendered. Render the target data.

[0094] In one exemplary implementation, the field of view is determined based on the camera height and camera position, and the rendering module 1030 is configured to perform: Each level from the level to be rendered to the highest level is determined as a valid level; Within the field of view, multiple grids are determined for each effective level; The data corresponding to the grids under each effective level are used as the target data.

[0095] In one exemplary embodiment, the rendering module 1030 is configured to perform: If the highest-level terrain grid data needs to be loaded based on the camera parameters, the highest-level terrain grid data is loaded synchronously. If it is determined based on the camera parameters that non-highest level terrain grid data needs to be loaded, the non-highest level terrain grid data is loaded asynchronously. Always retain the highest-level terrain grid data from the most recently loaded layer.

[0096] In one exemplary embodiment, the rendering module 1030 is configured to perform: If the conditions for rendering from high level to low level are met, and all fourth grids corresponding to the third grid are loaded, all fourth grids are displayed and the third grid is hidden. The third grid is any grid belonging to the high level within the field of view, and the fourth grid is a grid in the adjacent low level. The terrain range formed by the third grid coincides with the terrain range formed by all fourth grids.

[0097] Regarding the apparatus in the above embodiments, the specific manner of each step has been described in detail in the embodiments of the foregoing method, and will not be elaborated here.

[0098] Please refer to Figure 11 It illustrates the structural block of a computer device provided in an exemplary embodiment of this disclosure. Figure 1 The computer device can be a terminal. This computer device is used to implement the terrain rendering method provided in the above embodiments. Specifically: Typically, computer device 1100 includes a processor 1101 and a memory 1102.

[0099] Processor 1101 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1101 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1101 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In an exemplary embodiment, processor 1101 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In an exemplary embodiment, processor 1101 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0100] The memory 1102 may include one or more computer-readable storage media, which may be non-transitory. The memory 1102 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In an exemplary embodiment, the non-transitory computer-readable storage medium in the memory 1102 is used to store at least one instruction, at least one program, code set, or instruction set, configured to be executed by one or more processors to implement the terrain rendering method described above.

[0101] In one exemplary embodiment, the computer device 1100 may optionally include a peripheral device interface 1103 and at least one peripheral device. The processor 1101, memory 1102, and peripheral device interface 1103 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1103 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 1104, a touch display screen 1105, a camera assembly 1106, an audio circuit 1107, a positioning assembly 1108, and a power supply 1109.

[0102] Those skilled in the art will understand that Figure 11The structure shown does not constitute a limitation on the computer device 1100 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0103] Please refer to Figure 12 It illustrates the structural block of a computer device provided in another exemplary embodiment of this disclosure. Figure 2 The computer device can be a server used to execute the terrain rendering method described above. Specifically: Computer device 1200 includes a central processing unit (CPU) 1201, a system memory 1204 including random access memory (RAM) 1202 and read-only memory (ROM) 1203, and a system bus 1205 connecting the system memory 1204 and the CPU 1201. Computer device 1200 also includes a basic input / output system (I / O system) 1206 that facilitates information transfer between various devices within the computer, and a mass storage device 1207 for storing the operating system 1213, application programs 1214, and other program modules 1211.

[0104] The basic input / output system 1206 includes a display 1208 for displaying information and an input device 1209 for user input, such as a mouse or keyboard. Both the display 1208 and the input device 1209 are connected to the central processing unit 1201 via an input / output controller 1120 connected to the system bus 1205. The basic input / output system 1206 may also include the input / output controller 1120 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 1120 also provides output to a display screen, printer, or other types of output devices.

[0105] Mass storage device 1207 is connected to central processing unit 1201 via a mass storage controller (not shown) connected to system bus 1205. Mass storage device 1207 and its associated computer-readable media provide non-volatile storage for computer device 1200. That is, mass storage device 1207 may include computer-readable media (not shown) such as hard disk or CD-ROM (Compact Disc Read-Only Memory) drive.

[0106] Without loss of generality, computer-readable media can include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include RAM, ROM, EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other solid-state storage technologies, CD-ROM, DVD (Digital Video Disc) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that computer storage media are not limited to the above-mentioned types. The system memory 1204 and mass storage device 1207 described above can be collectively referred to as memory.

[0107] According to various embodiments of this disclosure, the computer device 1200 can also be connected to a remote computer on a network, such as the Internet. That is, the computer device 1200 can be connected to the network 1212 via the network interface unit 1211 connected to the system bus 1205, or the network interface unit 1211 can be used to connect to other types of networks or remote computer systems (not shown).

[0108] The aforementioned memory also includes a computer program stored in the memory and configured to be executed by one or more processors to implement the aforementioned terrain rendering method.

[0109] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is executed by a processor to implement the terrain rendering method.

[0110] Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0111] In an exemplary embodiment, a computer-readable storage medium including program code is also provided, such as a memory including program code, which can be executed by a processor to complete the terrain rendering method described above. Optionally, the computer-readable storage medium may be read-only memory (ROM), random access memory (RAM), compact-disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0112] In an exemplary embodiment, a computer program product is also provided, including a computer program that, when executed by a processor, implements the terrain rendering method described above.

[0113] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0114] It should be understood that this disclosure 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 this disclosure is limited only by the appended claims.

Claims

1. A terrain rendering method, characterized in that, The method includes: Offline construction of terrain grid data corresponding to multiple levels, the terrain grid data corresponding to multiple levels are used to describe the basic terrain and the mountains in the basic terrain; Offline bidirectional grid vertex alignment processing is performed on the terrain grid data corresponding to the multiple levels to obtain multi-level terrain grid data; Online rendering is performed based on camera parameters and the multi-level terrain mesh data.

2. The method according to claim 1, characterized in that, The offline process performs bidirectional grid vertex alignment between adjacent levels on the terrain grid data corresponding to the multiple levels to obtain multi-level terrain grid data, including performing the following operations on any two adjacent levels of terrain grid data: Insert some boundary vertices of the first grid into the corresponding positions of the boundary of the second grid, and use them as new vertices in the second grid; Based on the vertices in the first grid and the vertices in the second grid, a target vertex is determined, and the target vertex is deleted from the first grid; Wherein, the first grid refers to the grid indicated by the terrain grid data corresponding to the lower level among any two adjacent levels, and the second grid refers to the grid indicated by the terrain grid data corresponding to the higher level among any two adjacent levels.

3. The method according to claim 2, characterized in that, Determining the target vertex based on the vertices in the first grid and the vertices in the second grid includes: For any vertex in the first grid, determine the corresponding mapping position of the vertex in the second grid, and determine the two vertices in the second grid that are adjacent to the mapping position as the first vertex and the second vertex, respectively; The height difference between the vertex and the first vertex is taken as the first height difference, and the height difference between the vertex and the second vertex is taken as the second height difference; If the difference between the first height difference and the second height difference is less than a preset threshold, and the vertex, the first vertex and the second vertex are collinear, the vertex is determined as the target vertex.

4. The method according to claim 2, characterized in that, The method further includes: Points in the first grid that are within the outer contour boundary are taken as vertices of the first grid, and points in the second grid that are within the outer contour boundary are taken as vertices of the second grid.

5. The method according to claim 1, characterized in that, The offline construction of terrain grid data corresponding to multiple levels includes: Based on the topographic elevation map representing the basic terrain, the topographic elevation map is baked into a topographic mesh to obtain a multi-resolution topographic mesh; The 3D mountain model is placed in the terrain scene and the scene is baked. During the scene baking process, the multi-resolution terrain mesh and the 3D mountain model are loaded simultaneously to obtain mixed data. The mixed data includes multi-resolution terrain mesh data and height map. The multi-resolution terrain mesh data includes mountain texture map. Based on the mixed data, terrain grid data corresponding to the multiple levels are obtained respectively.

6. The method according to claim 5, characterized in that, The camera parameters include camera height. The online rendering based on the camera parameters and the multi-level terrain mesh data includes: When the camera height is less than the preset height, render a 3D mountain model located within the field of view; When the camera height is greater than or equal to the preset height, target data located within the field of view is rendered. The target data comes from the multi-level terrain mesh data and includes the mountain texture map.

7. The method according to claim 6, characterized in that, The rendered target data located within the field of view includes: Based on the camera height, determine the layer to be rendered; Based on the layer to be rendered, the target data within the field of view is extracted from the multi-level terrain mesh data, and the texture resources of the target layer are extracted from the multi-level terrain mesh data based on the field of view. The target layer is the upper level of the layer to be rendered. Render the target data.

8. The method according to claim 7, characterized in that, The field of view is determined based on the camera height and camera position. Extracting the target data within the field of view from the multi-level terrain mesh data based on the rendering layer includes: Each level from the level to be rendered to the highest level is determined as a valid level; Within the field of view, multiple grids are determined for each effective level; The data corresponding to the grids under each effective level are used as the target data.

9. The method according to claim 8, characterized in that, The online rendering based on camera parameters and the multi-level terrain mesh data includes: If the highest-level terrain grid data needs to be loaded based on the camera parameters, the highest-level terrain grid data is loaded synchronously. If it is determined based on the camera parameters that non-highest level terrain grid data needs to be loaded, the non-highest level terrain grid data is loaded asynchronously. Always retain the highest-level terrain grid data from the most recently loaded layer.

10. The method according to claim 1, characterized in that, The online rendering based on camera parameters and the multi-level terrain mesh data includes: If the conditions for rendering from high-level to low-level are met, and all fourth grids corresponding to the third grid are loaded, all fourth grids are displayed and the third grid is hidden. The third grid is any grid belonging to the high-level within the field of view, and the fourth grid is a grid in the adjacent low-level, and the terrain range formed by the third grid coincides with the terrain range formed by all fourth grids.

11. A terrain rendering device, characterized in that, The device includes: The basic data construction module is configured to perform offline construction of terrain grid data corresponding to multiple levels, which are used to describe the basic terrain and the mountains in the basic terrain. The vertex alignment module is configured to perform offline bidirectional grid vertex alignment processing between adjacent levels on the terrain grid data corresponding to the multiple levels respectively, to obtain multi-level terrain grid data; The rendering module is configured to perform online rendering based on camera parameters and the multi-level terrain mesh data.

12. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the terrain rendering method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device performs the terrain rendering method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product includes a computer program stored in a readable storage medium, wherein at least one processor of a computer device reads from and executes the computer program, causing the device to perform the terrain rendering method as described in any one of claims 1 to 10.

Images