Three-dimensional model loading method and device, equipment and storage medium

Abstract

The invention discloses a three-dimensional model loading method and device, equipment and a storage medium. Comprising the following steps: initializing a request queue through a main thread, sending a network request based on the request queue, receiving a returned lightweight model file to extract geometric data, and sending the geometric data to a sub-thread; converting the received geometric data into binary data through the sub-thread, and returning the binary data to the main thread; and storing the binary data through the main thread. The network requests can be managed in order by initializing the request queue, and disordered sending of the requests is avoided. By sending the geometric data to the sub-threads, the pressure of the main thread can be shunted to avoid blockage, and the response efficiency of the main thread is guaranteed. The sub-thread undertakes a geometric data conversion task, and the working pressure of the main thread can be shunted. The binary data is stored through the main thread, so that the repeated operation of subsequent loading can be reduced to increase the speed, the repeated consumption of equipment resources can be reduced, and the stable operation of low-end equipment is ensured.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for loading three-dimensional models. Background Technology

[0002] In digital twin applications, to visualize large 3D scenes, it's typically necessary to first lightweight the original, massive 3D model, generating smaller, more easily transferable lightweight model files. The front-end then loads these files and renders the model. Because digital twin scenarios demand a high number and level of detail in the models, the front-end loading process handles a large amount of model data. However, different devices have varying CPU processing power, memory capacity, and network request handling capabilities. Therefore, ensuring loading efficiency while preventing device malfunctions due to insufficient resources becomes a core background requirement for 3D model loading.

[0003] Existing technical solutions suffer from several prominent problems in practical applications: First, loading performance issues. When a scene contains a large number of models, the lack of efficient request scheduling and data processing mechanisms leads to slow front-end loading, severely impacting user experience. Second, memory crashes. Low-end devices have limited memory capacity, and existing solutions do not effectively manage data storage, making them prone to memory overflow when loading a large number of 3D models, causing application crashes. Third, CPU overload issues. Low-end devices have weak CPU processing capabilities, and existing technologies often rely on the main thread to synchronously parse large amounts of geometric data, easily causing CPU overload and system crashes. Fourth, concurrency limitations. When the front-end sends a large number of network requests simultaneously, it triggers the browser's concurrency limits, leading to request failures and placing excessive pressure on the server. Fifth, inadequate caching mechanisms. Existing solutions lack effective memory management and offline caching mechanisms, failing to fully utilize device resources to improve loading efficiency and making it difficult to meet the stable loading requirements of large 3D scenes. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for loading three-dimensional models. By adopting a geometric data processing architecture that separates the main thread and child threads, combining a dual caching strategy of memory caching and local offline caching, and efficient binary data processing, it solves the technical problems of slow loading speed, memory overflow crashes, CPU overload crashes, browser concurrency limitations, and imperfect caching mechanisms when loading large three-dimensional scenes in the prior art.

[0005] According to one aspect of the present invention, a three-dimensional model loading method is provided, applied to a multi-threaded system, including a main thread and a sub-thread, the method comprising:

[0006] The main thread initializes the request queue, sends network requests based on the request queue, receives the returned lightweight model file to extract geometric data, and sends the geometric data to the child thread.

[0007] The received geometric data is converted into binary data by a sub-thread, and the binary data is returned to the main thread.

[0008] The binary data is stored through the main thread.

[0009] Optionally, the request queue can be initialized through the main thread, including: when a model loading instruction is received, initiating the establishment operation of the network request management pool, and synchronously completing the creation of the request queue in the initialization configuration of the network request management pool.

[0010] Optionally, sending network requests based on the request queue includes: determining whether the request queue is empty; if so, stopping the request sending process and waiting for new network requests to be enqueued; otherwise, determining the current concurrency and determining whether the current concurrency is less than the maximum concurrency; if so, retrieving and sending a network request from the head of the request queue; otherwise, pausing the retrieval of requests from the queue and entering a waiting state until a sent network request is completed.

