Picture generation method and device, storage medium and equipment

Abstract

The invention discloses a picture generation method and device, a storage medium and equipment. The method comprises the steps of obtaining sparse voxel illumination data corresponding to a highest detail level model in a virtual scene; determining a cascade coordinate space corresponding to the virtual scene according to the spatial position and the observation depth of the virtual camera, and mapping the world coordinates of each detail hierarchy model into the cascade coordinate space; determining a boundary region of the adjacent detail hierarchy models in the cascade coordinate space; obtaining original voxel data of the current detail hierarchy model corresponding to the boundary region; the sparse voxel illumination data is loaded in the boundary region, and the sparse voxel illumination data and the original voxel data are mixed to generate a rendering picture of the virtual scene, so that smooth visual transition of the illumination effect between adjacent detail hierarchy models is realized, and the memory consumption is effectively reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method, apparatus, storage medium, and device for generating images. Background Technology

[0002] In the field of game rendering, especially in real-time rendering of large 3D world scenes, discrete Level of Detail (LOD) technology is commonly used for data loading to balance visual quality and performance. Specifically, the system dynamically loads different LOD models based on the distance between the virtual camera and scene objects. This requires pre-storing LOD information for different levels, resulting in a noticeable jump when the model in the terrain quickly switches from LOD0 to LOD1 as the camera moves forward. The current method causes the model to jump around noticeably as the camera moves, resulting in an uneven transition. In addition, each model needs to store multiple LOD levels, which consumes a lot of game memory. Summary of the Invention

[0003] This application provides a method, apparatus, storage medium, and device for generating images, which can achieve a smooth visual transition of lighting effects between adjacent detail level models and effectively reduce memory consumption.

[0004] On one hand, embodiments of this application provide a method for generating an image, the method comprising: Obtain the sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene; Based on the spatial position and observation depth of the virtual camera, the cascaded coordinate space corresponding to the virtual scene is determined, and the world coordinates of each detail level model are mapped to the cascaded coordinate space. Determine the boundary regions of adjacent detail level models in the cascaded coordinate space; Obtain the original voxel data of the current detail level model corresponding to the boundary region; The sparse voxel lighting data is loaded within the boundary area, and the sparse voxel lighting data is mixed with the original voxel data to generate the rendered image of the virtual scene.

[0005] On the other hand, embodiments of this application provide an image generation apparatus, the apparatus comprising: The first acquisition unit is used to acquire sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene. The generation unit is used to determine the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera, and to map the world coordinates of each detail level model to the cascaded coordinate space. A determining unit is used to determine the boundary region of adjacent detail level models in the cascaded coordinate space; The second acquisition unit is used to acquire the original voxel data of the current detail level model corresponding to the boundary region; The processing unit is used to load the sparse voxel lighting data within the boundary area and to mix the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene.

[0006] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the screen generation method as described in any of the above embodiments.

[0007] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory, the memory storing a computer program, the processor executing the screen generation method as described in any of the above embodiments by calling the computer program stored in the memory.

[0008] On the other hand, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the screen generation method as described in any of the above embodiments.

[0009] This application embodiment obtains sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene; determines the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera, and maps the world coordinates of each level of detail model to the cascaded coordinate space; determines the boundary region of adjacent level of detail models in the cascaded coordinate space; obtains the original voxel data of the current level of detail model corresponding to the boundary region; loads sparse voxel lighting data in the boundary region, and mixes the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene. This application embodiment uses general sparse voxel lighting data derived from the highest level of detail, combines it with the cascaded coordinate space mapping driven by the virtual camera, and determines the boundary region of adjacent level of detail models in the cascaded coordinate space. The sparse voxel lighting data is then loaded and mixed within the boundary region, thereby achieving a smooth visual transition of lighting effects between adjacent level of detail models with significantly reduced memory overhead and effectively reducing memory consumption. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of an example game system provided in an embodiment of this application.

[0012] Figure 2 This is a flowchart illustrating the screen generation method provided in an embodiment of this application.

[0013] Figure 3 A schematic diagram of the structure of the original dense voxel lighting data for the highest level of detail model provided in the embodiments of this application.

[0014] Figure 4 A schematic diagram of the structure of sparse voxel illumination data for the highest level of detail model provided in the embodiments of this application.

[0015] Figure 5 This is a schematic diagram illustrating the cascading region division of cascading data provided in an embodiment of this application.

[0016] Figure 6 This is a schematic diagram illustrating an application scenario for loading sparse voxel illumination data, as provided in an embodiment of this application.

[0017] Figure 7 This is a schematic diagram illustrating the application scenario of the rendered screen provided in the embodiments of this application.

[0018] Figure 8 This is a schematic diagram of the structure of the image generation device provided in the embodiments of this application.

