Lightweight progressive cache management method and device for Web3D component set

Abstract

The invention discloses a lightweight progressive cache management method and device for a Web3D component set, and relates to the field of Web3D component rendering, and the method comprises the steps: carrying out the visual cone elimination based on the construction of a bounding ball, the visibility calculation, and the calculation of the direction of the component relative to a viewpoint for each component; calculating a visual cone removal coefficient, visibility and a component direction coefficient of each component, and further calculating a cache residence degree of each component and an LOD level to which each component belongs; and according to the cache residence degree of each component of each LOD level, updating the InstanceedMesh Cache cache of the previous instantiation rendering so as to carry out the next instantiation rendering. According to the lightweight progressive cache management method during instantiation rendering, the cache management efficiency is improved, and then the problem of lagging or flickering caused during instantiation rendering is reduced to a greater extent.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Web3D component rendering, and particularly to a lightweight progressive cache management method and device for a Web3D component set. BACKGROUND

[0002] In a Web3D application, especially in a large-scale new energy engineering scene, the number of complex component sets is very large, which causes problems such as lag or flicker, seriously affecting the user experience. Although the traditional progressive instantiation technology can solve the problems of lag or flicker to some extent, the rendering effect is still insufficient. SUMMARY

[0003] The purpose of the present application is to provide a lightweight progressive cache management method and device for a Web3D component set, and to propose a lightweight progressive cache management method during instantiation rendering, to improve the efficiency of cache management, and thus to reduce the problems of lag or flicker caused by instantiation rendering to a greater extent.

[0004] To achieve the above purpose, the present application provides the following solutions:

[0005] In a first aspect, the present application provides a lightweight progressive cache management method for a Web3D component set, comprising:

[0006] For each component, the view frustum culling based on the bounding sphere, the visibility calculation, and the direction calculation of the component relative to the viewpoint are performed to calculate the view frustum culling coefficient, the visibility, and the component direction coefficient of each component. The component direction coefficient is calculated according to the direction of the component relative to the viewpoint.

[0007] The cache residency and the LOD level to which each component belongs are calculated according to the view frustum culling coefficient, the visibility, and the component direction coefficient. The cache residency is used to describe the importance of the cache data corresponding to the component within the time period before the next cache update.

[0008] The InstancedMeshCache cache of the previous instantiation rendering is updated according to the cache residency of each component of each LOD level, to obtain an updated InstancedMesh Cache cache. The updated InstancedMesh Cache cache corresponding to each LOD level is used for the next instantiation rendering.

[0009] In a second aspect, the present application provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the lightweight progressive cache management method for a Web3D component set as described above.

[0010] In a third aspect, the present application provides a computer readable storage medium, having stored thereon a computer program which, when executed by a processor, implements the method for lightweight progressive cache management of Web3D component set as described above.

[0011] In a fourth aspect, the present application provides a computer program product comprising a computer program which, when executed by a processor, implements the method for lightweight progressive cache management of Web3D component set as described above.

[0012] According to the embodiments provided by the present application, the following technical effects are achieved:

[0013] The present application provides a method and device for lightweight progressive cache management of Web3D component set, which quantifies the importance of components through residency, reasonably allocates cache resources, significantly reduces the time cost of cache management, and improves the efficiency of cache management. Through cache management based on residency, the accuracy of visibility analysis is improved, and the problem of objects constantly flickering on the screen is avoided. Through dynamic updating of cache, the efficiency and accuracy of rendering are ensured, and the user experience is improved. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed in the embodiments. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0015] Figure 1 A flowchart of a method for lightweight progressive cache management of Web3D component set according to an embodiment of the present application is shown in the figure.

[0016] Figure 2 An IntancedMesh_Cache updating process based on residency according to an embodiment of the present application is shown in the figure.

[0017] Figure 3 A processing process of parameter cache of instantiated component set according to an embodiment of the present application is shown in the figure.

[0018] Figure 4 A structural diagram of a computer device according to an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0019] With reference to the drawings and embodiments of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0020] The above purposes, features and advantages of the present application will be more apparent and understandable. The present application will be further described in detail below with reference to the drawings and specific embodiments.