[0011] Optionally, the method also includes: when a network request is sent, incrementing the current concurrency count by 1 to occupy a concurrency slot; when the network request is completed, decrementing the current concurrency count by 1 to release the concurrency slot.

[0012] Optionally, the returned lightweight model file is received to extract geometric data, including: parsing the lightweight model file to generate basic model information, wherein the basic model information includes model location and spatial attributes; creating a network object containing only the basic framework based on the basic model information; and extracting and separating geometric data from the lightweight model file based on the network object.

[0013] Optionally, the received geometric data can be converted into binary data via a sub-thread, including: decompressing the geometric data via a sub-thread to generate decompressed data; parsing and optimizing the decompressed data to generate processed geometric data; and calling a binary conversion tool to perform binary conversion on the processed geometric data to generate binary data.

[0014] Optionally, binary data can be stored through the main thread, including: storing binary data in a memory cache; synchronously storing binary data in a local offline cache, and completing cache version marking to achieve version management.

[0015] According to another aspect of the present invention, a three-dimensional model loading device is provided, applied to a multi-threaded system, including a main thread and a sub-thread, the device comprising:

[0016] The geometric data extraction module is used to initialize the request queue through the main thread, send network requests based on the request queue, receive the returned lightweight model file to extract geometric data, and send the geometric data to the child thread;

[0017] The binary data conversion module is used to convert the received geometric data into binary data through a sub-thread and return the binary data to the main thread;

[0018] The data storage module is used to store binary data via the main thread.

[0019] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0020] At least one processor;

[0021] and a memory communicatively connected to the at least one processor;

[0022] The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform a three-dimensional model loading method according to any embodiment of the present invention.

[0023] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement a three-dimensional model loading method according to any embodiment of the present invention.

[0024] The technical solution of this invention enables orderly management of network requests by initializing a request queue, avoiding chaotic request sending. By sending geometric data to a sub-thread, the main thread can handle only lightweight request management, file reception, and data extraction tasks, avoiding main thread blocking and ensuring its response efficiency. Having the sub-thread handle geometric data conversion tasks offloads workload from the main thread. Storing binary data in the main thread reduces repetitive loading operations, improving speed and reducing redundant consumption of device resources, ensuring stable operation on low-end devices.

[0025] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0027] Figure 1 This is a flowchart of a three-dimensional model loading method provided in Embodiment 1 of the present invention;

[0028] Figure 2 This is a flowchart of another three-dimensional model loading method provided in Embodiment 2 of the present invention;

[0029] Figure 3 This is a schematic diagram of the structure of a three-dimensional model loading device according to Embodiment 3 of the present invention;

[0030] Figure 4 This is a schematic diagram of the structure of an electronic device that implements a three-dimensional model loading method according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] Example 1

[0034] Figure 1This is a flowchart illustrating a three-dimensional model loading method provided in Embodiment 1 of the present invention. This embodiment is applicable to digital twin three-dimensional model loading scenarios. The method can be executed by a three-dimensional model loading device, which can be implemented in hardware and / or software. This device can be configured in a multi-threaded system, which includes a main thread and multiple sub-threads. Figure 1 As shown, the method includes:

[0035] S110. Initialize the request queue through the main thread, send network requests based on the request queue, receive the returned lightweight model file to extract geometric data, and send the geometric data to the child thread.

[0036] The main thread, created by default in a multi-threaded system, is responsible for the core interaction logic. Its core functions include initializing the request queue, sending network requests, receiving lightweight model files, parsing basic model information, creating a mesh network object, extracting geometric data and sending it to child threads, receiving binary data returned by child threads, initializing geometry objects and assembling mesh objects, and finally, storing the model and triggering scene rendering. Child threads, created outside the main thread, are used to handle specific heavy computational tasks. They do not directly participate in page rendering or user interaction and can execute tasks independently in the background. The number of child threads can be dynamically adjusted based on device performance. In this 3D model loading method, the role of child threads is to handle geometric data parsing. Handling heavy tasks with child threads effectively reduces the pressure on the main thread. Furthermore, controlling the number of child threads (e.g., 2-4) avoids overloading the CPU on low-end devices and prevents system crashes.