[0019] Figure 9 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] This application provides a method, apparatus, storage medium, and device for generating images. Specifically, the image generation method of this application can be executed by a computer device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, smart TV, wearable smart device, smart vehicle terminal, etc. The terminal can also include a client, which can be a game client, browser client, instant messaging client, or mini-program, etc. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0022] For example, when this screen generation method runs on a terminal device, the terminal device may include a display screen and a processor. The display screen is used to present game screens and receive commands generated by the player interacting with the game screens. The game screens may include a portion of a virtual game scene, which is a virtual world where virtual characters move. The processor is used to store the game application, run the game, generate game screens, respond to commands, and control the display of the game screens on the display screen. When the player interacts with the game screens through the display screens, the game screens can control the local content of the terminal device in response to the received operation commands. The terminal device can provide the graphical user interface to the player in various ways, such as rendering the display on the terminal device's screen or presenting the graphical user interface through holographic projection.

[0023] For example, when this screen generation method runs on a server, it can be implemented and executed based on a cloud gaming system. A cloud gaming system refers to a gaming method based on cloud computing. A cloud gaming system includes servers and client devices. The main body running the game application and the main body presenting the game screen are separate. The storage and execution of the screen generation method are completed on the server. The presentation of the game screen is completed on the client, which is mainly used for receiving and sending game data and presenting the game screen. For example, the client can be a display device with data transmission capabilities located close to the player, such as a mobile terminal, television, computer, PDA, personal digital assistant, head-mounted display device, etc. However, the terminal device for processing game data is the server in the cloud. During gameplay, the player operates the client to send commands to the server. The server controls the game operation according to the commands, encodes and compresses game screen data, returns it to the client via the network, and finally, the client decodes and outputs the game screen.

[0024] It should be noted that, in this embodiment, the execution entity of the screen generation method can be a terminal device or a server. The terminal device can be a local terminal device or a client device in the aforementioned cloud gaming. This embodiment does not limit the type of execution entity.

[0025] For example, in conjunction with the above description, Figure 1 This application illustrates a game system 1000 for implementing a screen generation method, as provided in an embodiment of this application. The game system 1000 may include at least one terminal 1001, at least one server 1002, at least one database 1003, and a network. The user-held terminal 1001 can connect to different servers via the network. The terminal is any device with computing hardware capable of supporting and executing software applications corresponding to the game.

[0026] In the aforementioned game system 1000, terminal 1001 is used to install and run the game application. In some cases, the game application may not need to be pre-installed on terminal 1001, and players can directly access the game through a browser or other client. Players log in to the game application using their registered game account to control the virtual character corresponding to that account and participate in the game. When a player logs in to the game application, terminal 1001 sends a login request to server 1002. Server 1002 verifies the game account used by the player and determines the game mechanics corresponding to the game account based on the login request. If the verification is successful, a login success notification is returned to terminal 1001. During the player's participation in the game through the game application, terminal 1001 and server 1002 exchange data. Terminal 1001 sends various information to server 1002. Server 1002 determines the display data for terminal 1001 based on the stored game mechanics and the received information, and sends the display data back to terminal 1001 so that terminal 1001 can display the display data sent by server 1002 to the player.

[0027] In possible application scenarios, different terminals 1001 may be served by different servers 1002. Therefore, in order to distinguish the servers 1002 corresponding to different game terminals 1001, the embodiments of this application will use the terms "first" and "second" to describe them. In fact, the servers 1002 corresponding to different game terminals 1001 can be the same server 1002. Therefore, without distinguishing between "first" and "second", it can be understood that the terminals 1001 corresponding to virtual characters in the same game scene are served by the same server 1002.

[0028] Furthermore, when the game system 1000 includes multiple terminals, multiple servers, and multiple networks, different terminals can connect to each other through different networks and servers. The network can be a wireless network or a wired network; for example, wireless networks include Wi-Fi, LAN, cellular networks, 2G, 3G, 4G, and 5G networks. Additionally, different terminals can also connect to other terminals or servers using their own Bluetooth networks or hotspot networks. Moreover, the system 100 can include multiple databases coupled to different servers, and can continuously store game-related information in the databases while different users are playing multiplayer games online.

[0029] It should be noted that in this embodiment, multiple terminal devices are running the same virtual game. Therefore, data interaction between the multiple terminal devices can be achieved through the virtual game's server. Thus, sending data from terminal device 1 to terminal device 2 can be understood as: terminal device 1 sends data to the virtual game's server, and the server sends the data to terminal device 2. Receiving data from terminal device 2 can be understood as: terminal device 1 receives data sent by the virtual game's server, which is the data sent by terminal device 2 to the server. Alternatively, there may be no game server, and terminal device 1 directly sends game data to terminal device 2.

[0030] It should be noted that, Figure 1 The game system diagram shown is merely an example. The game system 1000 described in this application embodiment is intended to more clearly illustrate the technical solutions of this application embodiment and does not constitute a limitation on the technical solutions provided in this application embodiment. As those skilled in the art will know, with the evolution of game systems and the emergence of new business scenarios, the technical solutions provided in this application embodiment are also applicable to similar technical problems.

