Data rendering method, device and equipment

Abstract

The embodiment of the invention provides a data rendering method, device and equipment, and the method comprises the steps: determining the visibility of each figure avatar in a to-be-rendered crowd scene graph at a current viewpoint, and then determining the LOD level of each figure avatar in the crowd scene graph according to the visibility of the figure avatar at the current viewpoint, according to the embodiment of the invention, the embodiment parameters corresponding to the figure avatars of different LOD hierarchies are stored in the instantiation grid cache corresponding to the LOD hierarchies, and finally, the figure avatars of different LOD hierarchies can be subjected to instantiation rendering according to the embodiment parameters in the instantiation grid cache.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data rendering method, apparatus, and device. Background Technology

[0002] Currently, progressive instantiation is one of the most effective algorithms for rendering 3D mesh crowds. However, this technique requires complex management when dealing with caching, and the computational overhead of caching management becomes unbearable when the crowd size is too large.

[0003] For example, in scenarios such as large-scale webpage 3D crowd rendering, the large number of character avatars to be rendered and the excessive time overhead of cache management can lead to rendering lag. Therefore, a faster and more reliable rendering solution for large-scale crowd scene images is needed. Summary of the Invention

[0004] The purpose of the embodiments in this specification is to provide a technical solution to improve the rendering efficiency and rendering effect of large-scale crowd scene graphs.

[0005] To achieve the above technical solution, the embodiments in this specification are implemented as follows: This specification provides a data rendering method, which includes: determining the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint; determining the Level of Dimension (LOD) to which each character avatar belongs based on the visibility of the character avatar from the current viewpoint; storing the avatar parameters corresponding to the character avatars at different LOD levels in an instantiated mesh cache corresponding to the LOD level; and instantiating and rendering the character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache.

[0006] This specification provides a data rendering apparatus, comprising: a visibility determination module for determining the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint; a hierarchy determination module for determining the LOD level of each character avatar in the crowd scene image based on the visibility of the character avatars from the current viewpoint; a parameter storage module for storing the avatar parameters corresponding to the character avatars at different LOD levels in an instantiated mesh cache corresponding to the LOD level; and a data rendering module for instantiating and rendering the character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache.

[0007] This specification provides an embodiment of a data rendering device, comprising: a processor; and a memory arranged to store computer-executable instructions, wherein the executable instructions, when executed, cause the processor to: determine the visibility of each character avatar in a crowd scene to be rendered from the current viewpoint; determine the Level of Dimension (LOD) to which each character avatar in the crowd scene belongs based on the visibility of the character avatars from the current viewpoint; store the avatar parameters corresponding to the character avatars at different LOD levels in an instantiated mesh cache corresponding to the LOD level; and perform instantiated rendering of the character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache.

[0008] This specification provides a data rendering system comprising a material layer subsystem, a geometry layer subsystem, a rendering layer subsystem, and an application layer subsystem. The material layer subsystem is configured to load texture maps and / or material parameters corresponding to a crowd scene image to be rendered, and to provide editing functions for each character avatar in the crowd scene image. The geometry layer subsystem is configured to determine the visibility of each character avatar in the crowd scene image at the current viewpoint, and based on the visibility of the character avatar at the current viewpoint, determine the Level of Dimension (LOD) to which each character avatar belongs, so as to store the avatar parameters corresponding to the different LOD levels in an instantiated mesh cache corresponding to the LOD level. The rendering layer subsystem is configured to instantiate and render the character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache. The application layer subsystem is configured to control the changes in the avatar parameters corresponding to the character avatars based on changes in the viewpoint.

[0009] This specification also provides a storage medium for storing computer-executable instructions. When executed by a processor, the executable instructions perform the following process: determining the visibility of each character avatar in a crowd scene to be rendered from the current viewpoint; determining the LOD level of each character avatar in the crowd scene based on the visibility of the character avatar from the current viewpoint; storing the avatar parameters corresponding to the character avatars at different LOD levels in an instantiated mesh cache corresponding to the LOD level; and instantiating and rendering the character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache.

[0010] This specification also provides a computer program product, including a computer program that, when executed by a processor, performs the following process: determining the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint; determining the LOD level to which each character avatar in the crowd scene image belongs based on the visibility of the character avatar from the current viewpoint; storing the avatar parameters corresponding to the character avatars at different LOD levels in an instantiated mesh cache corresponding to the LOD level; and instantiating and rendering the character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 This is a schematic diagram illustrating the implementation environment of one of the data rendering methods described in this specification; Figure 2 This is a schematic diagram illustrating the rendering process of a character avatar in this manual; Figure 3 This is a schematic diagram of a diverse population matrix as described in this specification; Figure 4 This is a schematic diagram illustrating the diversity of human incarnations in this specification; Figure 5 This is a schematic diagram of a resource index storage format described in this specification; Figure 6 This is a schematic diagram of a rendered crowd scene as described in this specification; Figure 7 This is a schematic diagram of the structure of a rendered crowd scene image as described in this specification; Figure 8 This is a schematic diagram of a four-layer Web3D scheduling architecture for a massive user base, as described in this specification. Figure 9 This is a schematic diagram illustrating the process of determining a character avatar in this specification; Figure 10 This explanation includes a separate diagram illustrating the process of determining a character's persona. Figure 11 This is a schematic diagram illustrating the process of determining the visibility of a character avatar in this specification. Figure 12 This is a flowchart illustrating the process of determining the visibility of a character avatar in this specification. Figure 13This is a schematic diagram illustrating one of the parsing-rendering-caching processes described in this manual; Figure 14 This is a schematic diagram illustrating another character avatar rendering process in this manual; Figure 15 This is a schematic diagram illustrating the rendering precision corresponding to one LOD level in this specification; Figure 16 This is a schematic diagram of a data rendering device according to the present specification; Figure 17 This is a schematic diagram of a data rendering device described in this specification. Detailed Implementation