[0037] Specifically, a request queue is an ordered data structure that manages network requests based on the first-in, first-out (FIFO) principle. It's used to uniformly schedule network requests for loading lightweight model files, preventing chaotic request delivery. All network requests for loading lightweight model files first enter the queue to wait, working in conjunction with the network request management pool to implement concurrency control. When the number of requests being sent hasn't reached the maximum concurrent request count, a request is retrieved from the queue and sent. When a request completes or fails, a new request is automatically resent from the queue, ensuring orderly request processing. This prevents the browser from triggering concurrency limits due to receiving a large number of requests simultaneously, and also prevents the server from experiencing excessive pressure due to request overload.

[0038] In this context, network requests refer to requests sent by the main thread to the server. Sending network requests allows the acquisition of model resources needed in the digital twin scenario, namely lightweight model files. The sending of network requests is controlled by a request queue and a network request management pool. Through concurrency limits and automatic resending mechanisms, stable request delivery is ensured, while preventing browser errors or server crashes due to excessive requests. Geometric data describes the spatial shape and structure of the 3D model, including vertex coordinates, face indices, texture coordinates, normal vectors, and other information.

[0039] Optionally, the request queue can be initialized through the main thread, including: when a model loading instruction is received, initiating the establishment operation of the network request management pool, and synchronously completing the creation of the request queue in the initialization configuration of the network request management pool.

[0040] Specifically, when the front-end receives a model loading instruction, the main thread prioritizes establishing a network request management pool. During the initialization and configuration phase of the network request management pool, the main thread synchronously creates the request queue. Simultaneously, the network request management pool configures the maximum concurrent request count during initialization. This maximum concurrent request count is set based on a balance between the browser's concurrency capabilities and the server's capacity limits, preventing slow loading due to excessively low concurrency while also preventing excessively high concurrency from triggering browser limitations or overwhelming the server. Furthermore, the network request management pool also initiates request monitoring during initialization. The main thread monitors the number of currently sent but incomplete requests in real time. When the number is below the maximum concurrent request count, a request is retrieved from the head of the request queue and a network request is initiated. Once a request is completed, the next request is automatically retrieved from the queue and resent.

[0041] Optionally, sending network requests based on the request queue includes: determining whether the request queue is empty; if so, stopping the request sending process and waiting for new network requests to be enqueued; otherwise, determining the current concurrency and determining whether the current concurrency is less than the maximum concurrency; if so, retrieving and sending a network request from the head of the request queue; otherwise, pausing the retrieval of requests from the queue and entering a waiting state until a sent network request is completed.

[0042] Specifically, the request queue stores all network requests to be sent. If the request queue is empty, it means there are no more model tasks to load, and the request sending process will stop and enter a waiting state until a new model loading requirement arises and a new network request is enqueued, at which point the request sending logic will restart. If the request queue is not empty, the main thread will further determine the current concurrency level, which refers to the number of network requests that have been sent but not yet completed.

[0043] Furthermore, the main thread checks if the current concurrency is less than the maximum concurrency. If the current concurrency is below the maximum, it means there is still room to send requests. In this case, the main thread can retrieve the first network request from the head of the request queue and initiate its transmission, while simultaneously incrementing the current concurrency count to ensure accurate concurrency statistics later. If the current concurrency has reached or exceeded the maximum, it means that continuing to send requests would exceed the system's capacity limit. Therefore, it will pause request retrieval from the queue and enter a waiting state. It's important to note that the waiting state is not indefinite; rather, it monitors the status of sent requests in real time. Once any sent network request completes—whether it's successfully receiving the lightweight model file or failing and triggering a retry mechanism—the main thread decrements the current concurrency count. If the concurrency then falls below the maximum again, it will immediately retrieve the next request from the head of the request queue and send it. This ensures orderly and stable request transmission, guaranteeing loading efficiency while avoiding system problems caused by uncontrolled concurrency.

