Three-dimensional data loading optimization method and system

Abstract

The invention relates to the technical field of three-dimensional data processing, and discloses a three-dimensional data loading optimization method and system. Comprising the following steps of S1, request interception mechanism establishment, S2, cache key value extraction and mapping, S3, cache state maintenance and dependency relationship construction, S4, cache hit judgment and local return, S5, multimedia resource independent caching, S6, cache life cycle management and S7, Cesium engine integration. The three-dimensional data caching system provided by the invention provides a feasible solution for efficient loading of large-scale three-dimensional geographic space data, has good expansibility and application prospects, and can be further expanded to support more three-dimensional engines and data formats along with continuous development of technologies such as digital twinning, smart cities, VR / AR and the like; and in combination with edge calculation, intelligent preloading and cross-platform application, the data loading efficiency and user experience under multiple scenes are improved, and a solid foundation is provided for constructing a high-performance and low-delay three-dimensional visualization system.

Description

Technical Field

[0001] This invention relates to the field of three-dimensional data processing technology, specifically to a method and system for loading and optimizing three-dimensional data. Background Technology

[0002] 3D geospatial data loading technology refers to the core technology for loading and rendering large-scale 3D models (such as 3D Tiles), texture maps, and multimedia resources on the Web through 3D visualization engines (such as Cesium) to build digital twins, smart cities, and other scenarios. Its performance directly affects the smoothness of 3D scenes and the user interaction experience.

[0003] In existing technologies, engines such as Cesium mainly obtain 3D data from the server through HTTP requests. The loading process relies on the browser's default caching mechanism. For resources that are accessed repeatedly, if the cache validity period has not expired, they can be read from the browser cache. At the same time, some applications reduce data transmission distance by using server-side caching or CDN acceleration to alleviate loading pressure. This is widely used in fields such as digital twin cities and engineering simulation.

[0004] However, existing technologies lack intelligent front-end caching mechanisms tailored to the characteristics of 3D data. Browser default caching is ill-suited to the hierarchical structure and large capacity of 3D tiles, resulting in frequent network requests when repeatedly loading the same resources. In scenarios with massive amounts of data, this can easily lead to problems such as high loading latency and excessive server load. Therefore, we propose a method and system for optimizing the loading of 3D data. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a method and system for optimizing the loading of 3D data, which solves the problems of the lack of a front-end intelligent caching mechanism for the characteristics of 3D data and the difficulty of adapting the browser's default cache to the hierarchical structure and large capacity of 3D tiles.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method and system for loading and optimizing three-dimensional data, comprising the following steps:

[0007] S1 request interception mechanism establishment: During the front-end page initialization phase, a third-party library is introduced to create a global request interceptor, which listens for 3D model resource requests initiated by the Cesium engine, filters requests for specified paths, and then enters the S2 cache key-value extraction and mapping step.

[0008] S2 cache key-value extraction mapping: Extract key identifiers as cache keys based on the request URLs intercepted and filtered by S1, extract the last-level filename in the URL path to ensure fine-grained and unique caching, support caching of 3D tile data at different levels separately, and then proceed to the S3 cache state maintenance and dependency relationship building steps.

[0009] S3 Cache State Maintenance and Dependency Building: The Map data structure is used to maintain the state of the current cache block corresponding to the cache key value extracted from S2. When parsing the response data, the child node dependencies are extracted and marked as objects to be cached, forming a three-dimensional data cache dependency tree. Then, the S4 cache hit judgment and local return steps are entered.

[0010] S4 cache hit detection and local return: Based on the cache key-value extracted by S2, check whether the corresponding cache data exists in the local database before the request. If it exists, construct the response body and terminate the real network request; if it does not exist, initiate a network request and write the result to the local cache. For non-JSON type resources, proceed to the S5 multimedia resource independent caching step.

[0011] S5 Multimedia Resource Independent Caching: For video streams, images, and other resources that are determined by S4 to be non-JSON type, the raw byte stream is obtained using FetchAPI and converted into a Blob object before caching. A local access link is generated using the URL.createObjectURL() method for Cesium to use. At the same time, this cache is controlled by the S6 cache lifecycle management steps.