[0031] It should be noted that the triggering operations mentioned in the subsequent detailed description of the screen generation method provided in the embodiments of this application can all be regarded as triggering operations performed by the player through a finger or by controlling a medium such as a mouse, keyboard, or stylus. The specific medium used can be determined according to the type of computer device. For example, when the computer device is a touchscreen device such as a mobile phone, tablet, or game console, the player can operate on the touchscreen using any suitable object or accessory such as a finger or stylus. When the terminal device is a non-touchscreen terminal device such as a desktop computer or laptop, the player can operate using external devices such as a mouse or keyboard.

[0032] The technical solution of this application will be described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0033] In this embodiment of the application, a graphical user interface is provided through a terminal device. The graphical user interface includes at least a portion of the virtual scene and at least one virtual character.

[0034] The aforementioned virtual scene can be a game scene, which can be understood as a simulation of the real world within a game, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. A game scene can be any of the following: two-dimensional, 2.5-dimensional, or three-dimensional virtual scenes. A virtual scene typically includes multiple scene elements, which are the various elements required to construct the virtual scene. For example, these may include, but are not limited to, at least one of the following: virtual character elements, virtual item elements, virtual building elements, virtual terrain elements, and virtual vegetation elements. Virtual terrain elements may include, but are not limited to, natural landforms such as land, ocean, lakes, and rivers. A virtual scene is a scenario where players control virtual characters to complete game logic.

[0035] As can be understood, a virtual character is a game character controlled by the player in a game. The player manipulates this virtual character to perform various game activities within the game environment, such as picking up items, engaging in combat, exploring, or solving puzzles. This virtual character can represent the player's image, and each virtual character can be implemented using a 3D or 2D virtual model; this embodiment does not specifically limit this. Virtual characters include, but are not limited to, at least one of the following: virtual human, virtual animal, and virtual machine.

[0036] Please see Figures 2 to 7 ,in, Figure 2 This is a flowchart illustrating a screen generation method provided in an embodiment of this application. The method can provide a graphical user interface (GUI) via a terminal device. The GUI includes at least a portion of a virtual scene. The method may include the following steps: Step 110: Obtain the sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene.

[0037] In some embodiments, the total amount of the sparse voxel lighting data is less than the total amount of the original lighting data of the highest level of detail model.

[0038] This process involves acquiring sparse voxel lighting data corresponding to the highest level of detail (LOD0) model in the virtual scene (i.e., the LOD0 model, which is used only to calculate sparse volumes applicable to all LOD levels). The total amount of sparse voxel lighting data is less than the total amount of original lighting data for the highest LOD model. The total amount of sparse voxel lighting data, i.e., the number of voxels stored, is only a preset percentage (e.g., 10%) of the total amount of original lighting data for the LOD0 model. This sparse voxel lighting data is obtained by baking the LOD0 model, and its lighting data includes direct lighting information and skylight lighting information. It is applicable to all other LOD models (LOD1, LOD2, etc.) in the virtual scene, thus avoiding the memory consumption caused by storing complete lighting data separately for each LOD level.

[0039] In some embodiments, the method further includes: acquiring raw dense voxel lighting data generated by pre-baking the highest level of detail model; adaptively downsampling the raw dense voxel lighting data to generate the sparse voxel lighting data, wherein the sampling density is dynamically adjusted according to the surface geometric complexity or vertex distribution density of the highest level of detail model; and storing the sparse voxel lighting data.

[0040] Light baking is a technique that pre-calculates and stores dynamic lighting effects in model textures or voxels. For models with the highest level of detail (LOD0), pre-light baking allows for detailed recording of direct lighting (such as direct illumination from a light source) and indirect lighting (such as ambient light and reflected light) effects on the model's surface, generating models like... Figure 3 The original dense voxel lighting data is shown. This process not only considers the position and intensity of the light source, but also simulates the propagation and reflection of light in the scene, ensuring the accuracy and realism of the lighting effects. The dense voxel lighting data contains lighting information for every point on the model surface, providing a rich data foundation for subsequent adaptive downsampling.

[0041] Adaptive downsampling is a technique that dynamically adjusts the sampling density based on the geometric complexity of the model surface or the vertex distribution density. The rule for adaptive downsampling is to use a relatively high sampling density in densely populated vertex face regions of the highest level of detail model, and a relatively low sampling density in regions far from the model.

[0042] For example, in areas with rich model detail (such as regions with a high number of vertex faces), a higher sampling density can be used to retain more lighting information, ensuring that the lighting effects in these areas are delicate and realistic. Conversely, in flat or distant areas from the model, a lower sampling density is used to reduce unnecessary data while maintaining sufficient lighting information to preserve the overall lighting effect of the scene. This dynamic adjustment of sampling density ensures an optimal balance between lighting effects and data volume in different regions. Through adaptive downsampling, such as... Figure 3 The original dense voxel illumination data shown was converted into, as follows: Figure 4 The sparse voxel lighting data shown is an example of how sparse voxel lighting data significantly reduces data volume and improves rendering efficiency while maintaining high visual quality.