[0044] Optionally, the method also includes: when a network request is sent, incrementing the current concurrency count by 1 to occupy a concurrency slot; when the network request is completed, decrementing the current concurrency count by 1 to release the concurrency slot.

[0045] Specifically, when the main thread determines that a network request can be sent based on the request queue, it simultaneously increments the current concurrency count by 1 while retrieving the request from the head of the queue and initiating the network request. Since the maximum number of concurrent requests is a key threshold set based on the browser's concurrency capacity and the server's request processing limits, each new request consumes one available resource slot. Incrementing the concurrency count allows the real-time tracking of currently used concurrent resources, preventing subsequent repeated requests from exceeding the maximum concurrency limit and ensuring that request transmission remains within the system's stable capacity. When a network request completes, the main thread decrements the current concurrency count by 1. Completed requests no longer consume system concurrency resources, and decrementing the concurrency count releases an available concurrency slot in real time. This allows the main thread to promptly detect when the current concurrency count is less than the maximum concurrency count during subsequent monitoring, and then retrieve the next request from the request queue, thus achieving the recycling of concurrency slots.

[0046] Optionally, the returned lightweight model file is received to extract geometric data, including: parsing the lightweight model file to generate basic model information, wherein the basic model information includes model location and spatial attributes; creating a network object containing only the basic framework based on the basic model information; and extracting and separating geometric data from the lightweight model file based on the network object.

[0047] The basic model information is data extracted first from the lightweight model file, describing the spatial positioning and basic morphological features of the 3D model, including model position and spatial attributes. Model position refers to the model's 3D coordinates in the digital twin 3D scene, used to determine the model's specific placement within the scene. Spatial attributes include the model's rotation angle and scaling ratio, which together determine the model's spatial posture in the scene. A network object is the basic unit used to represent a renderable model in the digital twin 3D scene. A network object containing only the basic framework refers to a preliminary Mesh object created by the main thread based on the basic model information, without being associated with specific geometric data. A complete Mesh object must include geometry and material properties; at this stage, the basic framework only determines the model's spatial position, rotation posture, and scaling ratio through the basic model information, but does not contain geometric data defining the model's specific shape. The purpose of creating this framework is to enable lightweight tasks to be handled by the main thread and heavy tasks to be distributed among sub-threads, avoiding the main thread being blocked due to synchronous processing of geometric data, and preparing for the subsequent integration of geometric data processed by sub-threads and the assembly of the complete model.

[0048] Specifically, after receiving the lightweight model file returned by the server, the main thread first parses the file to generate basic model information. Then, based on the generated basic model information, the main thread creates a Mesh object containing only the basic framework. Finally, based on the basic framework of the created Mesh object, the main thread extracts and separates geometric data from the lightweight model file. Since the Mesh object framework clearly defines the spatial attributes and basic relationships of the model, the main thread can accurately locate and extract the corresponding geometric data of the model based on the model identifier corresponding to the framework. At the same time, the separated geometric data is temporarily stored and prepared to be sent to the child thread, because parsing geometric data requires a lot of CPU resources, and handing it over to the child thread can avoid blocking the main thread.

[0049] S120. The received geometric data is converted into binary data through a sub-thread, and the binary data is returned to the main thread.

[0050] Binary data refers to a data format generated by converting geometric data into binary form and storing it in binary format. Compared to text formats such as JSON and XML, binary format is smaller in size, which can significantly reduce the resources required for data storage and transmission, has a faster parsing speed, and is easier to manage as a cache.

[0051] S130, Store binary data through the main thread.

[0052] Optionally, binary data can be stored through the main thread, including: storing binary data in a memory cache; synchronously storing binary data in a local offline cache, and completing cache version marking to achieve version management.

[0053] Specifically, the main thread associates binary data with corresponding model identifiers and stores them in a memory cache. This ensures that when loading the same model later, it can be quickly matched and read using the identifier, avoiding repeated network requests and sub-thread processing, thus significantly improving loading speed. Simultaneously, the main thread controls the overall memory cache usage based on the last-in-first-out (LIFO) principle and strictly sets the cache size to the maximum of 30% of the device's total memory. Furthermore, the main thread also calculates the cache hit rate, providing a basis for subsequent optimization of cache resource allocation.