[0012] S6 Cache Lifecycle Management: Provides interfaces for enabling, disabling, and clearing cached data stored after processing by S4 and S5, allowing developers to dynamically control cache behavior according to business needs. Combined with a timestamp mechanism, it implements cache expiration control. Its management objects cover all cached data corresponding to cache key-value pairs extracted by S2.

[0013] S7 Cesium Engine Integration: Provides a unified adaptation interface function for Cesium to call when loading 3D models processed by S1-S6 or playing video streams, enabling caching functionality without modifying the original Cesium code. This interface function is based on the caching results of S4 and S5.

[0014] Preferably, in the S1 request interception mechanism establishment step, the third-party library is ajax-hook, and the 3D model resource requests include requests of type .json, .b3dm, .pnts, and .glb.

[0015] Preferably, in the S2 cache key-value extraction and mapping step, the key identifier is the last-level filename in the URL path, which is obtained by a string truncation utility function that extracts the content after the last ' / ' of the string.

[0016] Preferably, in the S3 cache state maintenance and dependency relationship construction step, the state of the cache block includes whether it has been cached and whether it is an incremental cache. The response data includes tileset.json. The S3 cache state maintenance and dependency relationship construction step also includes a sub-resource dependency management process. When parsing the JSON format response data, this process automatically extracts the address of the sub-model, obtains the key value corresponding to the sub-model based on the S2 key-value extraction rules, adds it to the cache index mapping table, and marks it as a state to be cached.

[0017] Preferably, in the S4 cache hit determination and local return step, the local database is IndexedDB. During the query, the cache key value extracted in S2 is used for searching, and during the write, it is stored in the form of key-value pairs. The S4 cache hit determination and local return step also includes a cache query process. This process encapsulates a unified cache query interface, supports synchronous and asynchronous calls, and queries whether the corresponding cache data exists in the local database based on the cache key value extracted in S2.

[0018] Preferably, in the S5 multimedia resource independent caching step, after FetchAPI obtains the raw byte stream, it converts the byte stream into a Blob object by reading the response body. The type of the Blob object is determined according to the content-type in the response header.

[0019] Preferably, in the S6 cache lifecycle management step, the cache enable, disable, and clear interfaces are implemented through methods in the cache class, and the timestamp mechanism controls cache expiration by recording the storage time of cached data in S4 and S5 and comparing it with the preset expiration time.

[0020] Preferably, in the S7Cesium engine integration step, the adaptation interface functions include useCache and cacheVideo. useCache is called when loading the 3D model processed by S4, and cacheVideo is called when playing the video stream processed by S5.

[0021] A three-dimensional data loading optimization system includes the following modules:

[0022] Request interception module: Listens to all HTTP requests from the browser, filters out 3D data requests that meet preset rules, and passes the filtered request information to the cache query module;

[0023] Cache query module: Receives request information from the request interception module, extracts cache key-value pairs based on the request URL, queries the local database to see if the corresponding cache data exists, feeds back the query results to the request interception module, and triggers the data writing module if no cache data is found.

[0024] Local caching module: Receives data from the data writing module and stores resources such as 3D model data, textures, and video streams in the browser's local database in key-value format. The stored key-value pairs correspond to the cache key-value pairs extracted by the cache query module.

[0025] Data writing module: When the cache query module does not find the corresponding cached data, it receives the data returned by the network request, processes the data and passes it to the local cache module. JSON data is directly serialized, and binary resources such as video streams are converted into Blobs.

[0026] Cache management module: performs lifecycle management, status updates and cleanup of cached data stored in the local cache module. The cached data it manages covers all cached data corresponding to key-value pairs extracted by the cache query module.

[0027] The adapter interface module receives cached data stored in the local cache module and provides a unified cache call interface for integration with the Cesium engine. The cached data called by this interface comes from the cached data confirmed by the cache query module.

[0028] Preferably, the request interception module defines the interception scope by configuring a filter path string, and only processes requests containing the string; after extracting the cache key value, the cache query module uses a Map data structure to record the mapping relationship between the key value and the cache status, including uncached and pending cache.

[0029] This invention provides a method and system for optimizing the loading of three-dimensional data. It has the following beneficial effects:

[0030] 1. The three-dimensional data caching system proposed in this invention provides a practical solution for the efficient loading of large-scale three-dimensional geospatial data. It has good scalability and application prospects. With the continuous development of technologies such as digital twins, smart cities and VR / AR, this solution can be further expanded to support more three-dimensional engines and data formats. Combined with edge computing, intelligent preloading and cross-platform applications, it can improve data loading efficiency and user experience in multiple scenarios, and provide a solid foundation for building a high-performance, low-latency three-dimensional visualization system.

[0031] 2. This invention avoids repeated requests for the same resources through a local caching mechanism, which is particularly effective when users repeatedly browse the same area or model. In addition, cached data can be quickly read directly from the local database, which greatly shortens the loading time of 3D models, improves the user experience, and reduces a large number of invalid requests from the client, reducing the concurrent pressure on the server and helping to improve the stability and availability of the overall system.

[0032] 3. This invention achieves efficient extraction of sub-resource addresses by using path encoding and a multinomial hash function to generate unique hash values ​​in step S3; and by establishing a relationship between the hash index and cached key values ​​in step S4, optimizing the query into a two-step operation of "hash location + key-value matching," significantly reducing query time complexity. Simultaneously, a hash collision handling mechanism ensures accuracy, significantly improving the cache query efficiency of massive amounts of 3D data. Especially in large-scale caching scenarios, it effectively reduces network requests and server load, enhancing 3D scene loading performance and user experience. Attached Figure Description

[0033] Figure 1 This is a flowchart of the method for optimizing the loading of this 3D data;

[0034] Figure 2 Here is a flowchart of the system for optimizing the loading of this 3D data;

[0035] Figure 3 This is a flowchart of the request interception process of the present invention. Detailed Implementation

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

[0037] Example:

[0038] Please see the appendix Figure 1 - Appendix Figure 3 This invention provides a method and system for optimizing the loading of three-dimensional data, comprising the following steps:

[0039] S1 request interception mechanism establishment: During the front-end page initialization phase, a third-party library is introduced to create a global request interceptor, which listens for 3D model resource requests initiated by the Cesium engine, filters requests for specified paths, and then enters the S2 cache key-value extraction and mapping step.

[0040] In the S1 request interception mechanism establishment step, the third-party library is ajax-hook, and the 3D model resource requests include requests of type .json, .b3dm, .pnts, and .glb.

[0041] S2 cache key-value extraction mapping: Extract key identifiers as cache keys based on the request URLs intercepted and filtered by S1, extract the last-level filename in the URL path to ensure fine-grained and unique caching, support caching of 3D tile data at different levels separately, and then proceed to the S3 cache state maintenance and dependency relationship building steps.

[0042] In the S2 cache key-value extraction mapping step, the key identifier is the last-level filename in the URL path, which is obtained by a string truncation utility function that extracts the content after the last ' / ' of the string.

[0043] S3 Cache State Maintenance and Dependency Building: The Map data structure is used to maintain the state of the current cache block corresponding to the cache key value extracted from S2. When parsing the response data, the child node dependencies are extracted and marked as objects to be cached, forming a three-dimensional data cache dependency tree. Then, the S4 cache hit judgment and local return steps are entered.

[0044] In the S3 cache state maintenance and dependency construction step, the cache block status includes whether it is cached and whether it is incremental cache. The response data includes tileset.json. The S3 cache state maintenance and dependency construction step also includes a sub-resource dependency management process. When parsing the JSON format response data, this process automatically extracts the address of the sub-model, obtains the key-value corresponding to the sub-model based on the S2 key-value extraction rules, adds it to the cache index mapping table, and marks it as a state to be cached. In the JSON streaming parsing of sub-resource dependency management, an algorithm based on hash matching and status encoding is introduced, combined with numerical and alphabetic identifiers to achieve efficient parsing. The sub-resource dependency management process includes the following algorithms:

[0045] Step 1: Path Encoding

[0046] Assign a unique letter identifier (AZ) to each node in the target path (such as root, children, content, uri). For example, if root=A, children=B, content=C, uri=D, then the target path is encoded as A>B>C>D.

[0047] Step 2: Hash Calculation