[0012] This specification provides a data rendering method, apparatus, and device through its embodiments.

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0014] This specification provides a technical solution to improve the rendering efficiency and effect of large-scale crowd scene graphs. In scenarios such as large-scale webpage 3D crowd rendering, the large number of character avatars to be rendered leads to excessive cache management time overhead, causing rendering lag. This solution determines the visibility of each character avatar in the crowd scene graph from the current viewpoint. Based on the visibility, the Level of Dimension (LOD) of each character avatar in the crowd scene graph is determined. The avatar parameters corresponding to different LOD levels are stored in the instantiated mesh cache corresponding to the LOD level. Based on the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered. In this way, on the one hand, by storing the avatar parameters corresponding to character avatars at different LOD levels in the instantiated mesh cache corresponding to the LOD level, the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars can be avoided, thus improving the rendering effect of large-scale crowd scene graphs. On the other hand, by dividing the character avatars into LOD levels based on the visibility of the current viewpoint and performing instantiated rendering according to the LOD level, a smooth transition of character avatar details can be achieved, avoiding problems such as flickering of character avatars on the rendered screen due to frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene graphs. For specific processing details, please refer to the specific content in the following embodiments.

[0015] The data rendering methods described in one or more embodiments of this specification are applicable to the data rendering implementation environment, such as... Figure 1 As shown, the implementation environment includes at least: Client 100 and server 200. Furthermore, server 200 can be configured with various network models and algorithms, among which: Client 100 can run on terminal devices, which can be mobile phones, personal computers, tablets, e-book readers, wearable devices, devices that interact with information based on AR (Augmented Reality) and VR (Virtual Reality), and laptop computers, etc. Client 100 can be installed on terminal devices, and Client 100 can be an application, a browser, or a subroutine embedded in an application, etc.

[0016] Server 200 can run on a server, which can be one or more servers, a server cluster consisting of several servers, or a cloud server on a cloud computing platform. Server 200 can be installed on the server. Server 200 can be an application or a subroutine embedded in an application. Various network models and algorithms can be integrated into server 200, or server 200 can call one or more of various network models and algorithms to perform corresponding operations.

[0017] In addition, it may include a database 300, which may be set in the server on which the server 200 runs, or outside the server on which the server 200 runs. The database 300 may store basic crowd model data of crowd scene diagrams, avatar parameters corresponding to character avatars, etc.

[0018] In this implementation environment, the server 200 can determine the visibility of each character avatar in the crowd scene graph to be rendered from the current viewpoint. Based on the visibility of the character avatars from the current viewpoint, the server 200 determines the LOD level to which each character avatar in the crowd scene graph belongs. The server 200 can store the avatar parameters corresponding to the character avatars of different LOD levels in the instantiated mesh cache corresponding to the LOD level. Based on the avatar parameters in the instantiated mesh cache, the server 200 instantiates and renders the character avatars of different LOD levels on the client 100.

[0019] The crowd scene image to be rendered can be collected by the client 100. For example, the crowd scene image to be rendered can be a scene image corresponding to a large-scale online conference or a large-scale online exhibition collected by the client 100. Alternatively, the crowd scene image to be rendered can also be a scene image determined by the server 200 according to the instruction triggered by the client 100. For example, the crowd scene image to be rendered can be a scene image corresponding to a large-scale online game. That is, the user can trigger the execution instruction of a large-scale online game on the client 100, and the server 200 can obtain the crowd scene image corresponding to the large-scale online game based on the execution instruction triggered by the client 100.

[0020] like Figure 2 As shown in the embodiments of this specification, a data rendering method is provided. The execution subject of this method can be a server, which can be a single independent server or a server cluster composed of multiple servers. This embodiment takes a server as the execution subject as an example for detailed description, and the method specifically includes the following steps: In step S202, the visibility of each character avatar in the crowd scene to be rendered at the current viewpoint is determined.

[0021] Among them, crowd scene images can be images corresponding to scenarios such as large-scale online games, large-scale online conferences, large-scale online exhibitions, large-scale online social networking, and large-scale crowd emergency simulations.

[0022] In implementation, such as Figure 3 As shown, the server can read the crowd scene image and parse the basic crowd model, extract data such as character mesh, character actions, and character facial expressions. Then, it can compress the facial expression and action data into texture form to obtain diverse dynamic textures. At the same time, the server can also read various clothing textures and the initial crowd position saved in the crowd scene image, and generate a crowd personality matrix by randomly assigning clothing.

[0023] Then, the server can generate multiple sets of LOD simplified meshes based on the initial character mesh, pass in diverse dynamic textures, and edit diverse crowd shaders to parse the diverse dynamic textures. Finally, the server can assign clothing to the crowd and initialize position information according to the crowd personality matrix to complete the LOD crowd initialization on the GPU.

[0024] The server can determine the visibility of each character avatar in the current viewpoint based on the position information of each avatar in the crowd scene image to be rendered. For example, if the character avatar is located in the first preset area of ​​the crowd scene image (such as an area with the center point of the crowd scene image as the center and a radius equal to half the shortest side of the crowd scene image), then the visibility of the character avatar in the current viewpoint can be the first visibility. If the character avatar is located in the second preset area of ​​the crowd scene image (such as an area other than the first preset area with the center point of the crowd scene image as the center and a radius equal to half the shortest side of the crowd scene image), then the visibility of the character avatar in the current viewpoint can be the second visibility. If the character avatar is located in the third preset area of ​​the crowd scene image (such as an area other than the first and second preset areas of the crowd scene image), then the visibility of the character avatar in the current viewpoint can be the third visibility.

[0025] Alternatively, the server can use a pre-trained visibility determination model to determine the visibility of each character avatar in the crowd scene at the current viewpoint. The visibility determination model can be built based on a preset deep learning algorithm.

[0026] Alternatively, the server can obtain parameter information such as the rendering priority of each character avatar, and determine the visibility of each character avatar at the current viewpoint based on the parameter information of each character avatar and the position information of each character avatar in the crowd scene map at the current viewpoint.

[0027] Furthermore, the above-mentioned method for determining visibility is an optional and feasible method. In practical application scenarios, there can be a variety of different methods. Different methods can be selected according to different practical application scenarios. This specification does not specifically limit this method in the embodiments.

[0028] In step S204, the LOD level of each character avatar in the crowd scene is determined based on the visibility of the character avatar at the current viewpoint.

[0029] In implementation, the server can also determine the Levels of Detail (LOD) level of each character avatar based on the number of character avatars, the number of web resources, and the visibility of each character avatar from the current viewpoint. Furthermore, the higher the visibility of a character avatar from the current viewpoint, the lower its corresponding LOD level.

[0030] For example, assuming that the LOD level can include four levels: LOD0, LOD1, LOD2, and LOD3, if the crowd scene graph contains 10,000 character avatars, and based on the number of web resources, it can be determined that the LOD0 level can contain 10 character avatars, the LOD1 level can contain 100 character avatars, the LOD2 level can contain 1,000 character avatars, and the LOD3 level can contain 10,000 character avatars, then the lower the LOD level, the higher the rendering accuracy.