[0054] Furthermore, the local offline cache is implemented using the browser's IndexedDB. During synchronous storage, the main thread first writes the binary data along with metadata such as model identifier and storage time to IndexedDB. This ensures that when loading the model offline, data can be directly read from the local cache without relying on the network. Simultaneously, cache version marking is performed. It's worth noting that each cached data is associated with a unique version number. When the server-side model file is updated, the frontend can identify the old cached data by comparing the version numbers, promptly clearing expired cache and storing new data. This avoids display errors caused by using old cache, ensuring that the data in the local offline cache is always consistent with the latest version. This achieves both long-term resource retention and guarantees the accuracy and availability of cached data.

[0055] The technical solution of this invention enables orderly management of network requests by initializing a request queue, avoiding chaotic request sending. By sending geometric data to a sub-thread, the main thread can handle only lightweight request management, file reception, and data extraction tasks, avoiding main thread blocking and ensuring its response efficiency. Having the sub-thread handle geometric data conversion tasks offloads workload from the main thread. Storing binary data in the main thread reduces repetitive loading operations, improving speed and reducing redundant consumption of device resources, ensuring stable operation on low-end devices.

[0056] Example 2

[0057] Figure 2 This is a flowchart of a three-dimensional model loading method provided in Embodiment 2 of the present invention. This embodiment adds a specific process to Embodiment 1, whereby the received geometric data is converted into binary data via a sub-thread, and the binary data is returned to the main thread. The specific content of steps S210 and S250 is largely the same as steps S110 and S130 in Embodiment 1, and therefore will not be repeated in this embodiment. Figure 2 As shown, the method includes:

[0058] S210. Initialize the request queue through the main thread, send network requests based on the request queue, receive the returned lightweight model file to extract geometric data, and send the geometric data to the child thread.

[0059] Optionally, the request queue can be initialized through the main thread, including: when a model loading instruction is received, initiating the establishment operation of the network request management pool, and synchronously completing the creation of the request queue in the initialization configuration of the network request management pool.

[0060] Optionally, sending network requests based on the request queue includes: determining whether the request queue is empty; if so, stopping the request sending process and waiting for new network requests to be enqueued; otherwise, determining the current concurrency and determining whether the current concurrency is less than the maximum concurrency; if so, retrieving and sending a network request from the head of the request queue; otherwise, pausing the retrieval of requests from the queue and entering a waiting state until a sent network request is completed.

[0061] Optionally, the method also includes: when a network request is sent, incrementing the current concurrency count by 1 to occupy a concurrency slot; when the network request is completed, decrementing the current concurrency count by 1 to release the concurrency slot.

[0062] Optionally, the returned lightweight model file is received to extract geometric data, including: parsing the lightweight model file to generate basic model information, wherein the basic model information includes model location and spatial attributes; creating a network object containing only the basic framework based on the basic model information; and extracting and separating geometric data from the lightweight model file based on the network object.

[0063] S220. Decompress the geometric data through a sub-thread to generate decompressed data.

[0064] Specifically, to reduce the amount of data transmitted over the network and improve the speed of model file transmission, the geometric data in the lightweight model file returned by the server is compressed. The compressed geometric data cannot be directly used for parsing and conversion; therefore, a sub-thread must first perform a decompression operation. After receiving the geometric data sent by the main thread, the sub-thread calls the corresponding decompression algorithm to restore the compressed data, generating decompressed data that can be processed later. This process is executed in the sub-thread because decompression consumes CPU resources. If handled by the main thread, it might cause the main thread to block, affecting page rendering and user interaction responsiveness. The sub-thread, not directly involved in front-end interaction, can independently complete the decompression task in the background, avoiding the occupation of main thread resources.

[0065] S230. The decompressed data is parsed and optimized to generate processed geometric data.