[0043] The acquired sparse voxel lighting data can be stored using efficient data structures (such as 3D textures and compressed voxel data). These data structures not only reduce memory usage but also improve data access efficiency, enabling rapid loading and use of sparse voxel lighting data during rendering. By optimizing storage strategies, such as employing hierarchical storage and indexing techniques, memory usage is reduced and data access efficiency is improved, ensuring rapid loading and use of sparse voxel lighting data during the rendering process.

[0044] In some embodiments, lighting baking is performed on the highest level of detail model to generate raw dense voxel lighting data, including: generating the raw dense voxel lighting data by baking the direct lighting information and sky lighting information of the highest level of detail model, wherein the sky lighting information is ambient light information simulating the illumination of the sky hemisphere in the virtual scene.

[0045] By baking direct lighting information and skylight lighting information, which is the main contributor to ambient light, the generated raw lighting data is ensured to reflect the model's overall lighting performance in the scene with high quality, providing an accurate information source for the subsequent generation of sparse voxel lighting data applicable to the whole world. Direct lighting information comes from light sources in the scene, such as lamps and the sun. By baking this direct lighting information, the effects of light on the model's surface and the distribution of shadows can be recorded in detail.

[0046] The skylight illumination information simulates the ambient light effect of the sky hemisphere lighting in the virtual scene. This ambient light information makes the scene lighting more natural and realistic, enhancing the sense of immersion. By incorporating skylight illumination information into the lighting baking process, richer and more accurate dense voxel lighting data can be generated.

[0047] In some embodiments, the sparse voxel lighting data is applicable to all detail-level models in the virtual scene.

[0048] The sparse voxel lighting data is applicable to all detail levels of models in the virtual scene. This means that regardless of whether the currently rendered model is LOD1, LOD2, or even lower precision, when a smooth transition is required, the same set of sparse voxel lighting data originating from LOD0 can be used for interpolation and blending. This avoids the traditional approach of storing independent lighting data for each LOD. By establishing such a universal, high-quality lighting reference, the memory consumption of repeatedly storing lighting data for multiple LOD levels is fundamentally eliminated, achieving a smooth visual transition of lighting effects between models of different detail levels while effectively reducing memory consumption.

[0049] In some embodiments, the total amount of the sparse voxel lighting data is not greater than a preset proportion of the total amount of the original lighting data of the highest level of detail model.

[0050] This limitation aims to minimize data storage and processing burden while maintaining the lighting effects of the virtual scene. Raw dense voxel lighting data contains a wealth of lighting details and is typically large in size; directly using this data for rendering would put significant strain on system performance. In contrast, sparse voxel lighting data generated through adaptive downsampling significantly reduces the data volume while retaining crucial lighting information. By controlling the total amount of sparse voxel lighting data to a preset percentage (e.g., 10%) of the total amount of raw lighting data, memory usage and data processing time can be significantly reduced without affecting the lighting quality and visual effects of the virtual scene. This improves the operational efficiency of the virtual scene, enabling games or virtual applications to run smoothly on a wider range of hardware platforms.

[0051] Step 120: Based on the spatial position and observation depth of the virtual camera, determine the cascaded coordinate space corresponding to the virtual scene, and map the world coordinates of each detail level model to the cascaded coordinate space.

[0052] This involves dynamically dividing the virtual scene into multiple cascaded regions centered on the camera, based on the distance between the virtual camera and the model. Figure 5 The indicated directional area is used to determine the cascaded coordinate space corresponding to the virtual scene. The process of mapping the model's world coordinates to cascaded coordinates is essentially transforming the world coordinates into a coordinate space associated with the virtual camera, so that the cascaded region and boundary region to which the model belongs can be determined subsequently based on depth information.

[0053] In some embodiments, determining the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera includes: dividing the virtual scene into multiple cascaded regions centered on the virtual camera based on the spatial position and observation depth of the virtual camera, so as to determine the cascaded coordinate space corresponding to the virtual scene.

[0054] In a virtual scene, the spatial position of the virtual camera determines the starting point of its viewpoint, while the observation depth reflects the range of the scene that the camera can observe. By considering both parameters, the relative distance and positional relationship between different areas of the virtual scene and the camera can be accurately determined. For example, in a large open-world game scene, if the virtual camera is located on the wall of a castle and the observation depth is set to 1000 meters, then based on this range, the scene can be divided into multiple cascaded areas centered on the camera, at certain distance intervals (such as 100 meters, 200 meters, etc.). For example, 0-100 meters from the camera is the first cascaded area, 100-200 meters is the second cascaded area, and so on. This division method can clearly define the characteristics and requirements of the scene within different distance ranges.