[0031] Therefore, the server can determine the LOD level of each character avatar based on the visibility of the avatar at the current viewpoint and the number of character avatars corresponding to each LOD level. For example, the top 10 character avatars with higher visibility can be determined as LOD0 level.

[0032] Furthermore, the method for determining the LOD level to which the aforementioned character avatar belongs is an optional and feasible method. In practical application scenarios, there can be a variety of different methods. Different methods can be selected according to different practical application scenarios. This specification does not specifically limit this method in the embodiments.

[0033] In step S206, the avatar parameters corresponding to the character avatars of different LOD levels are stored in the instantiated mesh cache corresponding to the LOD level.

[0034] In implementation, each character avatar can include multiple parts such as hair, face, torso, top, pants, and shoes, and each part can use different materials, for example, such as... Figure 4 As shown, character avatars can be diversified through model combination diversification, shape editing diversification, and material diversification in the diversification layer. Avatar parameters can include the materials used for each character avatar.

[0035] The server can split the level-of-detail (LOD) cache based on the index cache: the materials used by each character avatar can be stored using a resource index, for example... Figure 5As shown, each avatar can contain k different parts, such as hair, face, torso, top, pants, and shoes. The number of assets for each part is j, so k*j represents the total number of assets for all parts. Each part of the avatar corresponds to multiple asset meshes in the asset library, and the MeshIndex Cache records the ID number of the asset mesh corresponding to each part of the avatar. The number of MeshIndexCaches is k, the number of parts in the avatar, and the length of the MeshIndex Cache is N, the number of avatars. The Avatar LOD Cache records the LOD level of each avatar. The Avatar LOD Cache can be divided into k*j Mesh LOD Caches, and each Mesh LOD Cache records which LOD level each asset is used by.

[0036] In step S208, character avatars at different LOD levels are instantiated and rendered according to the avatar parameters in the instantiated mesh cache.

[0037] In implementation, the server can obtain LOD cache data for LOD crowds in real time from WebGPU, and use instantiation rendering technology to merge multiple groups of crowds at different LOD levels into a single draw call, rendering it on the screen in real time. The rendered crowd scene graph can be displayed as follows: Figure 6 As shown in the figure. The structure of the rendered crowd scene graph can be as follows: Figure 7 As shown.

[0038] like Figure 8 As shown, a four-layer Web3D scheduling architecture for a massive user base can be constructed based on the above data rendering method. These four layers, from top to bottom, are the application layer, material layer, geometry layer, and rendering layer.

[0039] In this four-layer architecture, the upper layers are responsible for implementing effects, such as dynamic and diverse visual effects, while the lower layers are responsible for performance optimization, such as low-level code and its relationship with physical hardware.

[0040] This specification provides a data rendering method that determines the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint. Based on the visibility of the character avatars from the current viewpoint, the Level of Dimension (LOD) of each character avatar in the crowd scene image is determined. The avatar parameters corresponding to different LOD levels are stored in instantiated mesh caches corresponding to the LOD levels. Based on the avatar parameters in the instantiated mesh caches, character avatars at different LOD levels are instantiated and rendered. In this way, on the one hand, by storing the avatar parameters corresponding to different LOD levels in instantiated mesh caches corresponding to the LOD levels, the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars can be avoided, thus improving the rendering effect of large-scale crowd scene images. On the other hand, by dividing the character avatars into LOD levels based on the visibility from the current viewpoint and instantiating and rendering according to the LOD levels, smooth transitions of character avatar details can be achieved, avoiding flickering problems on the rendered screen caused by frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene images.

[0041] In practical applications, the initial character avatars in the crowd scene image to be rendered can also be filtered to determine the character avatars in the crowd scene image. There are various specific methods for filtering the initial character avatars; the following is one optional method, such as... Figure 9 As shown, the specific process may include the following steps S902 to S906.

[0042] In step S902, the projection depth of each initial character avatar in the crowd scene to be rendered at the current viewpoint is determined.

[0043] In implementation, the server can assign a GPU thread to each character avatar. Within the GPU thread, the center coordinates of the avatar's bounding sphere corresponding to each initial character avatar are obtained. Then, the corresponding 3D vector is processed sequentially through model transformation, view transformation, and projection transformation. After these three transformations, a new 3D vector is obtained. The first and second dimensions of this new 3D vector can represent the horizontal and vertical coordinates projected onto the screen, respectively, while the third dimension can represent the distance from the center of the avatar's bounding sphere to the screen (i.e., the projection depth of the initial character avatar at the current viewpoint).

[0044] In step S904, the depth information of the occluded objects corresponding to the crowd scene image to be rendered at the current viewpoint is determined.

[0045] In implementation, the server can input all building triangular mesh models. Starting from the current viewpoint, a ray is emitted through a pixel on the screen, and the intersection of this ray with a building triangular face is calculated. If the ray intersects a building triangular face, the distance from the current viewpoint to the intersection point is calculated; this distance is the depth of the corresponding pixel. This process is repeated for each pixel on the screen in the rasterization pipeline to obtain a complete depth map.

[0046] In step S906, the initial character avatar is screened based on its projection depth, position information in the crowd scene map, and depth information of occluded objects to determine the character avatar.

[0047] In practice, the server can compare the projected depth of the center coordinates of the avatar bounding sphere of each initial character avatar with the building depth map in the compute shader to determine the occlusion status of the initial character avatar.

[0048] For example, if the initial character avatar i is obscured by the building model, the initial character avatar can be removed from the initial crowd, and the value of the i-th position in the LOD Cache can be initialized to -1.

[0049] In practical applications, step S906 above filters the initial character avatar based on its projection depth, position information in the crowd scene map, and depth information of occluded objects. The specific processing method for determining the character avatar can vary; the following provides one optional method, such as... Figure 10 As shown, the specific process may include the following steps, S9062.

[0050] In step S9062, based on the projection depth of the initial character avatar, the position information of the initial character avatar in the crowd scene map, and the depth information of the occluded objects, the first character avatar among the initial character avatars that is not occluded by the occluded objects is determined, and based on the first character avatar, the character avatar is determined.

[0051] In implementation, the server determines the projected coordinates of the first character's avatar's surrounding sphere in the crowd scene map based on the sphere's position information. Then, the server can determine whether the first character's avatar is located within the visible cone based on these projected coordinates.