[0048] The encoding is converted into a numeric hash value using a polynomial hash function:

[0049] in:

[0050] The ASCII values ​​corresponding to the letter identifiers (e.g., A=65, B=66);

[0051] The base number (take prime numbers, such as 31);

[0052] This represents the number of nodes in the path.

[0053] The size of the hash table (take a prime number, such as 1000003).

[0054] Step 3: Real-time matching

[0055] When parsing JSON, the hash value of the current path is calculated in real time and compared with the hash H of the target path:

[0056] If they are equal, extract the current field value (sub-model address).

[0057] If they are not equal, skip parsing that branch;

[0058] S4 cache hit detection and local return: Based on the cache key-value extracted by S2, check whether the corresponding cache data exists in the local database before the request. If it exists, construct the response body and terminate the real network request; if it does not exist, initiate a network request and write the result to the local cache. For non-JSON type resources, proceed to the S5 multimedia resource independent caching step.

[0059] In the S4 cache hit determination and local return step, the local database is IndexedDB. During querying, the cache key-value pair is retrieved from S2. During writing, it is stored in key-value pair format. The S4 cache hit determination and local return step also includes a cache query process. This process encapsulates a unified cache query interface, supporting synchronous and asynchronous calls. It queries the local database to see if corresponding cached data exists based on the cache key-value pair extracted from S2, including the following algorithms:

[0060] 1. First, initialize the hash index. Create two object storage spaces in IndexedDB: mainstore and hashIndex5tore. The mainstore uses the cache key value generated by S2 as the primary key to store the data to be cached (Data) and the path hash value (H) generated by S3. Its data structure is {Key: string, Data: any, H: number}. The hashIndexstore uses the hash value H as the index key to store the list of all keys corresponding to the hash value. Its data structure is {H: number, Keys: string[]}. This step lays the foundation for data storage for subsequent hash index queries.

[0061] 2. When S3 generates the path hash value H and triggers the write operation of S4, data writing is performed, inserting data (Key, Data, H) into the mainstore, where H is calculated using the formula:

[0062]

[0063] In the formula This represents the ASCII value of the path node, for example, when the path node is "tile". , , , ;

[0064] We take the prime number 31 as the base.

[0065] This represents the total number of path nodes;

[0066] The prime number 1000003 was chosen as the hash table size to reduce the collision rate.

[0067] At the same time, check if the corresponding entry exists in hashIndexstore. If it exists, append the key to the Keys list. If it does not exist, create a new entry (H, [Key]). This establishes the association between the hash value and the cache key value.

[0068] 3. In the S4 query phase, for the cache key TargetKey to be queried, first reverse the path based on TargetKey, and then calculate the target hash value TargetH using the same hash formula as above:

[0069]

[0070] in:

[0071] The ASCII values ​​of the reverse path nodes are used to deduce the values; other parameters are the same as in step 2.