[0021] In Web3D applications, especially in large-scale new energy engineering scenarios, the number of complex component sets is very large, which causes problems such as lag or flicker, seriously affecting user experience. Although the traditional progressive instantiation technology can solve this problem to some extent, the effect still does not meet the demand. The inventors found that the defects in the prior art are caused by the inefficiency of cache management and visibility analysis. The following defects exist in cache management during rendering: (1) Large cache management overhead: Large-scale component sets result in a very large amount of cache data, and the time overhead of cache management is too high, which easily causes rendering lag. (2) Insufficient visibility analysis: The traditional visibility qualitative analysis method cannot effectively handle the case of frequent view angle changes, which causes the objects to flicker constantly on the screen, affecting user experience. That is, the traditional visibility analysis method cannot quantitatively evaluate the importance of the components, resulting in untimely cache flushing and affecting user experience. Therefore, in order to solve the problems of large cache management overhead and insufficient visibility analysis in the prior art, the present application provides a lightweight progressive cache management method for Web3D component sets, specifically a lightweight progressive cache management method for large-scale Web3D component sets based on residence degree, as shown in Figure 1 and Figure 2 The method comprises the following steps 101 to 103.

[0022] Step 101: For each component, the view frustum culling based on the construction of the bounding sphere, the visibility calculation, and the direction calculation of the component relative to the viewpoint are performed to calculate the view frustum culling coefficient, the visibility, and the component direction coefficient of each component. The component direction coefficient is calculated according to the direction of the component relative to the viewpoint.

[0023] Step 102: The cache residence degree of each component and the LOD level to which each component belongs are calculated according to the view frustum culling coefficient, the visibility, and the component direction coefficient. The cache residence degree is used to describe the importance of the cache data corresponding to the component in the time period before the next cache update.

[0024] Step 103, updating the InstancedMesh Cache cache according to the cache residence degree of each component of each LOD level, obtaining an updated InstancedMesh Cache cache; the updated InstancedMesh Cache cache corresponding to each LOD level is used for the next instance rendering.

[0025] Different levels of LOD correspond to different InstancedMesh objects, and different "InstancedMesh Cache" needs to be established respectively. When the viewpoint changes, the LOD also needs to be updated in real time, so the InstancedMeshCache also needs to be updated in real time.

[0026] Implementing the above steps 101 to 103 has the following effects:

[0027] (1) High cache management efficiency: by quantifying the importance of components through residence, the cache resources are reasonably allocated, significantly reducing the time overhead of cache management and improving the efficiency of cache management.

[0028] (2) Accurate visibility analysis: through cache management based on residence, the accuracy of visibility analysis is improved, avoiding the problem of objects constantly flickering on the screen.

[0029] (3) Good rendering performance: through dynamic updating of the cache, the efficiency and accuracy of rendering are ensured, and the user experience is improved.

[0030] In another exemplary embodiment of the present application, in step 101, the frustum culling based on the construction of the bounding sphere, the visibility calculation, and the direction calculation of the component relative to the viewpoint are performed for each component to calculate the frustum culling coefficient, the visibility, and the component direction coefficient of each component, specifically including:

[0031] (a1) Projecting the bounding sphere of each component to calculate the coordinates of the bounding sphere center projected onto the screen and the distance from the bounding sphere center to the screen.

[0032] (a2) Determine the projected spot radius of the component according to the coordinates of the bounding sphere center projected onto the screen, the distance from the bounding sphere center to the screen, and the radius of the bounding sphere, and perform frustum culling according to the size of the projected spot radius to obtain the frustum culling coefficient of each component.

[0033] Frustum Culling: The center of the bounding sphere is projected onto the screen by (al), then the radius of the projected spot is calculated according to the distance from the center to the screen and the radius of the bounding sphere. Knowing the projection position and the radius of the spot, it can be determined whether the spot can be seen on the screen or not. If the projection of the bounding sphere is completely off the screen, it means that the corresponding component is not in the view frustum. If component i is in the view frustum, the frustum culling coefficient a i is 1, if not, the frustum culling coefficient is 0.