[0052] Based on the projected coordinates of the center point of the avatar's surrounding sphere in the crowd scene, determine the distance from the center point to the screen. Then, based on the distance from the center point to the screen and the radius of the avatar's surrounding sphere, determine the radius of the projected light spot corresponding to the first character avatar. Finally, based on the projected coordinates of the avatar's surrounding sphere in the crowd scene and the radius of the projected light spot corresponding to the first character avatar, determine whether the first character avatar is located within the visible cone.

[0053] Finally, the server can identify the first character avatar within the visible cone as the character avatar.

[0054] Specifically, the server can calculate the distance from the center point to the screen and the radius of the sphere based on the center projection coordinates of the sphere surrounding the first character avatar. Then, based on these coordinates, the server can calculate the radius of the projected light spot. Finally, the server can determine whether the light spot is visible on the screen based on the projection position and the radius of the light spot. For example, the server can use the WebGPU's compute shaders to process the sphere information of each first character avatar in parallel, thereby determining which first character avatars are not within the view frustum. If first character avatar i is not within the view frustum, the value at position i in the LOD Cache can be initialized to -1.

[0055] After the above operations, the character avatars at positions with a value of -1 in the LOD Cache are those not within the view frustum or obscured by architectural models. Character avatars at other positions are visible from the current viewpoint (i.e., they are the character avatars in the crowd scene to be rendered). For example... Figure 11 As shown, the server can update the initial crowd based on the data in the LOD Cache, and allocate different numbers of character avatars to the crowd at each LOD level based on resource usage. It can also generate the simplest particle-based level and place avatars with an LOD Cache value of -1 at this level. In this way, character avatars with an LOD level of -1 will not be rendered at the current viewpoint, thus saving processing resources, avoiding rendering stutters, and improving rendering efficiency.

[0056] In practical applications, the specific methods for determining the visibility of each character avatar in the crowd scene image to be rendered at the current viewpoint in step S202 above can vary, such as... Figure 12 As shown, another optional determination method is provided below, which may specifically include the following steps S2022.

[0057] In step S2022, the visibility of each character avatar at the current viewpoint is determined based on the distance from the center point of the avatar's enclosing sphere to the screen and the farthest distance rendered by the camera.

[0058] In practice, the server can determine the ratio between the distance from the center point of the avatar's bounding sphere to the screen and the farthest distance rendered by the camera, and determine the visibility of each avatar at the current viewpoint based on the difference between the square of the ratio and a set value.

[0059] The visibility of a character avatar depends on the area projected onto the screen, and the size of the light spot is inversely proportional to the square of the distance di from the center of the enclosing sphere to the screen. Assuming the furthest distance rendered by the camera is D, the visibility vdi is 1 when the distance is 0, and 0 when the distance is greater than or equal to D. Therefore, the visibility vd_i of character avatar i is equal to Fun(1 - (d_i / D)^2), thus limiting the visibility of the character avatar to between 0 and 1.

[0060] Next, the server can calculate the value of the corresponding position of the character avatar visible from the current viewpoint in the LOD Cache, and dynamically calculate the LOD value of the visible avatar within the current field of view based on the visibility of the character avatar, and update the corresponding parameters in the LOD Cache.

[0061] Furthermore, since updating the instantiated mesh cache has a significant overhead, the update operation of the instantiated mesh cache can be completed by GPU parallel threads. This requires multiple GPU parallel threads to process the same instantiated mesh cache. In order to achieve coordination between these GPU parallel threads, a shared counter needs to be set for the instantiated mesh cache to prevent multiple threads from modifying the same cache metadata at the same time.

[0062] Assuming each InstancedMesh Cache corresponds to a specific mesh asset within a certain Level of Detail (LOD), and the number of LODs is denoted as l, then the number of InstancedMesh Caches is k*j*l. The server can calculate the number of character avatars in each LOD and then count the number of references for each mesh asset in that LOD. These reference counts represent the effective length of each InstancedMesh Cache.

[0063] The server can store the avatar parameters of a character into the corresponding InstancedMesh Cache. Each InstancedMesh Cache can record the avatar parameters (such as position, orientation, size, color, etc.) for a specific mesh within a given LOD level. The server can input all the avatar parameters for each mesh asset in each LOD into the corresponding InstancedMesh Cache. Figure 13 As shown, since the LOD of the crowd is refreshed in real time, the InstancedMesh Cache associated with LOD is also refreshed in real time.

[0064] Furthermore, since the number of objects corresponding to each LOD layer in the field of view is constantly changing, different LOD layers correspond to different InstancedMesh objects. The more objects an InstancedMesh object represents, the larger the corresponding video memory it requires. A shared counter can be used to record the size of the video memory area currently occupied by the InstancedMesh object.

[0065] In practical applications, the specific processing method for instantiating and rendering character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache in step S208 above can vary. The following provides one optional method for determining this method, such as... Figure 14 As shown, the specific process may include the following steps, S2082.

[0066] In step S2082, based on the rendering precision corresponding to the LOD level and the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

[0067] In implementation, for example, Figure 15 As shown, the lower the LOD level, the higher the corresponding rendering precision (i.e., the more faces, the higher the level of detail). The server can instantiate and render character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache, according to the rendering precision corresponding to the LOD level.

[0068] In addition, for character avatars with a LOD level of -1 (i.e., character avatars that are occluded or have a visibility of 0 at the current viewpoint), a preloading mechanism can be used to predict which character avatars with a LOD level of -1 may enter the visible cone at the next viewpoint, and load the avatar parameters of the character avatar with a low precision (such as a precision lower than the preset rendering precision value) to reduce rendering latency.

[0069] In this way, to solve the problems of management overhead and rendering lag caused by excessive instantiated grid cache data volume, first, the server can perform occlusion culling using depth map comparison, and combine it with visible frustum picking to dynamically divide the LOD levels of all character avatars, which can reduce the single-frame rendering data volume. Second, through cache splitting and parallel update, the avatar parameters of the character avatars can be split into multi-level component detail level caches according to body parts and materials, and combined with a shared counter to only update the necessary cache segments, reducing the data refresh overhead. Finally, the instantiated rendering technology can be adopted to integrate the instances of different LOD levels into a single draw call, which can reduce the communication loss between the CPU and the GPU and improve the overall rendering efficiency.