[0066] Specifically, the decompressed data remains in its original data structure state, containing some redundant information, such as duplicate vertex coordinates and invalid face index data. Furthermore, the data format may not meet the requirements of subsequent binary conversion and model rendering, thus requiring further parsing and optimization. During parsing, a sub-thread extracts key information from the decompressed data according to the standard structure of 3D model data and standardizes it into a unified data format. The optimization process removes redundant information from the data, such as merging duplicate vertices and eliminating invalid face data. Simultaneously, it performs data normalization processing, such as adjusting coordinate precision and optimizing data arrangement order, reducing the data volume while improving the efficiency of subsequent binary conversion and model rendering.

[0067] S240. Call the binary conversion tool to perform binary conversion on the processed geometric data and generate binary data.

[0068] Specifically, if the processed geometric data exists in text format, it will occupy a large amount of storage space, and the CPU is less efficient at reading and processing text data. Furthermore, storing it in the cache or transmitting it will consume even more resources. Binary data, on the other hand, has advantages such as small size, high CPU processing efficiency, and ease of cache management. Therefore, the child thread will call a pre-defined binary conversion tool, such as a dedicated tool in the Three.js framework that supports converting geometric data to binary, or a custom binary encoding tool, to encode the processed geometric data into binary format according to a pre-defined binary data structure, generating the final binary data.

[0069] S250: Store binary data through the main thread.

[0070] Optionally, binary data can be stored through the main thread, including: storing binary data in a memory cache; synchronously storing binary data in a local offline cache, and completing cache version marking to achieve version management.

[0071] The technical solution of this invention uses a sub-thread to decompress geometric data, thereby avoiding CPU resource consumption by the main thread during decompression and preventing main thread blocking. By parsing and optimizing the decompressed data generated by the sub-thread to produce processed geometric data, data redundancy is removed, data format is standardized, resource consumption for subsequent data processing is reduced, and data availability is improved. Converting the processed geometric data into binary data using a binary conversion tool further reduces data size, lowers storage and transmission resource consumption, and improves CPU processing efficiency.

[0072] Example 3

[0073] Figure 3 This is a schematic diagram of a three-dimensional model loading device provided in Embodiment 3 of the present invention. Figure 3As shown, the device includes: a geometric data extraction module 310, which is used to initialize a request queue through the main thread, send network requests based on the request queue, and receive the returned lightweight model file to extract geometric data, and send the geometric data to a sub-thread;

[0074] The binary data conversion module 320 is used to convert the received geometric data into binary data through a sub-thread and return the binary data to the main thread;

[0075] Data storage module 330 is used to store binary data through the main thread.

[0076] Optionally, the geometric data extraction module 310 specifically includes: an initialization request queue unit, used to: initiate the establishment operation of the network request management pool when a model loading instruction is received, and synchronously complete the creation of the request queue in the initialization configuration of the network request management pool.

[0077] Optionally, the geometric data extraction module 310 specifically includes: a network request sending unit, used to: determine whether the request queue is empty; if so, stop the request sending process and wait for a new network request to be enqueued; otherwise, determine the current concurrency and determine whether the current concurrency is less than the maximum concurrency; if so, extract and send a network request from the head of the request queue; otherwise, pause retrieving requests from the queue and enter a waiting state until a sent network request is completed.

[0078] Optionally, the device also includes a current concurrency increment / decrement module, used to: increment the current concurrency by 1 when a network request is sent, occupying a concurrency slot; and decrement the current concurrency by 1 when the network request is completed, releasing the concurrency slot.

[0079] Optionally, the geometric data extraction module 310 specifically includes: a geometric data extraction unit, used for: parsing the lightweight model file to generate basic model information, wherein the basic model information includes model location and spatial attributes; creating a network object containing only the basic framework based on the basic model information; and extracting and separating geometric data from the lightweight model file based on the network object.

[0080] Optionally, the binary data conversion module 320 is specifically used for: decompressing geometric data through a sub-thread to generate decompressed data; parsing and optimizing the decompressed data to generate processed geometric data; and calling a binary conversion tool to perform binary conversion on the processed geometric data to generate binary data.