[0034] (a3) The visibility of each component is calculated according to the size of the projected spot of each component.

[0035] Visibility of component: The visibility of a component depends on the size of the spot projected onto the screen, and the spot size is inversely proportional to the square of the distance d i from the center of the bounding sphere to the screen. The farthest distance rendered by the camera is denoted by D. When the distance is 0, the visibility vd i is 1, when the distance is greater than or equal to D, the visibility vd i is 0. The visibility of component i is defined as vd i = 1 - (d i / D) i 2 .

[0036] (a4) Determine the direction of each component relative to the viewpoint.

[0037] Direction of component relative to viewpoint: The direction of component i relative to the viewpoint can be calculated by the camera position parameter and the position parameter of component i .

[0038] (a5) Calculate the component direction coefficient of each component according to the direction of each component relative to the viewpoint and the direction of camera movement.

[0039] Component direction coefficient: The component direction coefficient is used to determine whether the position of the component is in the center of the field of view. If the line of sight is towards the component, the component direction coefficient is 1, if the line of sight is completely away from the component, the component direction coefficient is 0. The component direction coefficient can be calculated by the direction of camera movement and the direction of component i .

[0040] ​In another example embodiment of the present application, the projection calculation of the bounding sphere center comprises: obtaining the bounding sphere center coordinate, sequentially performing model transformation, view transformation and projection transformation on the three-dimensional vector of the center coordinate, and obtaining a new three-dimensional vector after the three transformations. The first dimension and the second dimension of the vector are the horizontal coordinate and the vertical coordinate of the coordinate projected on the screen, and the third dimension of the vector represents the distance from the bounding sphere center to the screen. Therefore, in step (a1), the projection calculation of the bounding sphere of each component is performed to obtain the coordinate of the bounding sphere center projected on the screen and the distance from the bounding sphere center to the screen, which specifically comprises:

[0041] (b1) obtaining the bounding sphere center coordinate of each component.

[0042] (b2) performing model transformation, view transformation and projection transformation on the bounding sphere center coordinate to obtain an updated three-dimensional coordinate; the first dimension and the second dimension of the updated three-dimensional coordinate represent the horizontal coordinate and the vertical coordinate of the bounding sphere center projected on the screen; and the third dimension of the updated three-dimensional coordinate represents the distance from the bounding sphere center to the screen.

[0043] In another example embodiment of the present application, in step 102, the cache residency of each component and the LOD level to which each target component belongs are calculated according to the view frustum culling coefficient, the visibility and the component direction coefficient, which specifically comprises:

[0044] (c1) calculating the cache residency of each component according to the view frustum culling coefficient, the visibility and the component direction coefficient; the expression of the cache residency is: rd i =α i +vd i *γ i ; rd i represents the cache residency of component i; α i represents the view frustum culling coefficient; vd i represents the visibility; and γ i represents the component direction coefficient.

[0045] The cache residency is used to describe the need degree of the cache data corresponding to each component from the current time to the next refresh time. The cache residency depends on three factors, i.e. the visibility vd i affected by the distance from the component to the viewpoint, the view frustum culling situation α i , and the orientation γ i of the component. The specific calculation method of the cache residency is rd i =α i +vd i *γ iThe cache residency will be the basis of the subsequent management of the cache of the components. Based on the residency, the importance of each component in the scene to the user is calculated.

[0046] (c2) Calculate the LOD level of each component according to the cache residency of each component.

[0047] Output LOD_Cache: LOD_Cache records the LOD level corresponding to different components, and each LOD level corresponds to a different rendering unit InstancedMesh. The LOD level of component i depends on the cache residency rd i of the component, and the number of levels is denoted as N. The level corresponding to component i is In this setting, in the area with a distance greater than D (D is the farthest visible distance), the LOD level number is 0, i.e. no rendering is performed, in the area with a distance slightly less than D, the level number is 1, and in the area with the closest distance, the level number is N.