[0070] To solve the flickering problem during perspective switching caused by qualitative visibility analysis, first, the server can dynamically evaluate the distance weight of the character avatar to the screen based on quantitative visibility calculation, using the visibility function vd_i = Fun(1 - (d_i / D)^2). For avatars close to the visibility threshold (d_i<D), even if they are currently invisible, they are still retained in the cache at the lowest LOD to avoid perspective mutation problems caused by complete culling. Second, combined with incremental cache update, only the LOD level parameters of the character avatars within the current field of view are locally refreshed, and the avatar details are ensured to smoothly transition during perspective changes through real-time LOD adjustment, rather than instant loading. Finally, a dynamic LOD preloading mechanism is introduced to predict the avatars in the frustum that may enter the next viewpoint based on visibility, and preload their data at a low-precision LOD in advance to reduce rendering latency. Through the synergistic effect of the three, it is possible to avoid screen flickering under frequent perspective switching, and at the same time reduce the computational load of real-time rendering through preloading and local update, achieving a smooth user experience.

[0071] The server can separate dynamic and static data by compressing dynamic information and storing it as a texture map. In addition, by using a highly reusable geometric mesh to implement a highly lightweight data structure, it can reduce the transmission load while improving the parsing efficiency. The server uses WebGPU shaders to build a parallel processing framework, which can achieve GPU-accelerated operations for occlusion culling and visible frustum picking. In addition, an automated cache update mechanism can maintain the data stream and achieve real-time instantiated rendering output.

[0072] The server achieves quantitative visibility analysis through view distance and projected area. It can drive incremental mesh generation by evaluating the visibility of crowd avatars, dynamically constructing adaptive multi-LOD level instantiated meshes to balance crowd rendering quality and computational power consumption. By splitting the crowd cache into multi-LOD levels, multi-limb, and multi-pose units, fine-grained updates can be achieved while avoiding full data operations, reducing the computational load required for each update. Dynamically evaluating avatar reuse rate, screen coverage, and other multi-dimensional indicators allows for the construction of a dynamic cache replacement algorithm, ultimately achieving real-time cache update efficiency.

[0073] By combining the above technologies, a unified scheduling algorithm for online parsing, rendering, and caching of massive crowds based on WebGPU can be implemented. A highly efficient and collaborative technical system has been constructed to address the real-time rendering and caching management challenges of large-scale triangular mesh crowd scenes. Simultaneously, a fine-grained parameter caching splitting mechanism and a GPU parallel update strategy are designed to achieve low-overhead real-time refreshing of diverse crowd data. The resulting system deeply integrates the parallel computing capabilities of WebGPU, supporting smooth rendering of millions of triangular meshes on the webpage. It reduces memory consumption and rendering latency, resolves screen flickering issues during viewpoint switching, and ensures stable high frame rate operation, demonstrating powerful real-time interactive performance for large-scale 3D crowd scenes.

[0074] This specification provides a data rendering method that determines the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint. Based on the visibility of the character avatars from the current viewpoint, the Level of Dimension (LOD) of each character avatar in the crowd scene image is determined. The avatar parameters corresponding to different LOD levels are stored in instantiated mesh caches corresponding to the LOD levels. Based on the avatar parameters in the instantiated mesh caches, character avatars at different LOD levels are instantiated and rendered. In this way, on the one hand, by storing the avatar parameters corresponding to different LOD levels in instantiated mesh caches corresponding to the LOD levels, the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars can be avoided, thus improving the rendering effect of large-scale crowd scene images. On the other hand, by dividing the character avatars into LOD levels based on the visibility from the current viewpoint and instantiating and rendering according to the LOD levels, smooth transitions of character avatar details can be achieved, avoiding flickering problems on the rendered screen caused by frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene images.

[0075] The above describes the data rendering method provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a data rendering device, such as... Figure 16 As shown.

[0076] The data rendering device includes: a visibility determination module 1601, a hierarchy determination module 1602, a parameter storage module 1603, and a data rendering module 1604, wherein: The visibility determination module 1601 is used to determine the visibility of each character avatar in the crowd scene to be rendered at the current viewpoint; The level determination module 1602 is used to determine the LOD level of each character avatar in the crowd scene map based on the visibility of the character avatar at the current viewpoint. The parameter storage module 1603 is used to store the avatar parameters corresponding to the character avatars of different LOD levels in the instantiated grid cache corresponding to the LOD level respectively; The data rendering module 1604 is used to instantiate and render character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache.

[0077] In the embodiments described in this specification, the device further includes: The first determining module is used to determine the projection depth of each initial character avatar in the crowd scene to be rendered at the current viewpoint. The second determining module is used to determine the depth information of the occludeable objects corresponding to the current viewpoint in the crowd scene image to be rendered; The filtering module is used to filter the initial character avatar based on the projection depth of the initial character avatar, the position information of the initial character avatar in the crowd scene map, and the depth information of the occludeable object, so as to determine the character avatar.

[0078] In the embodiments of this specification, the filtering module is used for: Based on the projection depth of the initial character avatar, the position information of the initial character avatar in the crowd scene map, and the depth information of the occluder, a first character avatar that is not occluded by the occluder is determined among the initial character avatars, and the character avatar is determined based on the first character avatar.

[0079] In the embodiments of this specification, the filtering module is used for: Based on the position information of the sphere surrounding the first character's avatar in the crowd scene map, determine the projection coordinates of the sphere surrounding the first character's avatar in the crowd scene map; Based on the projection coordinates of the avatar surrounding the first character avatar in the crowd scene diagram, determine whether the first character avatar is located within the visible cone; The first character avatar within the visible cone is identified as the character avatar.

[0080] In the embodiments of this specification, the filtering module is used for: The distance from the center point to the screen is determined based on the projection coordinates of the center point of the sphere surrounding the first character's avatar in the crowd scene diagram. The radius of the projected light spot corresponding to the first character avatar is determined based on the distance from the center point to the screen and the radius of the avatar's surrounding sphere. Based on the projection coordinates of the avatar surrounding the first character in the crowd scene diagram, and the radius of the projection spot corresponding to the first character, determine whether the first character is located within the visible cone.

[0081] In the embodiments described in this specification, the visibility determination module 1601 is used for: The visibility of each character avatar at the current viewpoint is determined based on the distance from the center point of the avatar's encircling sphere to the screen, and the farthest distance rendered by the camera.

[0082] In the embodiments described in this specification, the visibility determination module 1601 is used for: Determine the ratio between the distance from the center point of the avatar's bounding sphere corresponding to the current viewpoint to the screen, and the farthest distance rendered by the camera; The visibility of each character avatar at the current viewpoint is determined based on the difference between the square of the ratio and a set value.