[0081] Optionally, the data storage module 330 is specifically used for: storing binary data in a memory cache; synchronously storing binary data in a local offline cache; and completing cache version marking to achieve version management.

[0082] The technical solution of this invention enables orderly management of network requests by initializing a request queue, avoiding chaotic request sending. By sending geometric data to a sub-thread, the main thread can handle only lightweight request management, file reception, and data extraction tasks, avoiding main thread blocking and ensuring its response efficiency. Having the sub-thread handle geometric data conversion tasks offloads workload from the main thread. Storing binary data in the main thread reduces repetitive loading operations, improving speed and reducing redundant consumption of device resources, ensuring stable operation on low-end devices.

[0083] The three-dimensional model loading device provided in this embodiment of the invention can execute a three-dimensional model loading method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0084] Example 4

[0085] Figure 4 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0086] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0087] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0088] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a three-dimensional model loading method.

[0089] In some embodiments, a three-dimensional model loading method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the three-dimensional model loading method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a three-dimensional model loading method by any other suitable means (e.g., by means of firmware).

[0090] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0091] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0092] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0093] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0094] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0095] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0096] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0097] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A three-dimensional model loading method characterized by comprising: Applied to a multi-thread system including a main thread and a sub-thread, the method comprises: initializing a request queue through the main thread, sending a network request based on the request queue, and receiving a returned lightweight model file to extract geometric data and send the geometric data to the sub-thread; converting the received geometric data into binary data through the sub-thread and returning the binary data to the main thread; storing the binary data through the main thread.

2. The method of claim 1, wherein, The initialization of the request queue through the main thread comprises: when a model loading instruction is received, initiating an establishment operation of a network request management pool, and synchronously creating a request queue in the initialization configuration of the network request management pool.

3. The method of claim 1, wherein, The sending of the network request based on the request queue comprises: determining whether the request queue is empty, if yes, stopping the request sending process and waiting for a new network request to be enqueued; otherwise, determining a current concurrency number and determining whether the current concurrency number is less than a maximum concurrency number, if yes, extracting and sending a network request from the head of the request queue; otherwise, pausing the request taking from the queue and entering a waiting state until a completed network request is sent.

4. The method of claim 3, wherein, The method further comprises: when the network request is sent, increasing the current concurrency number by 1 to occupy a concurrency quota; when the network request is completed, decreasing the current concurrency number by 1 to release the concurrency quota.

5. The method of claim 1, wherein, The receiving of the returned lightweight model file to extract the geometric data comprises: parsing the lightweight model file to generate model basic information, wherein the model basic information comprises a model position and spatial attributes; creating a network object containing only a basic framework based on the model basic information; extracting and separating geometric data from the lightweight model file according to the network object.

6. The method of claim 5, wherein, The conversion of the received geometric data into binary data through the sub-thread comprises: decompressing the geometric data through the sub-thread to generate decompressed data; parsing and optimizing the decompressed data to generate processed geometric data; calling a binary conversion tool to perform binary conversion on the processed geometric data to generate binary data.

7. The method of claim 1, wherein, The storage of the binary data through the main thread comprises: storing the binary data to a memory cache; synchronously storing the binary data to a local offline cache and completing cache version marking to realize version management.

8. A three-dimensional model loading apparatus applied to a multi-thread system including a main thread and a sub thread, comprising: The device comprises: a geometric data extraction module for initializing a request queue through a main thread, sending a network request based on the request queue, and receiving a returned lightweight model file to extract geometric data and send the geometric data to a sub-thread; a binary data conversion module for converting received geometric data into binary data through the sub-thread and returning the binary data to the main thread; a data storage module for storing the binary data through the main thread.

9. An electronic device, comprising: The electronic device comprises: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores a computer program capable of being executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the method in any one of claims 1-7.

10. A computer storage medium, characterized in that, The computer storage medium stores computer instructions for causing the processor to implement the method in any one of claims 1-7 when executed.

Images