[0048] In another exemplary embodiment of the present application, as shown in Figure 3 Step 103, the InstancedMesh Cache cache of the previous instance rendering is updated according to the cache residency of each component of each LOD level, to obtain an updated InstancedMesh Cache cache, which specifically includes:

[0049] (d1) Obtain the InstancedMesh Cache cache of the previous instance rendering.

[0050] Obtain the InstancedMesh Cache cache before updating: InstancedMesh Cache is a packaged result of all data required for rendering an instance object once. With the movement of the viewpoint and the change of the component object, the instance object corresponding to each component is dynamically changed, and therefore it is necessary to update the InstancedMesh Cache cache in real time.

[0051] (d2) Determine the visibility state of each component in the InstancedMesh Cache cache of the previous instance rendering according to the cache residency of each component calculated at present; the visibility state includes visible, potentially visible, and waiting for cleaning. Among them, visible describes whether a component is currently in the field of view. Potentially visible describes the probability of a component changing from outside the field of view to inside the field of view.

[0052] (d3) merging the visible components in the InstancedMesh Cache cache rendered by the previous instantiation rendering to obtain a merged InstancedMesh Cache cache; the merged partitions of the visible components are located in the frontmost region of the InstancedMesh Cache cache; the greater the cache residence degree of the visible components, the closer the region of the visible components to the front end of the InstancedMesh Cache cache.

[0053] Merging the partitions of the visible components: since subsequent compaction processing of the cache is required, and the compaction processing requires moving a large number of component parameters in the cache, this operation will consume a large amount of computing power, and the closer to the front end region, the smaller the probability of moving, so that the component data with a longer residence time is placed closer to the front end of the region, thereby reducing the computing power consumption of subsequent operations. The parameters of the visible components have a longer residence time in the cache than the parameters of the potentially visible components, and the parameters of the visible components are all stored in the frontmost end of the cache by exchanging the storage regions of the parameters multiple times.

[0054] (d4) clearing the components to be cleaned in the merged InstancedMesh Cache cache, and recording the region where the components to be cleaned are located as cache fragments.

[0055] For the components that participated in the last instantiation rendering but do not need to participate in the subsequent instantiation rendering, the data corresponding to these components needs to be removed from the cache, and these regions are scattered in the cache and are called cache fragments.

[0056] (d5) adding the cache data of the new components to the current InstancedMesh Cache cache according to the cache fragments; the new components refer to the components that do not participate in the last rendering but need to participate in the next rendering.

[0057] In another exemplary embodiment of the present application, as shown in Figure 3 In step (d5), the cache data of the new components is added to the current InstancedMesh Cache cache according to the cache fragments, and specifically includes:

[0058] (1) if the number of new components is greater than the number of cache fragments, then a plurality of new components with the largest cache residence degree are added one by one into the cache fragments, and the remaining new components are added to the idle region at the back end of the current InstancedMesh Cache cache to obtain an updated InstancedMesh Cache cache; the greater the cache residence degree of the new components, the closer the position of the cache fragment to which the new components are added to the front end of the InstancedMesh Cache cache.

[0059] If the number of new components exceeds the amount of data in the cache fragments, the remaining component data will be stored in the free area. When the number of cache fragments is insufficient to accommodate all the data of new components, the remaining component data needs to be stored in the free area at the end of the InstancedMesh Cache.

[0060] (2) If the number of new components is less than the number of cache fragments, the new components are added to the cache fragments according to the cache residency size, and the cache data after the currently free cache fragments are added to the currently free cache fragments so that the free cache fragments are at the back end of the InstancedMesh Cache, resulting in the updated InstancedMesh Cache.

[0061] Add the cached data adjacent to the currently free cache fragment to the currently free cache fragment. The cached data adjacent to the currently free cache fragment is the currently free cache fragment. Return to the step "Add the cached data adjacent to the currently free cache fragment" until the free cache fragment is at the very end of the InstancedMesh Cache.

[0062] If the number of new components is less than the amount of data in the cache free fragments, the remaining cache fragments are cleared by cache compaction: when there are still cache free fragments after the data of the new components are added, the cache needs to be compacted, that is, the component data at the end of the cache is put into the cache fragment, and the end position becomes a new cache free fragment. Repeat the above operation to move all cache free fragments to the last area of ​​the cache, and then merge these areas to get a complete free area.