[0055] In this context, world coordinates represent the absolute position of a model within the virtual scene, while cascaded coordinate space is a relative coordinate system based on the virtual camera's position. By mapping the world coordinates of each detail-level model to its corresponding cascaded coordinate space, model data can be categorized into different cascaded regions based on their distance and relative position from the virtual camera. Taking the aforementioned cascaded regions as an example, for a model located within the first cascaded region (0-100 meters), its world coordinates are mapped to the local coordinate system of that cascaded region according to certain transformation rules. This mapping process involves coordinate transformation algorithms, using matrix operations and other methods to achieve coordinate transformation. After mapping, each model has a new coordinate representation in its corresponding cascaded coordinate space. These coordinate data, combined with the information from the cascaded regions, constitute the cascaded coordinate space of the virtual scene.

[0056] The multiple cascaded regions are a series of axis-aligned bounding boxes centered on the virtual camera, with dimensions increasing from near to far. An axis-aligned bounding box is a simple geometric shape that facilitates calculation and determination of whether an object is inside it, thereby improving data processing efficiency. The design of increasing dimensions from near to far ensures that areas closer to the virtual camera receive higher data accuracy and more detail, while areas farther away can have reduced accuracy to conserve resources.

[0057] The cascaded coordinate space is composed of multiple cascaded regions; the closer the cascaded region is to the camera, the smaller its volume and the higher its theoretical accuracy.

[0058] Step 130: Determine the boundary regions of adjacent detail level models in the cascaded coordinate space.

[0059] Among them, the boundary region, also known as the "transition region" or "overlapping region," is dynamically determined based on the distance between the virtual camera and the corresponding detail level model. It refers to the transition zone at the intersection of adjacent regions corresponding to two adjacent LOD levels in the cascaded coordinate space.

[0060] In some embodiments, determining the boundary region of adjacent detail level models in the cascaded coordinate space includes: determining the boundary region of adjacent detail level models in the cascaded coordinate space based on the distance between the virtual camera and each detail level model.

[0061] First, the system calculates the spatial distances between the virtual camera and models at various detail levels (such as LOD0, LOD1, LOD2, etc.) in real time. This distance data is dynamically updated as the virtual camera moves within the virtual scene. By associating these distances with the model's detail level, the system can identify which models are currently in the foreground of the camera and which are in the background. Based on these distance calculations, one or more boundary regions can be defined. These boundary regions are typically located in transitional zones at the boundaries between adjacent detail level models, such as the area transitioning from a high-precision model (LOD0) to a medium-precision model (LOD1). The width and position of these boundary regions can be dynamically adjusted according to actual needs to ensure a smooth transition in lighting and model detail.

[0062] In some embodiments, determining the boundary region of adjacent detail level models in the cascaded coordinate space based on the distance between the virtual camera and each detail level model includes: presetting distance thresholds for different detail level models; and determining the region where the distance between the virtual camera and the model falls between the distance thresholds of two adjacent detail level models as the boundary region.

[0063] This method ensures a clear transition area between adjacent detail level models, facilitating subsequent lighting data blending.

[0064] Step 140: Obtain the original voxel data of the current detail level model corresponding to the boundary region.

[0065] After determining the boundary region, the original voxel data of the current level of detail model involved in the boundary region is extracted. This original voxel data contains various lighting, material, and other information of the current level of detail model within the boundary region. This original voxel data represents the lighting information (usually of high quality) that should have been presented in this region based on the original LOD model before the smooth transition processing.

[0066] Step 150: Load the sparse voxel lighting data within the boundary area, and mix the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene.

[0067] For example, after loading sparse voxel lighting data into the boundary region, this newly loaded sparse voxel lighting data needs to be mixed with the original voxel data obtained in step 140. The mixing method can be selected according to specific needs and effects; common methods include linear mixing and weighted mixing. Through mixing, the lighting information in the sparse voxel lighting data can be organically combined with the material and lighting information in the original voxel data, making the lighting effect in the boundary region more natural and smooth, avoiding abrupt changes caused by switching between different detail levels. Finally, the rendered virtual scene generated after mixing can present a rendered image with continuous and smooth visual transitions, enhancing the user's immersion in the virtual scene.

[0068] like Figure 6 As shown, sparse voxel illumination data generated based on the LOD0 level model is inserted at the corresponding position in the cascaded coordinate space of the boundary region of the LOD1 level model.

[0069] In some embodiments, loading the sparse voxel illumination data within the boundary region includes: determining the corresponding position of the boundary region in the cascaded coordinate space; and loading the pre-baked and stored sparse voxel illumination data corresponding to the boundary region into the corresponding position of the boundary region in the cascaded coordinate space.

[0070] For example, in the construction of a virtual scene, the cascaded coordinate spaces corresponding to adjacent detail level models are clearly defined, but the boundary region is the transition zone between two adjacent detail level models with different precision or level of detail in the cascaded coordinate space. To accurately load or insert sparse voxel lighting data, the position of the boundary region in the cascaded coordinate space must first be precisely located. This requires utilizing the coordinate system of the virtual scene and the rules for dividing the cascaded regions. For example, in a large open-world game, the virtual scene is divided into multiple cascaded regions centered on the virtual camera, each region having its own independent coordinate space. Two adjacent detail level models, such as a model representing a detailed building at close range and a model representing a coarser building at medium range, have boundaries in their corresponding cascaded coordinate spaces. Through pre-defined coordinate mapping relationships and the boundary definitions of the cascaded regions, and using mathematical calculation methods such as coordinate transformation matrix operations, the coordinate range of the boundary region in its respective cascaded coordinate space can be accurately calculated.