[0083] In this embodiment of the specification, the data rendering module 1604 includes: Based on the rendering precision corresponding to the LOD level, and using the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

[0084] This specification provides a data rendering apparatus that can determine the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint. Based on the visibility of the character avatars from the current viewpoint, it determines the Level of Dimension (LOD) to which each character avatar belongs in the crowd scene image. The avatar parameters corresponding to different LOD levels are stored in instantiated mesh caches corresponding to the LOD levels. Based on the avatar parameters in the instantiated mesh caches, the avatars at different LOD levels are instantiated and rendered. In this way, on the one hand, by storing the avatar parameters corresponding to different LOD levels in instantiated mesh caches corresponding to the LOD levels, the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars can be avoided, thus improving the rendering effect of large-scale crowd scene images. On the other hand, by dividing the character avatars into LOD levels based on the visibility from the current viewpoint and instantiating and rendering according to the LOD levels, smooth transitions of character avatar details can be achieved, avoiding flickering problems on the rendered screen caused by frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene images.

[0085] This specification provides a data rendering system, which includes a material layer subsystem, a geometry layer subsystem, a rendering layer subsystem, and an application layer subsystem, wherein: The material layer subsystem is configured to load the texture maps and / or material parameters corresponding to the crowd scene image to be rendered, and to provide editing functions for each character avatar in the crowd scene image to be rendered.

[0086] The geometry layer subsystem is configured to determine the visibility of each character avatar in the crowd scene graph to be rendered from the current viewpoint, and based on the visibility of the character avatar from the current viewpoint, determine the LOD level to which each character avatar in the crowd scene graph belongs, so as to store the avatar parameters corresponding to the character avatars of different LOD levels in the instantiated mesh cache corresponding to the LOD level respectively.

[0087] The rendering layer subsystem is configured to instantiate and render character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache.

[0088] The application layer subsystem is configured to control the changes in the avatar parameters corresponding to the character avatar based on changes in the viewpoint.

[0089] This data rendering system can be based on, for example... Figure 8The four-layer Web3D scheduling architecture for massive crowds is shown. The material layer subsystem can output a diverse crowd matrix corresponding to the task avatar in the crowd scene graph. The geometry layer subsystem can perform LOD layering processing on the character avatar based on data such as the diverse crowd matrix. That is, the visibility of the character avatar at the current viewpoint can be determined by the material layer subsystem, and the LOD level of each character avatar in the crowd scene graph can be determined based on the visibility. The avatar parameters corresponding to the character avatars of different LOD levels are stored in the instantiated mesh cache corresponding to the LOD level.

[0090] The rendering layer subsystem can perform incremental instantiation rendering based on the avatar parameters in the instantiated mesh cache to output real-time crowd visualization results. The application layer subsystem, when the viewpoint changes, can determine the avatar parameters corresponding to the character avatar at the changed viewpoint through the aforementioned material layer subsystem, geometry layer subsystem, and rendering layer subsystem. It also updates the multi-level crowd cache in real-time to reflect changes in crowd movement, emotions, etc., after the viewpoint changes. In other words, the application layer subsystem can control the changes in the avatar parameters corresponding to the character avatar based on changes in viewpoint.

[0091] This specification provides a data rendering system. On the one hand, by storing the avatar parameters corresponding to character avatars at different LOD levels in the instantiated mesh cache corresponding to the LOD level, the system avoids the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars, thus improving the rendering effect of large-scale crowd scene images. On the other hand, by dividing the character avatars into LOD levels based on the visibility of the current viewpoint and performing instantiated rendering according to the LOD level, the system can achieve smooth transition of character avatar details, avoiding problems such as flickering of character avatars on the rendered screen due to frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene images.

[0092] In practical applications, the material layer subsystem is configured to provide overall and partial editing of the body shape of each character avatar in the crowd scene image, as well as one or more functions such as action type editing, speed editing, and clothing editing.

[0093] The overall body shape editing can include height editing, while the partial body shape editing can include the thickness of body parts. Body parts can include one or more of the following: head, arms, stomach, and legs.

[0094] Specifically, the material layer subsystem can be used to expand the diversity of the crowd. Its functions include providing editing capabilities for each character avatar within the crowd, such as overall and partial body shape editing (e.g., overall shape editing can be height, while partial shape editing can be the thickness of different body parts like the head, arms, stomach, and legs), action type editing (including standing, walking, sitting, running, etc.), speed editing, and clothing editing. The material layer subsystem can also be used to load texture maps and material parameters. This loading process does not expose the program interface; it can be automatically loaded when the program needs the corresponding data.

[0095] In practical applications, the application layer subsystem is configured to control one or more of the following: position transformation, orientation transformation, and size scaling of the character avatar. The application layer subsystem can be used to provide 3D engine functionality, specifically controlling the position transformation, orientation transformation, and size scaling of each character avatar within a crowd.

[0096] In practical applications, the geometry layer subsystem is configured to control the geometric resolution of the human avatar within the visual cone and the loading of geometric data.

[0097] In addition, the geometry layer subsystem is configured to use a progressive mesh loading method for loading the geometry of the human avatar, which can improve the speed of scene initialization. The geometry loading process is automated and does not expose any program interfaces.

[0098] In practical applications, the rendering subsystem encapsulates the GPU's vertex shader and fragment shader. The rendering subsystem is responsible for improving rendering quality through instantiation rendering techniques, handling various materials and lighting effects, and ensuring compatibility with different GPU hardware devices.

[0099] It should be noted that the above data rendering method can be executed by a data rendering system as the execution subject. Based on the specific architecture of the data rendering system, the processing of steps S202 to S208 is achieved through the interaction between the various subsystems therein. In addition, besides implementing the method embodiments of steps S202 to S208, the specific architecture of the data rendering system can also implement other method embodiments described above. For relevant details, please refer to the description of the method embodiments, which will not be repeated here.

[0100] The above are the data rendering apparatuses provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a data rendering device, such as... Figure 17 As shown.

[0101] The data rendering device can provide a terminal device or server, etc., for the above embodiments.

[0102] like Figure 17 As shown, device 1700 mainly consists of a communication interface 1702, a user interface 1704, a processor 1706, and a data storage 1708. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 1710. The communication interface 1702 enables device 1700 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 1702 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 1702 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 1702 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 1702 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0103] User interface 1704 includes receiving user input and providing output to the user. Therefore, user interface 1704 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 1704 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 1704 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 1700 may support remote access from other devices via communication interface 1702 or another physical interface (not shown). User interface 1704 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 1704 can also be configured as a display device for rendering or displaying text fragments.