[0063] The final updated InstancedMesh Cache stores all artifact parameter data at the very front of the cache, with the free area at the back. The effective length of the cache area used by the front end is calculated, and then the InstancedMesh Cache and the effective length are used as input for subsequent rendering operations. Additionally, if a newly added artifact is a visible artifact (not potentially visible), but its corresponding cache fragment is not located near the front end of the cache, it needs to be moved to the front end. This is because if a new visible artifact has a higher visibility weight, the cache position needs to be adjusted.

[0064] In this embodiment, frustum culling based on the component-bounding sphere enables rapid determination of whether a component is within the view frustum, reducing unnecessary computation. Cache management based on dwell time allows for the rational allocation of cache resources by quantifying component importance. Real-time updates to cache content ensure rendering efficiency and accuracy. This application effectively addresses the efficiency problem of rendering large-scale components in new energy engineering projects through frustum culling and dynamic allocation and updating of cache resources; utilizing component importance quantification for cache management significantly reduces the consumption of irrelevant resources and ensures rendering quality.

[0065] This application also provides an application scenario in which the aforementioned lightweight progressive cache management method for Web3D component sets is applied. Specifically, the lightweight progressive cache management method for Web3D component sets provided in this embodiment can be applied to large-scale new energy engineering rendering scenarios. This scenario includes a cache management stage (for managing the cache of component data for the next instantiation rendering) and a rendering stage (for instantiation rendering based on the cache-managed data); the lightweight progressive cache management method for Web3D component sets provided in this embodiment belongs to the cache management stage.

[0066] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 4 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores lightweight progressive cache management data for Web3D component sets. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a lightweight progressive cache management method for Web3D component sets.

[0067] Those skilled in the art will understand that Figure 4The structures shown are merely block diagrams of some structures related to the present application and do not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements. In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0068] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0069] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0070] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0071] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0072] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0073] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0074] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A lightweight progressive caching management method for Web3D component sets, characterized in that, The lightweight progressive caching management method for the Web3D component set includes: For each component, frustum culling based on the constructed bounding sphere, visibility calculation, and component orientation calculation relative to the viewpoint are performed to calculate the frustum culling coefficient, visibility, and component orientation coefficient for each component; the component orientation coefficient is calculated based on the component's orientation relative to the viewpoint. The cache residency of each component and the LOD level of each component are calculated based on the visual cone culling coefficient, the visibility, and the component orientation coefficient; the cache residency is used to describe the importance of the cached data corresponding to the component in the time period before the next cache update; The InstancedMesh Cache of the previous instantiation rendering is updated based on the cache residency of each component at each LOD level, resulting in the updated InstancedMesh Cache. The updated InstancedMesh Cache corresponding to each LOD level is used for the next instantiation rendering.

2. The lightweight progressive caching management method for Web3D component sets according to claim 1, characterized in that, For each component, frustum culling based on the constructed bounding sphere, visibility calculation, and component orientation calculation relative to the viewpoint are performed to calculate the frustum culling coefficient, visibility, and component orientation coefficient for each component. Specifically, this includes: Projection calculations are performed on the bounding sphere of each component to obtain the coordinates of the center of the bounding sphere projected onto the screen and the distance from the center of the bounding sphere to the screen; The radius of the projected light spot of the component is determined by the coordinates of the center of the bounding sphere projected onto the screen, the distance from the center of the bounding sphere to the screen, and the radius of the bounding sphere. Based on the size of the projected light spot radius, the visual cone is culled to obtain the visual cone culling coefficient for each component. The visibility of each component is calculated based on the size of the projected light spot of each component; Determine the orientation of each component relative to the viewpoint, and calculate the component orientation coefficient of each component based on the orientation of each component relative to the viewpoint and the camera movement direction.