[0071] Then, based on the position of the boundary region in the cascaded coordinate space, the corresponding data block is retrieved from the pre-baked and stored sparse voxel lighting dataset. The retrieved sparse voxel lighting data is then aligned with the boundary region to ensure that the lighting effect accurately covers the target area. During loading, the sparse voxel lighting data can also be dynamically adjusted and optimized according to the needs of real-time rendering, such as adjusting parameters like light intensity, color, or direction to adapt to different scenes and lighting conditions.

[0072] In some embodiments, loading the boundary region to the corresponding position in the cascaded coordinate space includes: writing the sparse voxel lighting data as three-dimensional texture data into the graphics processor cache allocated for the boundary region.

[0073] In some embodiments, the steps of loading the corresponding sparse voxel lighting data and performing blending are executed in parallel within the computation shader of the graphics processor; wherein the cascaded coordinate space is divided into multiple thread groups, each thread being responsible for loading and blending data for one or more voxels.

[0074] In some embodiments, the process of mixing the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene includes: The sparse voxel lighting data and the original voxel data in the boundary region are linearly interpolated and mixed to generate a rendered image with a smooth visual transition between adjacent detail level models in the virtual scene.

[0075] Linear interpolation blending is a commonly used data fusion technique that achieves a smooth transition in lighting effects by calculating the weighted average of sparse voxel lighting data and the original voxel data within the boundary region. This processing method ensures that lighting changes are natural and without obvious jumps when switching between different detail levels of models, thereby improving the overall visual effect of the rendered image.

[0076] In some embodiments, the mixing weights of the linear interpolation mixing process are determined based on the distances of the current processing point to both sides of the boundary region in the cascaded coordinate space; wherein, the closer to the side of the boundary region corresponding to the closer level of detail, the higher the weight of the original voxel data.

[0077] This design allows processing points closer to the level of detail to retain more of the original voxel data's lighting characteristics, while processing points closer to the level of detail incorporate more of the influence of sparse voxel lighting data, thus achieving a gradual transition in lighting effects.

[0078] In some embodiments, the method further includes: in response to the movement of the virtual camera, dynamically adjusting the division of the cascaded coordinate space and the extent of the boundary region based on changes in the distance between the virtual camera and each detail level model.

[0079] The movement of the virtual camera causes changes in its distance from various detail levels of the model. To maintain a smooth transition in the rendered image, the system needs to dynamically adjust the division of the cascaded coordinate space and the extent of the boundary regions. This dynamic adjustment mechanism ensures a smooth transition of lighting effects between adjacent detail levels of the model, regardless of how the virtual camera moves.

[0080] In some embodiments, the method is executed via a script driver attached to the virtual camera. Specifically, the method further includes: attaching a control script to the virtual camera; and, through the control script, performing at least one of the following operations: acquiring sparse voxel illumination data, generating cascaded data, inserting data in boundary regions, and triggering blending processing.

[0081] like Figure 7 As shown, during game execution, the screen generation method provided in this application embodiment can be executed through a script driver mounted on the virtual camera to generate images as shown in the figure. Figure 7 The rendering shown demonstrates a smooth visual transition between adjacent detail level models. Specifically, renderings with smooth visual transitions are generated at boundary regions A, B, C, and D.

[0082] In some embodiments, the method further includes: providing a user interaction interface, allowing users to adjust the observation parameters of the virtual camera (such as observation depth, viewing angle, etc.) and the detail level display settings of the virtual scene according to their needs; and updating the generated rendering effect in real time based on the user's adjustments to meet the user's personalized needs. By allowing users to adjust the observation parameters of the virtual camera and the detail level display settings of the virtual scene, the system can update the generated rendering effect in real time. This personalized setting can meet the needs and preferences of different users, improving the practicality and attractiveness of the rendered image.

[0083] In some embodiments, the method further includes: performing a quality assessment on the rendered image of the generated virtual scene, wherein the assessment indicators include color consistency, lighting uniformity, and the naturalness of detail transitions; if the assessment result does not meet the preset standard, the acquisition parameters of sparse voxel lighting data, the weight of the blending process, or the method for determining the boundary region are readjusted until the rendered image of the generated virtual scene meets the quality requirements. This quality assessment mechanism can ensure the stability and reliability of the rendered image.