[0104] The processor 1706 may contain one or more general-purpose processors and / or special-purpose processors.

[0105] Data storage 1708 may include one or more volatile storage components and may be integrated wholly or partially with processor 1706. Data storage 1708 may include removable and non-removable components.

[0106] Processor 1706 is capable of executing program instructions 1718 (e.g., compiled or uncompiled program logic and / or machine code) stored in data store 1708 to perform the various functions described herein. Data store 1708 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 1700, enable device 1700 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 1718 by processor 1706 may result in processor 1706 using data 1717.

[0107] For example, program instructions 1718 may include an operating system 1722 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 1700 and one or more applications 1720 (e.g., a browser, social application, or game application). Similarly, data 1717 may include operating system data 1716 and application data 1714. Operating system data 1716 is primarily accessible to the operating system 1722, while application data 1714 is primarily accessible to one or more applications 1720. Application data 1714 may reside in a file system visible or hidden from the user of device 1700.

[0108] Application 1720 can communicate with operating system 1717 through one or more application programming interfaces (APIs). These APIs help application 1720 read and / or write application data 1714, transmit or receive information via communication interface 1702, receive or display information on user interface 1704, etc.

[0109] In some terminology, application 1720 may be simply referred to as "app". Furthermore, application 1720 can be downloaded to device 1700 through one or more online app stores or app markets. However, applications can also be installed on device 1700 in other ways, such as through a web browser or a physical interface on device 1700 (e.g., a USB port).

[0110] Specifically, in this embodiment, the data rendering device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the data rendering device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: Receive risk detection requests for target videos; Determine the visibility of each character avatar in the crowd scene to be rendered from the current viewpoint; Based on the visibility of the character avatar at the current viewpoint, determine the LOD level of each character avatar in the crowd scene diagram; The avatar parameters corresponding to the character avatars at different LOD levels are stored in the instantiated grid cache corresponding to the LOD level, respectively. Based on the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

[0111] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the data rendering device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0112] This specification provides a data rendering device that can determine the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint. Based on the visibility of the character avatars from the current viewpoint, the Level of Dimension (LOD) of each character avatar in the crowd scene image is determined. The avatar parameters corresponding to different LOD levels are stored in instantiated mesh caches corresponding to the LOD levels. Based on the avatar parameters in the instantiated mesh caches, the character avatars at different LOD levels are instantiated and rendered. In this way, on the one hand, by storing the avatar parameters corresponding to different LOD levels in instantiated mesh caches corresponding to the LOD levels, the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars can be avoided, thus improving the rendering effect of large-scale crowd scene images. On the other hand, by dividing the character avatars into LOD levels based on the visibility from the current viewpoint and instantiating and rendering according to the LOD levels, smooth transitions of character avatar details can be achieved, avoiding flickering problems on the rendered screen caused by frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene images.

[0113] Furthermore, based on the above Figures 1 to 15 This specification also provides a storage medium for storing computer-executable instruction information in one or more embodiments. In one specific embodiment, the storage medium may be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, it can realize the following process: Determine the visibility of each character avatar in the crowd scene to be rendered from the current viewpoint; Based on the visibility of the character avatar at the current viewpoint, determine the LOD level of each character avatar in the crowd scene diagram; The avatar parameters corresponding to the character avatars at different LOD levels are stored in the instantiated grid cache corresponding to the LOD level, respectively. Based on the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

[0114] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described storage medium embodiment is basically similar to the method embodiment, so the description is relatively simple; relevant parts can be referred to the description of the method embodiment.

[0115] This specification provides a storage medium that can determine the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint. Based on the visibility of the character avatars from the current viewpoint, the Level of Detail (LOD) of each character avatar in the crowd scene image is determined. The avatar parameters corresponding to different LOD levels are stored in the instantiated mesh cache corresponding to the LOD level. Based on the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered. In this way, on the one hand, by storing the avatar parameters corresponding to different LOD levels in the instantiated mesh cache corresponding to the LOD level, the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars can be avoided, thus improving the rendering effect of large-scale crowd scene images. On the other hand, dividing the character avatars into LOD levels based on the visibility of the current viewpoint and instantiating and rendering according to the LOD level can achieve smooth transitions of character avatar details, avoiding flickering problems on the rendered screen caused by frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene images.

[0116] Furthermore, based on the above Figures 1 to 15 This specification also provides one or more embodiments of a computer program product, including a computer program, which, when executed by a processor, can perform the following processes: Determine the visibility of each character avatar in the crowd scene to be rendered from the current viewpoint; Based on the visibility of the character avatar at the current viewpoint, determine the LOD level of each character avatar in the crowd scene diagram; The avatar parameters corresponding to the character avatars at different LOD levels are stored in the instantiated grid cache corresponding to the LOD level, respectively. Based on the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

[0117] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described embodiment of a computer program product is relatively simple in description because it is fundamentally similar to the method embodiment; relevant parts can be referred to the description of the method embodiment.

[0118] This specification provides a computer program product that can determine the visibility of each character avatar in a crowd scene image to be rendered from the current viewpoint. Based on the visibility of the character avatars from the current viewpoint, it determines the Level of Detail (LOD) to which each character avatar belongs in the crowd scene image. The avatar parameters corresponding to different LOD levels are stored in instantiated mesh caches corresponding to the LOD levels. Based on the avatar parameters in the instantiated mesh caches, the character avatars at different LOD levels are instantiated and rendered. In this way, on the one hand, by storing the avatar parameters corresponding to different LOD levels in instantiated mesh caches corresponding to the LOD levels, the problem of large cache management time overhead caused by the large amount of data in the instantiated mesh cache due to the large number of character avatars can be avoided, thus improving the rendering effect of large-scale crowd scene images. On the other hand, by dividing the character avatars into LOD levels based on the visibility from the current viewpoint and instantiating and rendering according to the LOD levels, smooth transitions of character avatar details can be achieved, avoiding flickering problems on the rendered screen caused by frequent changes in viewpoint, thus improving the rendering effect of large-scale crowd scene images.

[0119] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0120] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0121] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0122] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0123] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

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

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

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

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

[0128] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0129] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0130] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0131] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitations, the presence of additional identical elements in the process, method, article, or apparatus that includes said elements is not excluded.