3. The lightweight progressive caching management method for Web3D component sets according to claim 2, characterized in that, For each component, a projection calculation is performed on the bounding sphere to obtain the coordinates of the center of the bounding sphere projected onto the screen and the distance from the center of the bounding sphere to the screen. Specifically, this includes: For each component, obtain the coordinates of the center of the bounding sphere of the component; The coordinates of the center of the bounding sphere are transformed by model transformation, view transformation, and projection transformation to obtain updated three-dimensional coordinates. The first and second dimensions of the updated three-dimensional coordinates represent the x and y coordinates of the center of the bounding sphere after it is projected onto the screen. The third dimension of the updated three-dimensional coordinates represents the distance from the center of the bounding sphere to the screen.

4. The lightweight progressive caching management method for Web3D component sets according to claim 2, characterized in that, Determine the orientation of each component relative to the viewpoint, and calculate the component orientation coefficient for each component based on its orientation relative to the viewpoint and the camera movement direction. Specifically, this includes: The orientation of a component relative to the viewpoint is determined based on the camera position parameters and the position parameters of each component. The component orientation coefficient is calculated for each component based on its direction relative to the viewpoint and the camera's movement direction; the expression for the component orientation coefficient is: Where, γ i The component orientation coefficient of component i; Indicates the direction of camera movement; This indicates the direction of component i relative to the viewpoint.

5. The lightweight progressive caching management method for Web3D component sets according to claim 1, characterized in that, The cache dwell time of each component and the LOD level of each target component are calculated based on the frustum elimination coefficient, the visibility, and the component orientation coefficient, specifically including: The buffer dwell time of each component is calculated based on the visual cone elimination coefficient, the visibility, and the component orientation coefficient; the expression for the buffer dwell time is: rd i =α i +vd i *γ i ;rd i Indicates the cache residency of component i; α i Indicates the cone rejection coefficient; vd i Indicates visibility; γ i Indicates the component orientation coefficient; The LOD level of each component is calculated based on its cache residency.

6. The lightweight progressive caching management method for Web3D component sets according to claim 1, characterized in that, The InstancedMesh Cache from the previous instantiation rendering is updated based on the cache residency of each component at each LOD level, resulting in the updated InstancedMesh Cache, which specifically includes: Retrieve the InstancedMesh Cache from the previous instantiation rendering; The visibility status of each component in the InstancedMesh Cache of the previous instantiation rendering is determined based on the currently calculated cache residency of each component; the visibility status includes visible, potentially visible, and awaiting cleanup; The visible components in the previously instantiated and rendered InstancedMesh Cache are partitioned and merged to obtain the merged InstancedMesh Cache. The merged partition of the visible components is located at the front of the InstancedMesh Cache. The greater the cache residency of the visible components, the closer the area where the visible components are located is to the front of the InstancedMesh Cache. Clear the components waiting to be cleaned up in the merged InstancedMesh Cache cache, and record the area where the components waiting to be cleaned up are located as cache fragments; Based on cache fragments, the cache data of newly added components is added to the current InstancedMesh Cache; newly added components refer to components that did not participate in the previous rendering but need to participate in the next rendering.

7. The lightweight progressive caching management method for Web3D component sets according to claim 6, characterized in that, Based on cache fragments, the cache data of newly added components is added to the current InstancedMesh Cache, specifically including: If the number of new components is greater than the number of cache fragments, the new components with the highest cache residency will be added to the cache fragments one by one, and the remaining new components will be added to the free area of ​​the current InstancedMesh Cache backend to obtain the updated InstancedMesh Cache. The higher the cache residency of the new components, the closer the cache fragment where the new components are added is to the frontend of the InstancedMesh Cache. If the number of new components is less than the number of cache fragments, then according to the cache residency level, the new components are added to the cache fragments, and the cached data after the currently free cache fragments are added to the currently free cache fragments so that the free cache fragments are at the very back of the InstancedMesh Cache, resulting in the updated InstancedMeshCache.

8. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement a lightweight progressive cache management method for a Web3D component set according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the lightweight progressive caching management method for Web3D component sets as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the lightweight progressive caching management method for Web3D component sets as described in any one of claims 1-7.

Images