[0084] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0085] The image generation method provided in this application embodiment obtains sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene; determines the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera, and maps the world coordinates of each level of detail model to the cascaded coordinate space; determines the boundary region of adjacent level of detail models in the cascaded coordinate space; obtains the original voxel data of the current level of detail model corresponding to the boundary region; loads sparse voxel lighting data in the boundary region, and mixes the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene. This application embodiment uses general sparse voxel lighting data derived from the highest level of detail, combines it with the cascaded coordinate space mapping driven by the virtual camera, and determines the boundary region of adjacent level of detail models in the cascaded coordinate space. The sparse voxel lighting data is then loaded and mixed within the boundary region, thereby achieving a smooth visual transition of lighting effects between adjacent level of detail models with significantly reduced memory overhead and effectively reducing memory consumption.

[0086] To facilitate better implementation of the image generation method of this application, this application also provides an image generation apparatus. Please refer to... Figure 8 , Figure 8 This is a schematic diagram of the structure of the image generation apparatus provided in an embodiment of this application. The image generation apparatus 200 may include: The first acquisition unit 210 is used to acquire sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene, wherein the total amount of the sparse voxel lighting data is less than the total amount of the original lighting data of the highest level of detail model. The generation unit 220 is used to determine the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera, and to map the world coordinates of each detail level model to the cascaded coordinate space. Determining unit 230 is used to determine the boundary region of adjacent detail level models in the cascaded coordinate space; The second acquisition unit 240 is used to acquire the original voxel data of the current detail level model corresponding to the boundary region; The processing unit 250 is used to load the sparse voxel lighting data within the boundary area and to mix the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene.

[0087] In some embodiments, the generation unit 220 is configured to: divide the virtual scene into multiple cascaded regions centered on the virtual camera according to the spatial position and observation depth of the virtual camera, so as to determine the cascaded coordinate space corresponding to the virtual scene.

[0088] In some embodiments, the processing unit 250 is configured to perform mixed processing on the sparse voxel lighting data and the original voxel data to generate a rendered image of the virtual scene, including: performing linear interpolation mixed processing on the sparse voxel lighting data and the original voxel data in the boundary region to generate a rendered image of the virtual scene with a smooth visual transition between adjacent detail level models.

[0089] In some embodiments, the processing unit 250 is configured to load the sparse voxel illumination data within the boundary region, including: determining the corresponding position of the boundary region in the cascaded coordinate space; and loading the pre-baked and stored sparse voxel illumination data corresponding to the boundary region into the corresponding position of the boundary region in the cascaded coordinate space.

[0090] In some embodiments, the image generation apparatus 200 further includes a preprocessing unit, configured to: acquire raw dense voxel lighting data generated by pre-baking the highest level of detail model; adaptively downsample the raw dense voxel lighting data to generate the sparse voxel lighting data, wherein the sampling density is dynamically adjusted according to the surface geometric complexity or vertex distribution density of the highest level of detail model; and store the sparse voxel lighting data.

[0091] In some embodiments, the preprocessing unit is used to perform lighting baking on the highest level of detail model to generate raw dense voxel lighting data, including: generating the raw dense voxel lighting data by baking the direct lighting information and sky lighting information of the highest level of detail model, wherein the sky lighting information is ambient light information simulating the illumination of the sky hemisphere in the virtual scene.

[0092] In some embodiments, the sparse voxel lighting data is applicable to all detail-level models in the virtual scene.

[0093] In some embodiments, the total amount of the sparse voxel lighting data is less than the total amount of the original lighting data of the highest level of detail model.

[0094] In some embodiments, the total amount of the sparse voxel lighting data is not greater than a preset proportion of the total amount of the original lighting data of the highest level of detail model.

[0095] In some embodiments, the determining unit 230 is configured to: determine the boundary region of adjacent detail level models in the cascaded coordinate space based on the distance between the virtual camera and each detail level model.

[0096] Each unit in the aforementioned image generation device 200 can be implemented entirely or partially through software, hardware, or a combination thereof. Each unit can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each unit.

[0097] The screen generation device 200 can be integrated into a terminal or server that has storage and a processor and thus computing power, or the screen generation device 200 can be the terminal or server.

[0098] Optionally, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0099] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device may be a terminal or a server. Figure 9 As shown, the computer device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 is electrically connected to the memory 302. Those skilled in the art will understand that the computer device structure shown in the figures does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0100] The processor 301 is the control center of the computer device 300. It connects various parts of the computer device 300 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 302, and calling data stored in the memory 302, it performs various functions of the computer device 300 and processes data, thereby performing overall processing of the computer device 300.

[0101] In this embodiment, the processor 301 in the computer device 300 loads the instructions corresponding to the processes of one or more computer programs into the memory 302 according to the following steps, and the processor 301 runs the computer programs stored in the memory 302 to realize various functions: Acquire sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene; determine the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera, and map the world coordinates of each level of detail model to the cascaded coordinate space; determine the boundary region of adjacent level of detail models in the cascaded coordinate space; acquire the original voxel data of the current level of detail model corresponding to the boundary region; load the sparse voxel lighting data in the boundary region, and perform a mixing process between the sparse voxel lighting data and the original voxel data to generate the rendered image of the virtual scene.