[0132] It should also be noted that the terms "one," "an," and "the" do not specifically refer to the singular; they can also include the plural. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0133] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving data sent by B, or it can be understood as A indirectly receiving data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending data directly to A, or it can be understood as B indirectly sending data to A through other entities such as C. Here, C can be a single subject, or two or more subjects.

[0134] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations within this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0135] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

[0136] It should be noted that the user data obtained in this manual is authorized by the user and does not involve user privacy.

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

[0138] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0139] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0140] The above description is merely an embodiment of this specification and is not intended to limit this document. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A data rendering method, comprising: Determine the visibility of each character avatar in the crowd scene to be rendered from the current viewpoint; Based on the visibility of the character avatar at the current viewpoint, determine the LOD level of each character avatar in the crowd scene diagram; The avatar parameters corresponding to the character avatars at different LOD levels are stored in the instantiated grid cache corresponding to the LOD level, respectively. Based on the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

2. The method according to claim 1, further comprising, before determining the visibility of each character avatar in the crowd scene graph to be rendered at the current viewpoint: Determine the projection depth of each initial character avatar in the crowd scene to be rendered at the current viewpoint; Determine the depth information of the occludeable objects corresponding to the current viewpoint in the crowd scene image to be rendered; Based on the projection depth of the initial character avatar, the position information of the initial character avatar in the crowd scene map, and the depth information of the occludeable object, the initial character avatar is filtered to determine the character avatar.

3. The method according to claim 2, wherein the step of filtering the initial character avatar based on the projection depth of the initial character avatar, the position information of the initial character avatar in the crowd scene map, and the depth information of the occludeable object to determine the character avatar includes: Based on the projection depth of the initial character avatar, the position information of the initial character avatar in the crowd scene map, and the depth information of the occluder, a first character avatar that is not occluded by the occluder is determined among the initial character avatars, and the character avatar is determined based on the first character avatar.

4. The method according to claim 3, wherein determining the character avatar based on the first character avatar includes: Based on the position information of the sphere surrounding the first character's avatar in the crowd scene map, determine the projection coordinates of the sphere surrounding the first character's avatar in the crowd scene map; Based on the projection coordinates of the avatar surrounding the first character avatar in the crowd scene diagram, determine whether the first character avatar is located within the visible cone; The first character avatar within the visible cone is identified as the character avatar.

5. The method according to claim 4, wherein determining whether the first character avatar is located within the visible cone based on the projection coordinates of the avatar enclosure sphere of the first character avatar in the crowd scene diagram includes: The distance from the center point to the screen is determined based on the projection coordinates of the center point of the sphere surrounding the first character's avatar in the crowd scene diagram. The radius of the projected light spot corresponding to the first character avatar is determined based on the distance from the center point to the screen and the radius of the avatar's surrounding sphere. Based on the projection coordinates of the avatar surrounding the first character in the crowd scene diagram, and the radius of the projection spot corresponding to the first character, determine whether the first character is located within the visible cone.

6. The method according to claim 5, wherein determining the visibility of each character avatar in the crowd scene to be rendered at the current viewpoint includes: The visibility of each character avatar at the current viewpoint is determined based on the distance from the center point of the avatar's encircling sphere to the screen, and the farthest distance rendered by the camera.

7. The method according to claim 4, wherein determining the visibility of each character avatar at the current viewpoint based on the distance from the center point of the avatar's bounding sphere to the screen and the farthest distance rendered by the camera includes: Determine the ratio between the distance from the center point of the avatar's bounding sphere corresponding to the current viewpoint to the screen, and the farthest distance rendered by the camera; The visibility of each character avatar at the current viewpoint is determined based on the difference between the square of the ratio and a set value.

8. The method according to claim 1, wherein instantiating and rendering the character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache includes: Based on the rendering precision corresponding to the LOD level, and using the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

9. A data rendering apparatus, comprising: The visibility determination module is used to determine the visibility of each character avatar in the crowd scene to be rendered from the current viewpoint; The level determination module is used to determine the LOD level of each character avatar in the crowd scene map based on the visibility of the character avatar at the current viewpoint. The parameter storage module is used to store the avatar parameters corresponding to the character avatars of different LOD levels in the instantiated grid cache corresponding to the LOD level, respectively. The data rendering module is used to instantiate and render character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache.

10. A data rendering device, the data rendering device comprising: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to: Determine the visibility of each character avatar in the crowd scene to be rendered from the current viewpoint; Based on the visibility of the character avatar at the current viewpoint, determine the LOD level of each character avatar in the crowd scene diagram; The avatar parameters corresponding to the character avatars at different LOD levels are stored in the instantiated grid cache corresponding to the LOD level, respectively. Based on the avatar parameters in the instantiated mesh cache, the character avatars at different LOD levels are instantiated and rendered.

11. A data rendering system, the data rendering system comprising a material layer subsystem, a geometry layer subsystem, a rendering layer subsystem, and an application layer subsystem, wherein: The material layer subsystem is configured to load the texture map and / or material parameters corresponding to the crowd scene image to be rendered, and to provide editing functions for each character avatar in the crowd scene image to be rendered. The geometry layer subsystem is configured to determine the visibility of each character avatar in the crowd scene graph to be rendered at the current viewpoint, and to determine the LOD level to which each character avatar in the crowd scene graph belongs based on the visibility of the character avatar at the current viewpoint, so as to store the avatar parameters corresponding to the character avatars at different LOD levels in the instantiated mesh cache corresponding to the LOD level respectively. The rendering layer subsystem is configured to instantiate and render character avatars at different LOD levels based on the avatar parameters in the instantiated mesh cache. The application layer subsystem is configured to control the changes in the avatar parameters corresponding to the character avatar based on changes in the viewpoint.

12. The data rendering system according to claim 11, wherein the material layer subsystem is configured to provide one or more functions for overall and partial editing of the body shape of each of the character avatars in the crowd scene diagram, as well as action type editing, speed editing and clothing editing, wherein the overall editing of the body shape includes height editing, and the partial editing of the body shape includes editing the thickness of body parts, wherein the body parts include one or more of the head, arms, stomach and legs.

13. The data rendering system according to claim 11, wherein the application layer subsystem is configured to control one or more of the following: position transformation, orientation transformation, and size scaling of the character avatar.

14. The data rendering system of claim 11, wherein the geometry layer subsystem is configured to control the geometric resolution of the human avatar within the view frustum and the loading of geometric data.

15. The data rendering system according to claim 14, wherein the geometry layer subsystem is configured to perform geometry loading of the human avatar using a progressive mesh loading method.

Images