[0072] Next, query the list of keys for the TargetH pair in hashIndex5tore. This step, leveraging the indexing features of IndexedDB, has a time complexity of O(1), i.e. , This indicates the query time; then iterates through the Keys list, performing an exact string match between each Key and the TargetKey, with a maximum number of matches equal to the number of hash collisions. (generally If a match is found, the corresponding data is read from the mainstore; otherwise, it is determined that the data is not cached, and the total query time is [time missing]. , For single string comparison time, compared to string query time ( (Total cache count), efficiency is significantly improved, and the improvement rate can be expressed by the formula improvement rate. Calculate, when , At that time, the improvement rate was approximately 99.995%;

[0073] S5 Multimedia Resource Independent Caching: For video streams, images, and other resources that are determined by S4 to be non-JSN type, the raw byte stream is obtained using FetchAPI and converted into a LOB object before caching. A local access link is generated using the URL.createObjectURL() method for Cesium to use. At the same time, this cache is controlled by the S6 cache lifecycle management steps.

[0074] In the S5 multimedia resource independent caching step, after FetchAPI obtains the raw byte stream, it converts the byte stream into a Blob object by reading the response body. The type of the Blob object is determined according to the content-type in the response header.

[0075] S6 Cache Lifecycle Management: Provides interfaces for enabling, disabling, and clearing cached data stored after processing by S4 and S5, allowing developers to dynamically control cache behavior according to business needs. Combined with a timestamp mechanism, it implements cache expiration control. Its management objects cover all cached data corresponding to cache key-value pairs extracted by S2.

[0076] In the S6 cache lifecycle management step, the cache enable, disable, and clear interfaces are implemented through methods in the cache class, and the timestamp mechanism controls cache expiration by recording the storage time of cached data in S4 and S5 and comparing it with the preset expiration time.

[0077] S7Cesium Engine Integration: Provides a unified adaptation interface function for Cesium to call when loading 3D models processed by S1-S6 or playing video streams, enabling caching functionality without modifying the original Cesium code. This interface function is called based on the caching results of S4 and S5.

[0078] In the S7Cesium engine integration step, the adaptation interface functions include useCache and cacheVideo. useCache is called when loading the 3D model processed by S4, and cacheVideo is called when playing the video stream processed by S5.

[0079] A three-dimensional data loading optimization system includes the following modules:

[0080] Request interception module: Listens to all HTTP requests from the browser, filters out 3D data requests that meet preset rules, and passes the filtered request information to the cache query module;

[0081] The request interception module defines the interception scope by configuring a filter path string, and only processes requests containing that string; after extracting the cache key value, the cache query module uses a Map data structure to record the mapping relationship between the key value and the cache status, which includes not cached and waiting to be cached.

[0082] This code implements a caching class called ThreeDtileCache, used to intercept, cache, and persistently store 3D model resources on the browser side. Its core functionalities include:

[0083] Request interception: Intercept all HTTP requests that match the rules using ajax-hook;

[0084] Cache query: Check if the corresponding cache already exists in IndexedDB;

[0085] Cache write: Write the data retrieved for the first time to the local database;

[0086] Sub-resource dependency management: Automatically parses and caches sub-model addresses in JSON files;

[0087] Video stream caching: Supports caching of Blobs for multimedia resources such as video;

[0088] Cache lifecycle control: Provides interfaces for enabling, disabling, and clearing cache;

[0089] Its code is as follows:

[0090] import { proxy} from 'ajax-hook'

[0091] / / Use the `proxy` method provided by the third-party library `ajax-hook` to intercept global AJAX requests.

[0092] / / This allows you to insert custom logic before the request is sent and after the response is returned.

[0093] / / === Define the cache class ThreeDtileCache ===

[0094] class ThreeDtileCache {

[0095] / / === Class member variable initialization ===

[0096] / / Table name, used to store cached data in IndexedDB

[0097] _tableName = 'geomDb'

[0098] / / 3D model request path filter; only requests matching this path will be cached.

[0099] _filterStr = ' / uploadfile / '

[0100] / / Array of JSON URLs to be cached

[0101] _JsonUrls = ''

[0102] / / Store the video addresses that need to be cached

[0103] _VideoUrl = ''

[0104] / / Record the total number of blocks (cache index mapping)

[0105] _cacheIndexMap = new Map()

[0106] / / Close the cache handling handle

[0107] unProxy = null

[0108] / / === Constructor initialization configuration items ===

[0109] constructor(option) {

[0110] / / Custom URL filter string

[0111] if (option.filter) this._filterStr = option.filter

[0112] / / Set the list of main model file addresses that need to be cached

[0113] if (!Array.isArray(option.url)) this._JsonUrls = [option.url]

[0114] else this._JsonUrls = option.url

[0115] / / Set video resource address

[0116] this._VideoUrl = option.VideoUrl

[0117] / / Initialize cache index mapping table

[0118] this._cacheIndexMap = new Map()

[0119] / / Initialize the cancel interceptor to null

[0120] this.unProxy = null

[0121] }

[0122] / / === Check if there is a cache ===

[0123] async isCached(key) {

[0124] / / Check if the corresponding cached data exists in IndexedDB.

[0125] const data = await $g.myIndexDb.query({ name: this._tableName, key:key})

[0126] return data && data.value ? true : false

[0127] }

[0128] / / === String slicing utility functions ===

[0129] getTextAfterLastBackslash(wasStr, Str) {

[0130] / / Extract the content after the last ' / ' of the string, which will be used to extract the filename as a cache key-value pair.

[0131] let lastIndex = wasStr.lastIndexOf(Str)

[0132] if (lastIndex !== -1)

[0133] return wasStr.slice(lastIndex + 1)

[0134] else

[0135] return wasStr

[0136] }

[0137] / / === Disable caching ===

[0138] closeHandle() {

[0139] / / Clear cached index mappings

[0140] this._cacheIndexMap = []

[0141] / / If a cancellation interceptor exists, then call the cancellation function.

[0142] if (this.unProxy) this.unProxy()

[0143] }

[0144] / / === Write cached data ===

[0145] dataStorage(key, data) {

[0146] / / Write data to the IndexedDB database as key-value pairs.

[0147] $g.myIndexDb.add({ name: this._tableName, att: { key: key, value:data}})

[0148] }

[0149] / / === Use cached data ===

[0150] async useCacheData(key) {

[0151] / / Read cached data from the database based on the key value

[0152] const data = await $g.myIndexDb.query({ name: this._tableName, key:key})

[0153] return data

[0154] }

[0155] / / === Request interception and handling ===

[0156] intercept() {

[0157] const { unProxy} = proxy({

[0158] / / Enter before request is initiated

[0159] onRequest: async(config, handler) => {

[0160] / / Check if the current request matches the cache path

[0161] if (config.url.toString().includes(this._filterStr)) {

[0162] const url = config.url.toString()

[0163] const key = this.getTextAfterLastBackslash(url, ' / ')

[0164] const datas = await this.useCacheData(key)

[0165] / / Should cached data be used?

[0166] if (datas && datas.value) {

[0167] / / Construct a virtual response and return cached data

[0168] handler.resolve({

[0169] config

[0170] status: 200,

[0171] response: datas.value

[0172] })

[0173] return

[0174] }

[0175] else {

[0176] if (key !== '' && this._cacheIndexMap.has(key))

[0177] this._cacheIndexMap.set(key, false)

[0178] }

[0179] }

[0180] handler.next(config)

[0181] },

[0182] / / Enter when an error occurs during the request

[0183] onError: (err, handler) => {

[0184] console.log(err.type)

[0185] handler.next(err)

[0186] },

[0187] / / Enter after successful request

[0188] onResponse: (response, handler) => {

[0189] if (response.config.url.toString().includes(this._filterStr)) {

[0190] const url = response.config.url

[0191] let key = this.getTextAfterLastBackslash(url, ' / ')

[0192] if (key !== '') {

[0193] if (this._JsonUrls.some(item => url === item)) {

[0194] if (!this._cacheIndexMap.has(key))

[0195] this._cacheIndexMap.set(key, false)

[0196] const children = JSON.parse(response.response).root.children

[0197] children.forEach(element => {

[0198] const childrenKeys = this.getTextAfterLastBackslash(element.content.uri, ' / ')

[0199] if (childrenKeys)

[0200] this._cacheIndexMap.set(childrenKeys, true)

[0201] })

[0202] }

[0203] if (this._cacheIndexMap.has(key) && !this._cacheIndexMap.get(key))

[0204] this.dataStorage(key, response.response)

[0205] }

[0206] }

[0207] handler.next(response)

[0208] }

[0209] })

[0210] this.unProxy = unProxy

[0211] }

[0212] / / === Video stream caching usage ===

[0213] async acheFetch() {

[0214] let resultUrl = this._VideoUrl

[0215] const datas = await this.useCacheData(this._VideoUrl)

[0216] if (datas && datas.value)

[0217] resultUrl = URL.createObjectURL(datas.value)

[0218] else

[0219] this.getDataByFetch(this._VideoUrl)

[0220] return resultUrl

[0221] }

[0222] / / === Get and cache video stream data ===

[0223] getDataByFetch(url) {

[0224] fetch(url).then(response => {

[0225] if (!response.body || !response.ok)

[0226] throw new Error('Unable to read response body or response status is incorrect')

[0227] let chunks = []

[0228] return new Promise((resolve, reject) => {

[0229] const reader = response.body.getReader()

[0230] function readChunk() {

[0231] reader.read().then(({ value, done}) => {

[0232] if (done) {

[0233] const blob = new Blob(chunks, { type:response.headers.get('content-type')})

[0234] resolve(blob)

[0235] } else {

[0236] chunks.push(value)

[0237] readChunk()

[0238] }

[0239] }).catch(reject)

[0240] }

[0241] readChunk()

[0242] })

[0243] })

[0244] .then(blob => {

[0245] if (blob) this.dataStorage(url, blob)

[0246] })

[0247] .catch(error => {

[0248] console.error('Failed to retrieve video stream and convert to Blob:', error)

[0249] })

[0250] }

[0251] }

[0252] / / === Utility function: Enable caching ===

[0253] function useCache(arr) {

[0254] const TDCache = new ThreeDtileCache({url: arr})

[0255] TDCache.intercept()

[0256] return TDCache.closeHandle

[0257] }

[0258] / / === Utility function: Cache video resources ===

[0259] function cacheVideo(url) {

[0260] const TDCache = new ThreeDtileCache({VideoUrl: url})

[0261] return TDCache.acheFetch()

[0262] }

[0263] / / === Module Export ===

[0264] export { useCache, cacheVideo}

[0265] Cache query module: Receives request information from the request interception module, extracts cache key-value pairs based on the request URL, queries the local database to see if the corresponding cache data exists, feeds back the query results to the request interception module, and triggers the data writing module if no cache data is found.

[0266] Local caching module: Receives data from the data writing module and stores resources such as 3D model data, textures, and video streams in the browser's local database in key-value format. The stored key-value pairs correspond to the cache key-value pairs extracted by the cache query module.

[0267] Data writing module: When the cache query module does not find the corresponding cached data, it receives the data returned by the network request, processes the data and passes it to the local cache module. JSON data is directly serialized, and binary resources such as video streams are converted into Blobs.

[0268] Cache management module: performs lifecycle management, status updates and cleanup of cached data stored in the local cache module. The cached data it manages covers all cached data corresponding to key-value pairs extracted by the cache query module.

[0269] The adapter interface module receives cached data stored in the local cache module and provides a unified cache call interface for integration with the Cesium engine. The cached data called by this interface comes from the cached data confirmed by the cache query module.

[0270] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for optimizing the loading of three-dimensional data, characterized in that, Includes the following steps: S1 request interception mechanism establishment: During the front-end page initialization phase, a third-party library is introduced to create a global request interceptor, which listens for 3D model resource requests initiated by the Cesium engine, filters requests for specified paths, and then enters the S2 cache key-value extraction and mapping step. S2 cache key-value extraction mapping: Extract key identifiers as cache keys based on the request URLs intercepted and filtered by S1, extract the last-level filename in the URL path to ensure fine-grained and unique caching, support caching of 3D tile data at different levels separately, and then proceed to the S3 cache state maintenance and dependency relationship building steps. S3 Cache State Maintenance and Dependency Building: The Map data structure is used to maintain the state of the current cache block corresponding to the cache key value extracted from S2. When parsing the response data, the child node dependencies are extracted and marked as objects to be cached, forming a three-dimensional data cache dependency tree. Then, the S4 cache hit judgment and local return steps are entered. S4 cache hit detection and local return: Based on the cache key-value extracted by S2, check whether the corresponding cache data exists in the local database before the request. If it exists, construct the response body and terminate the real network request; if it does not exist, initiate a network request and write the result to the local cache. For non-JSON type resources, proceed to the S5 multimedia resource independent caching step. S5 Multimedia Resource Independent Caching: For video streams, images, and other resources that are determined by S4 to be non-JSON type, the raw byte stream is obtained using FetchAPI and converted into a Blob object before caching. A local access link is generated using the URL.createObjectURL() method for Cesium to use. At the same time, this cache is controlled by the S6 cache lifecycle management steps. S6 Cache Lifecycle Management: Provides interfaces for enabling, disabling, and clearing cached data stored after processing by S4 and S5, allowing developers to dynamically control cache behavior according to business needs. Combined with a timestamp mechanism, it implements cache expiration control. Its management objects cover all cached data corresponding to cache key-value pairs extracted by S2. S7 Cesium Engine Integration: Provides a unified adaptation interface function for Cesium to call when loading 3D models processed by S1-S6 or playing video streams, enabling caching functionality without modifying the original Cesium code. This interface function is based on the caching results of S4 and S5.

2. The method for loading and optimizing three-dimensional data according to claim 1, characterized in that, In the steps of establishing the S1 request interception mechanism, the third-party library is ajax-hook, and the 3D model resource requests include requests of type .json, .b3dm, .pnts, and .glb.

3. The method for loading and optimizing three-dimensional data according to claim 1, characterized in that, In the S2 cache key-value extraction and mapping step, the key identifier is the last-level filename in the URL path, which is obtained through a string truncation utility function that extracts the content after the last ' / ' of the string.

4. The method for loading and optimizing three-dimensional data according to claim 1, characterized in that, In the S3 cache state maintenance and dependency relationship construction step, the state of the cache block includes whether it has been cached and whether it is an incremental cache. The response data includes tileset.json. The S3 cache state maintenance and dependency relationship construction step also includes a sub-resource dependency management process. When parsing the JSON format response data, this process automatically extracts the address of the sub-model, obtains the key value corresponding to the sub-model based on the S2 key-value extraction rules, adds it to the cache index mapping table, and marks it as a state to be cached.

5. The method for loading and optimizing three-dimensional data according to claim 1, characterized in that, In the S4 cache hit determination and local return step, the local database is IndexedDB. During the query, the cache key value extracted in S2 is used for lookup, and during the write, it is stored in the form of key-value pairs. The S4 cache hit determination and local return step also includes a cache query process. This process encapsulates a unified cache query interface, supports synchronous and asynchronous calls, and queries whether the corresponding cache data exists in the local database based on the cache key value extracted in S2.

6. The method for loading and optimizing three-dimensional data according to claim 1, characterized in that, In the S5 multimedia resource independent caching step, after FetchAPI obtains the raw byte stream, it converts the byte stream into a Blob object by reading the response body. The type of the Blob object is determined according to the content-type in the response header.

7. The method for loading and optimizing three-dimensional data according to claim 1, characterized in that, In the S6 cache lifecycle management step, the cache enable, disable, and clear interfaces are implemented through methods in the cache class. The timestamp mechanism records the storage time of cached data in S4 and S5 and compares it with the preset expiration time to achieve cache expiration control.

8. The method for loading and optimizing three-dimensional data according to claim 1, characterized in that, In the S7Cesium engine integration step, the adaptation interface functions include useCache and cacheVideo. useCache is called when loading the 3D model processed by S4, and cacheVideo is called when playing the video stream processed by S5.

9. The three-dimensional data loading optimization system according to claim 1, characterized in that, Includes the following modules: Request interception module: Listens to all HTTP requests from the browser, filters out 3D data requests that meet preset rules, and passes the filtered request information to the cache query module; Cache query module: Receives request information from the request interception module, extracts cache key-value pairs based on the request URL, queries the local database to see if corresponding cache data exists, feeds back the query results to the request interception module, and triggers the data writing module if no cache data is found. Local caching module: Receives data from the data writing module and stores resources such as 3D model data, textures, and video streams in the browser's local database in key-value format. The stored key-value pairs correspond to the cache key-value pairs extracted by the cache query module. Data writing module: When the cache query module does not find the corresponding cached data, it receives the data returned by the network request, processes the data and passes it to the local cache module. JSON data is directly serialized, and binary resources such as video streams are converted into Blobs. Cache management module: performs lifecycle management, status updates and cleanup of cached data stored in the local cache module. The cached data it manages covers all cached data corresponding to key-value pairs extracted by the cache query module. The adapter interface module receives cached data stored in the local cache module and provides a unified cache call interface for integration with the Cesium engine. The cached data called by this interface comes from the cached data confirmed by the cache query module.

10. A three-dimensional data loading optimization system according to claim 9, characterized in that, The request interception module defines the interception scope by configuring a filter path string, and only processes requests containing that string; after extracting the cache key value, the cache query module uses a Map data structure to record the mapping relationship between the key value and the cache status, which includes not cached and waiting to be cached.

Images