[0102] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0103] Optional, such as Figure 9 As shown, the computer device 300 also includes: a display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 9 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0104] The display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the computer device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program. Optionally, the touch panel may include a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, and transmits the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to the processor 301, and can receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel according to the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0105] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other computer devices, and to transmit and receive signals with network devices or other computer devices.

[0106] Audio circuitry 305 can be used to provide an audio interface between a user and a computer device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and output to processor 301 for processing. The audio data is then transmitted via radio frequency circuitry 304 to, for example, another computer device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and the computer device.

[0107] The input unit 306 can be used to receive input numbers, characters, or object feature information (such as fingerprints, irises, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0108] Power supply 307 is used to supply power to various components of computer device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0109] although Figure 9 As not shown in the diagram, computer equipment 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0110] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the screen generation method described in the embodiments of this application; for the sake of brevity, further details are omitted here.

[0111] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the screen generation method described in the embodiments of this application. For simplicity, further details are omitted here.

[0112] This application also provides a computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the screen generation method of this application. For brevity, further details are omitted here.

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

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

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

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

[0117] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

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

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

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

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

Claims

1. A method for generating an image, characterized in that, The method includes: Obtain the sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene; Based on the spatial position and observation depth of the virtual camera, the cascaded coordinate space corresponding to the virtual scene is determined, and the world coordinates of each detail level model are mapped to the cascaded coordinate space. Determine the boundary regions of adjacent detail level models in the cascaded coordinate space; Obtain the original voxel data of the current detail level model corresponding to the boundary region; The sparse voxel lighting data is loaded within the boundary area, and the sparse voxel lighting data is mixed with the original voxel data to generate the rendered image of the virtual scene.

2. The image generation method as described in claim 1, characterized in that, The step of determining the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera includes: Based on the spatial position and observation depth of the virtual camera, the virtual scene is divided into multiple cascaded regions centered on the virtual camera to determine the cascaded coordinate space corresponding to the virtual scene.

3. The image generation method as described in claim 1, characterized in that, The process of mixing the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene includes: The sparse voxel lighting data and the original voxel data are linearly interpolated and mixed to generate a rendered image with smooth visual transitions between adjacent detail level models in the virtual scene.

4. The image generation method as described in claim 1, characterized in that, Loading the sparse voxel illumination data within the boundary region includes: Determine the corresponding position of the boundary region in the cascaded coordinate space; The sparse voxel illumination data, which is pre-baked and stored and corresponds to the boundary region, is loaded into the corresponding position of the boundary region in the cascaded coordinate space.

5. The image generation method as described in claim 1, characterized in that, The method further includes: Obtain the raw dense voxel lighting data generated by pre-baking the highest level of detail model; The original dense voxel lighting data is adaptively downsampled to generate the sparse voxel lighting data, wherein the sampling density is dynamically adjusted according to the surface geometry complexity or vertex distribution density of the highest detail level model. Store the sparse voxel illumination data.

6. The image generation method as described in claim 5, characterized in that, Light baking is performed on the highest level of detail model to generate raw dense voxel lighting data, including: The original dense voxel lighting data is generated by baking the direct lighting information and sky lighting information of the highest level of detail model. The sky lighting information is the ambient light information that simulates the lighting of the sky hemisphere in the virtual scene.

7. The image generation method as described in claim 1, characterized in that, The sparse voxel lighting data is applicable to all detail-level models in the virtual scene.

8. The image generation method as described in claim 1, characterized in that, The total amount of data in the sparse voxel lighting data is less than the total amount of data in the original lighting data of the highest level of detail model.

9. The image generation method as described in claim 8, characterized in that, The total amount of the sparse voxel lighting data is no greater than a preset proportion of the total amount of the original lighting data of the highest level of detail model.

10. The image generation method as described in claim 1, characterized in that, Determining the boundary region of adjacent detail level models in the cascaded coordinate space includes: Based on the distance between the virtual camera and each detail level model, the boundary region of adjacent detail level models in the cascaded coordinate space is determined.

11. An image generation device, characterized in that, The device includes: The first acquisition unit is used to acquire sparse voxel lighting data corresponding to the highest level of detail model in the virtual scene. The generation unit is used to determine the cascaded coordinate space corresponding to the virtual scene based on the spatial position and observation depth of the virtual camera, and to map the world coordinates of each detail level model to the cascaded coordinate space. A determining unit is used to determine the boundary region of adjacent detail level models in the cascaded coordinate space; The second acquisition unit is used to acquire the original voxel data of the current detail level model corresponding to the boundary region; The processing unit is used to load the sparse voxel lighting data within the boundary area and to mix the sparse voxel lighting data with the original voxel data to generate the rendered image of the virtual scene.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to perform the screen generation method as described in any one of claims 1-10.

13. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, and the processor executing the screen generation method according to any one of claims 1-10 by calling the computer program stored in the memory.

Images