Engine data normalization processing method

Abstract

The invention relates to the cross technical field of internet and digital twinning technologies, and discloses an engine data normalization processing method, which comprises the following steps of: analyzing an input heterogeneous 3D model through an XML Schema and binary stream mixed architecture to generate a 3D model with a uniform format; engine data in the 3D model with the unified format is subjected to data partitioning according to the resolution ratio, the engine data in different data partitions are converted into different voxel data representation, and a static octree structure is generated; and when engine data in the static octree structure changes, recalculating and updating octree nodes in an engine data change region by using a spatial adjacency relationship among the engine data in the static octree structure, and converting the static octree structure into a dynamically updated octree structure. The problem that different engine data formats are incompatible in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of intersectional technology between the Internet and digital twin technology, specifically a method for normalizing engine data. Background Technology

[0002] With the increasing application of digital twin technology in fields such as intelligent manufacturing and smart cities, developers often need to develop and deploy using various 3D engines such as Unity, Unreal Engine, and WebGL. However, the current lack of a unified 3D data standard in the industry leads to the following significant problems: Data format incompatibility: Each 3D engine uses proprietary data formats (such as FBX, OBJ, GLTF, etc.), making it difficult to directly exchange model assets; Inconsistent rendering effects: Differences in the rendering pipelines and material systems of different engines lead to problems such as material color differences and texture loss for the same model on different platforms; Low processing efficiency: Traditional conversion tools suffer from problems such as excessively long voxelization time, cumbersome animation data processing, and inability to fully utilize the parallel computing capabilities of modern hardware when processing highly complex models.

[0003] Currently, there are various 3D engines available, and application developers often face the challenge of switching between multiple engines. They hope to reduce the cost of switching between different engines or find a universal skill set to learn. Therefore, this paper emphasizes how unified technologies can help developers work across engines or improve project portability. Current technologies suffer from the following problems: incompatible data models, with different engines using proprietary data formats; lack of a unified graphics API, requiring multiple 3D engines to handle low-level details on different platforms, increasing development costs and maintenance difficulty; texture loss during multi-format 3D model conversion (average loss rate 23%); voxelization processing cannot adapt to model complexity (processing a 100,000-facet model takes >15 seconds); and color differences exist in cross-engine material rendering (ΔE > 4.5). Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides an engine data normalization processing method, which solves problems such as incompatibility between different engine data formats in existing technologies.

[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: An engine data normalization processing method includes the following steps: The heterogeneous 3D model input is parsed using a hybrid architecture of XML Schema and binary stream to generate a 3D model in a unified format; the heterogeneous 3D model includes engine data in two or more formats. The engine data in the 3D model with a unified format is partitioned according to the resolution, so that the engine data in different data partitions have different resolution ranges. The engine data in different data partitions is converted into different voxel data representations to generate a static octree structure. When engine data changes in a static octree structure, the octree nodes in the changed engine data area are recalculated and updated using the spatial adjacency relationships between engine data in the static octree structure, thus converting the static octree structure into a dynamically updated octree structure.

[0006] As a preferred technical solution, the heterogeneous input 3D model is parsed using a hybrid architecture of XML Schema and binary stream to generate a 3D model in a unified format, including the following steps: Collect equipment data and POI data, use spatiotemporal feature encoding to unify data format and coordinate system, convert latitude and longitude into discrete indexes, encode time into multi-dimensional feature vectors, and normalize the static attributes of equipment data and POI data to obtain fixed-length feature vectors. The legality rules for the data structure of engine data are defined using XML Schema. Non-text data or text data with a size greater than a set threshold are directly processed using binary streams and transmitted in byte form. The legality rules include one or more of the following: element type, constraints, and nesting relationships. Decouple the coupled geometric information, material information, and animation data in the 3D model; Convert continuous animation data embedded in a 3D model into discrete keyframe data; Offload 3D model preprocessing tasks from the CPU to the GPU.

[0007] As a preferred technical solution, converting continuous animation data embedded in a 3D model into discrete keyframe data includes the following steps: Initial segmentation: The continuous animation data is segmented using all feature frames as initial segmentation points; Piecewise fitting: For each segment of data between two adjacent keyframes P0 and P3, use the least squares method to find the two optimal control points P1 and P2 such that the error between the cubic Bézier curve defined by P0, P1, P2, and P3 and the original data points is minimized. Error calculation: Calculate the root mean square value of all errors between the fitted curve and the original data points; Iterative subdivision and optimization: If the error is greater than the set threshold, a new keyframe is inserted at the point with the largest error in the segment between P0 and P3. Then, the data in the segment between P0 and P3 is divided into two new sub-segments, and the segment fitting is repeated for the two new sub-segments. If the error is less than or equal to the set threshold, then the segments between P0 and P3, keyframes P0 and P3, and control points P1 and P2 are retained.

[0008] As a preferred technical solution, when offloading 3D model preprocessing tasks from the CPU to the GPU, vertex processing acceleration is performed, including the following steps: On the CPU side, the extracted vertex data is allocated in the GPU memory using the CUDA interface, and the cudaMemcpy function is used to asynchronously copy the vertex data from the host memory to the GPU memory. Each vertex processing task is mapped to an independent CUDA thread, enabling parallel processing of vertex data.

[0009] As a preferred technical solution, when offloading 3D model preprocessing tasks from the CPU to the GPU, texture compression acceleration is performed, converting the original texture into a block compression format in real time, including the following steps: On the CPU side, the unpacked texture data is decoded, and the decoded texture data is copied to the GPU memory. Each thread block loads pixel blocks from global video memory into shared memory; The thread within the thread block analyzes the color distribution, brightness, and alpha channel characteristics of the pixel block; The threads attempt multiple compression modes in parallel to find the optimal compression parameters for the current pixel block; Write the optimal compression parameters into the output buffer in the video memory.

[0010] As a preferred technical solution, engine data in a uniformly formatted 3D model is partitioned according to resolution, so that engine data in different data partitions have different resolution ranges. The engine data in different data partitions is then converted into different voxel data representations to generate a static octree structure, including the following steps: The Gaussian curvature of the vertices is calculated in parallel using CPU and OpenMP. The spatial bounding box and curvature map data of the mesh are streamed into the FPGA. The FPGA performs curvature sampling on the input 3D space, calculates the required voxel density through a predefined or programmable mapping function, obtains the voxel size assigned to different spatial regions, and outputs it as a lookup table or 3D texture. Convert the contents of the lookup table or 3D texture into voxel data and fill it into a 3D voxel mesh; The data structure of voxel data in the 3D voxel mesh is transformed using the octree compression algorithm.

[0011] As a preferred technical solution, the data structure transformation of voxel data in a 3D voxel mesh using the octree compression algorithm includes the following steps: The three-dimensional Boolean mesh output by the voxel generation layer marks whether each voxel is occupied; traverse the entire three-dimensional Boolean mesh and form a voxel coordinate list by the three-dimensional coordinates of the occupied voxels. The three-dimensional coordinates are interleaved and encoded into a one-dimensional Morton code; For all voxels in the voxel list, sort them in ascending order according to Morton code. In the sorted list, the voxels are linearly arranged in memory according to the Z-order curve. Treat the entire 3D Boolean mesh as the root node, and then recursively divide the 3D Boolean mesh into 8 equal-sized sub-cubes until each leaf node contains only one voxel or is empty.

[0012] As a preferred technical solution, when engine data changes in a static octree structure, the octree nodes in the changed engine data area are recalculated and updated using the spatial adjacency relationships between engine data in the static octree structure, thus converting the static octree structure into a dynamically updated octree structure. This includes the following steps: Construct a dynamic graph convolutional network for spatiotemporal feature aggregation of attribute features in an octree structure for dynamic updates; wherein, the attribute features include one or more of the following: static attribute feature vectors of devices, static attribute feature vectors of POIs, dynamic state data of devices, dynamic state data of POIs, the attribute features are nodes of the graph, and the dynamic adjacency matrix defines the connection relationship of the graph nodes. Using the attribute features of each node as the initial feature vector, the dynamic graph convolutional network uses multi-layer graph convolution operations to enable each node to aggregate the feature information of its neighboring nodes, generating an aggregated node feature vector.

[0013] As a preferred technical solution, when engine data changes in a static octree structure, the octree nodes in the changed engine data area are recalculated and updated using the spatial adjacency relationships between engine data in the static octree structure, thus converting the static octree structure into a dynamically updated octree structure. This includes the following steps: Based on the spatial location of the device and / or POI, create the geometry corresponding to the device and / or POI in the 3D scene, and set the initial color, size and transparency for each geometry; Based on the spatiotemporal feature aggregation results, the color, size, and transparency of the geometry are updated in real time, and the spatial location and aggregation features are converted into three-dimensional graphic elements.

[0014] As a preferred technical solution, when engine data changes in a static octree structure, the octree nodes in the changed engine data area are recalculated and updated using the spatial adjacency relationships between engine data in the static octree structure, thus converting the static octree structure into a dynamically updated octree structure. This includes the following steps: The aggregated feature vector output after aggregating spatiotemporal features is passed to the shader program of the rendering engine in real time. The eigenvalues ​​are converted into colors using the HSL space brightness mapping function; Based on device status or importance indicators, the geometry is dynamically scaled to achieve size conversion; The exponential decay curve is used to convert the age of data into transparency. The fragment shader receives spatial location density information and aggregate feature values ​​of the geometry, calculates the color of each geometry pixel in real time on the GPU, and generates a heat map.

[0015] Compared with the prior art, the present invention has the following advantages: (1) This invention uses a hybrid parsing architecture to parse 3D models. The XML Schema layer defines the legality rules of the data structure, and the binary stream layer directly processes non-text or large-capacity data and transmits it in the form of raw bytes to avoid text encoding overhead. It decouples the tightly coupled geometric information, material information and animation data in the 3D model, laying the foundation for subsequent independent optimization, efficient conversion and cross-engine compatibility. Through the above-mentioned finely designed CUDA parallel computing scheme, it successfully completes the preprocessing tasks that originally took several seconds or even tens of seconds on the CPU at a sub-second speed on the GPU, providing a key guarantee for the real-time performance of the entire normalization processing flow. (2) The present invention adopts an adaptive resolution strategy to convert polygon meshes into voxel representations. Nested encoding allows the use of voxels of different precision in different regions, optimizing storage space while maintaining details. It transforms the voxel data generated by the voxel generation layer, which is usually very dense and redundant, into a sparse, efficient and easy-to-query data structure. While ensuring data integrity, it achieves significant storage optimization and query acceleration. (3) This invention performs SVO construction rendering, develops a cross-platform PBR rendering pipeline, is compatible with the three major engines Unity / Unreal / WebGL, realizes physically based lighting consistency calibration, and makes visual differences between multiple platforms imperceptible. It organizes voxel data through an octree structure to achieve efficient storage and query, converts unified voxel data into a dynamic 3D scene that can be efficiently rendered and interacted with, and solves the final rendering problem across engines. Nested encoding is particularly suitable for handling the irregular distribution characteristics of 3D point cloud data, and can effectively solve the problem of information loss that may occur when traditional methods process sparse areas. Attached Figure Description

[0016] Figure 1 This is the overall flowchart of the present invention; Figure 2 This is a diagram illustrating the steps involved in the preprocessing stage of this invention. Figure 3 This is a flowchart of the SVO construction and rendering stage of the present invention; Figure 4 This is a flowchart of the adapter packaging process of the present invention. Detailed Implementation

[0017] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0018] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0019] Example 1 like Figures 1 to 4 As shown, this invention, by constructing a multimodal parsing engine and an adaptive processing framework, can be widely applied to scenarios such as intelligent manufacturing (e.g., digital twins of production lines), smart cities (lightweight BIM models), and virtual reality (cross-platform asset processing), effectively solving the current interoperability problem of industrial-grade 3D data. This invention provides a unified normalization processing method for processing data from multiple digital twin engines. This method constructs an intelligent, adaptive processing pipeline to convert heterogeneous 3D models into a unified intermediate representation, thereby achieving high-fidelity, high-efficiency rendering across engines.

[0020] This invention proposes an Intelligent Voxel Encoding System (IVES), which works collaboratively through the following technical modules: Multimodal Format Parsing Engine: Employing a hybrid parsing architecture (XML Schema and binary stream hybrid: a technical solution combining structured data validation and efficient binary processing, its core lies in defining data structures and rules through XML Schema while utilizing binary streams to process non-text or large-volume data), this engine achieves efficient and accurate parsing of various formats such as FBX, OBJ, and GLTF. This engine innovatively decouples skeletal animation data from static geometry and features dynamic material library mapping to adapt to the texture naming conventions of different engines. It utilizes a hybrid XML Schema and binary stream parsing architecture, developing an interpreter that supports both FBX and OBJ protocols; innovatively decouples skeletal animation data from static geometry, improving model display processing speed by 300% (from 4.2s to 1.4s); and adds dynamic material library mapping functionality to automatically match texture naming conventions for different formats.

[0021] Dynamic resolution voxelization module: Based on surface curvature analysis algorithms and complexity evaluation functions, it adaptively determines the optimal voxel resolution for different model regions. This significantly optimizes computational and storage resources and improves processing efficiency while preserving key details. By introducing surface curvature analysis algorithms, the voxelization efficiency of million-facet building models is improved by 40%, and the newly added complexity evaluation function improves processing efficiency by another 40%.

[0022] Material Preservation Encoding Module: This module achieves lossless or high-fidelity material conversion through a two-way verification mechanism using UV coordinate reparameterization technology and texture hash fingerprints (such as SHA-256). It supports the transfer of advanced material properties, including Subsurface Scattering, ensuring visual consistency. Lossless material conversion is achieved; a test on a certain architectural model showed a color difference ΔE < 1.2. This is achieved using UV coordinate reparameterization technology combined with texture hash fingerprints (SHA-256) for two-way verification; and lossless transfer of advanced material properties such as Subsurface Scattering is supported.

[0023] This method employs a three-stage processing architecture: data preprocessing, voxelization transformation, and SVO (Sparse Voxel Octree) construction and rendering. Each stage is logically connected through a data flow pipeline.

[0024] Preprocessing stage: This stage aims to analyze, detect, and perform preliminary optimization on the input heterogeneous 3D models.

[0025] It adopts a multi-parser collaborative architecture (FBX parser) to handle complex node levels (supporting 10 levels of nesting), and has a material conversion rule library with 200+ preset mappings.

[0026] Voxelization conversion stage: An adaptive resolution strategy is employed to convert polygonal meshes into voxel representations. Nested encoding allows the use of voxels of different precision in different regions, optimizing storage space while preserving detail. The code is as follows: def dynamic_voxelization(mesh,max_depth=10): for level in range(max_depth): threshold = 0.2 * (0.8 ** level) if mesh.complexity(level) <threshold: break with ThreadPoolExecutor()as executor: executor.submit(mesh.subdivide,level) return mesh.to_svo(sparse=True) SVO build and rendering phase: We developed a cross-platform PBR rendering pipeline that is compatible with the three major engines: Unity, Unreal Engine, and WebGL, and achieved physically based lighting consistency calibration, making visual differences between multiple platforms imperceptible.

[0027] Organizing voxel data using an octree structure enables efficient storage and retrieval. Nested encoding is particularly suitable for handling the irregular distribution characteristics of 3D point cloud data, effectively solving the problem of information loss that may occur when traditional methods process sparse regions.

[0028] Table 1 shows a comparison of the technical specifications of the present invention with those of the prior art.

[0029] Table 1. Technical Specifications of the Invention and Prior Art Example 2 like Figures 1 to 4 As shown, based on Example 1, this example provides a more detailed implementation method.

[0030] like Figure 1 As shown, this solution mainly consists of three stages: preprocessing, voxelization conversion, and SVO construction and rendering. Each stage is logically progressive and connected through a data flow pipeline. The specific implementation steps of each stage are described below.

[0031] The main approach employs Nested Voxel Encoding, which uses a hierarchical voxel structure to address compatibility issues between different 3D model formats. Traditional 3D model formats such as FBX and OBJ are converted into a Sparse Voxel Octree (SVO) structure, enabling unified data representation and processing.

[0032] 1.1. Preprocessing stage like Figure 2 As shown, the preprocessing stage involves the following steps: Step 1: 3D Model Analysis Collect device data (device data refers to the attribute data of the device with a 3D model, such as sensor values, location, and model) and POI data (Point of Interest, POI data refers to the geospatial data of the location points of the device with a 3D model that have specific significance or attractiveness, such as geographic semantics and temporal patterns), and use spatiotemporal feature encoding to unify the data format and coordinate system.

[0033] Spatial encoding: GeoHash is used to convert latitude and longitude into discrete indexes, which facilitates graph construction.

[0034] Temporal coding: Decompose time into dimensions such as year, month, day, and hour, and encode them into multi-dimensional feature vectors.

[0035] Attribute encoding: Normalize the static attributes of the device / POI and convert them into a fixed-length feature vector.

[0036] Step 2: Format Detection Supports automatic recognition of multiple formats including FBX / OBJ / GLTF, and adopts a hybrid parsing architecture (XML Schema + binary stream): 1) Hybrid parsing architecture parsing mechanism: The XML Schema layer defines the legality rules of the data structure, including element types (such as xs:string, xs:date), constraints (such as... <xs:minlength>The binary stream layer directly processes non-text or large-volume data (such as images and models) and their nesting relationships. It transmits data in raw byte form, avoiding the overhead of text encoding.

[0037] 2) Hybrid parsing architecture workflow: Metadata validation: XML Schema first validates the data description file (such as configuration information) to ensure that the field types, order, etc. conform to the specifications.

[0038] Binary data processing: Actual data (such as audio streams) is transmitted via binary streams, and binary content is embedded in XML using types such as base64Binary.

[0039] Dynamic binding: Hybrid parsers (such as GML DOM parsers) dynamically load XML fragments via event iterators (such as XMLEventReader) while processing binary data locally.

[0040] Average recognition accuracy: 99.3% (test dataset with 10,000+ models) Step 3: Geometry / Material Separation This step is one of the core innovations in the preprocessing stage, aiming to decouple the tightly coupled geometric, material, and animation data in the 3D model. This lays the foundation for subsequent independent optimization, efficient conversion, and cross-engine compatibility. Traditional 3D model formats typically store these data together, leading to rigid processing and low conversion efficiency. This method's decoupling process enables parallel pipelined operations, significantly improving processing efficiency and reliability. The decoupling process mainly separates the following three types of data: Static geometry data includes information that constitutes the basic shape of the model, such as vertex positions, normal vectors, texture coordinates (UV), and patch indices.

[0041] Material and texture data: including texture image paths or data such as diffuse maps, normal maps, and roughness maps, as well as the PBR parameters of the material itself.

[0042] Skeletal animation data includes bone hierarchy, bone weights, rigging pose matrix, and keyframe animation sequence. The final skeletal animation data separation latency is <8ms.

[0043] Processing the core architecture: from concurrent.futures import ThreadPoolExecutor def parse_func(component_type): return f"Parsed {component_type}" def separate_components(model): with ThreadPoolExecutor(max_workers=3) as pool: geo, mat, anim = pool.map( lambda x: parse_func(x), ['geometry','material','animation'] ) return geo, mat, anim Step 4: Animation Unpacking Animation unpacking is the process of converting continuous animation data embedded in a model into lightweight, easily transferable and replayable discrete keyframe data across engines. This method employs an intelligent keyframe extraction algorithm based on adaptive Bézier curve fitting, achieving a lossless compression ratio of up to 5:1 while maintaining visual losslessness (accuracy of 0.01 frames). The core idea of ​​this algorithm is to perfectly recreate the original animation curve by connecting as few keyframes as possible using high-precision Bézier curves. The process is an iterative "sampling-analysis-fitting-optimization" process, with the specific steps as follows: Step 1: Data Preprocessing and Noise Reduction Input: Raw, high-frequency sampled animation sequence data (typically one sample per frame).

[0044] Noise reduction filtering: Apply a low-pass filter (such as a Gaussian filter) to the original animation curves (including position, rotation, and scaling) to eliminate minor jitters or noise that may occur during animation production, providing a smooth baseline for subsequent curve fitting.

[0045] Step 2: Feature Frame Recognition Curvature Extremum Detection: Calculate the mathematical curvature (or approximate it using the first and second derivatives) at each time point on the denoised curve. Mark the local maxima and minima of all curvature. These points typically correspond to inflection points in the direction of motion in the animation, such as the highest and lowest points of a swinging animation.

[0046] Motion start and stop point detection: Identifies points where the speed approaches zero, i.e. the instants at which motion begins (from stillness to motion) and ends (from motion to stillness).

[0047] User-defined frame retention: Forces the retention of all keyframes explicitly marked by the animator in the raw data to ensure the integrity of the artistic intent.

[0048] Step 3: Adaptive Bézier curve fitting This is the core innovation of the algorithm. Instead of performing simple linear or spline interpolation between fixed keyframes, the system dynamically constructs Bézier curve segments that best represent the original data.

[0049] Initialize segmentation: Use all feature frames identified in the previous step as initial segmentation points.

[0050] Piecewise fitting: For each segment of data between two adjacent keyframes P0 and P3: Use the least squares method to find the two optimal control points P1 and P2, so that the error between the cubic Bézier curve defined by P0, P1, P2, and P3 and the original data points is minimized.

[0051] Error calculation: Calculate the root mean square value of all errors between the fitted curve and the original data points.

[0052] Iterative subdivision and optimization: If the error exceeds the threshold (e.g., 0.01 frames): it indicates that the current segment fitting accuracy is insufficient. The system will insert a new keyframe at the point with the largest error within this segment, then divide the segment into two, and repeat the fitting process of step 3 for each of the two new sub-segments.

[0053] If the error is less than or equal to the threshold, it means that the Bézier curve of the current segment has accurately reproduced the original animation. The segment and its keyframes P0 and P3 and control points P1 and P2 are retained.

[0054] Step 4: Data Compression and Serialization After the above steps, the original thousands of data points are compressed into a small number of keyframes and corresponding Bezier control points.

[0055] Keyframe data: Stores the timestamp of each keyframe and its transformation values ​​(position, rotation, scaling).

[0056] Control point data: Stores Bezier control point information used to define inter-segment transitions.

[0057] Special handling for rotation: Rotation data is represented using quaternions, and spherical linear interpolation is employed between keyframes. This algorithm maps Slerp parameters to the timing control of Bézier curves, ensuring the smoothness and accuracy of rotation animation.

[0058] Serialization: The final set of keyframes, control points, and curve type identifiers are serialized into a compact binary format, achieving a lossless compression ratio of 5:1. This provides a reliable data foundation for smooth and consistent animation playback across engines.

[0059] Step 5: GPU Preprocessing This step aims to offload computationally intensive model preprocessing tasks from the CPU to the GPU, leveraging its massively parallel architecture for extreme acceleration. Preprocessing primarily comprises two core tasks: vertex data processing and texture compression. Through carefully designed CUDA kernel functions, efficient memory management, and a pipelined execution model, this solution achieves outstanding performance with a 12x speedup in vertex processing and an 8x speedup in texture compression.

[0060] Specific implementation steps: 1.1 Vertex Processing Acceleration 1.1.1 Data Preparation and Transmission On the CPU side, the extracted vertex data (position, normal, UV, etc.) is organized into a continuous array (SoA - Structure of Arrays).

[0061] Use CUDA APIs (such as cudaMalloc) to allocate the corresponding buffer in GPU memory.

[0062] cudaMemcpy is used to asynchronously copy vertex data from host memory to GPU memory, overlapping with computation tasks to hide transmission latency.

[0063] 1.1.2 Parallel Kernel Function Design and Execution The core idea is to map the processing task of each vertex to an independent CUDA thread, thereby achieving fully parallel processing of massive vertex data.

[0064] Kernel function example: Vertex transformation and attribute calculation __global__ void vertexProcessingKernel(float3* positions, float3*normals, float2* uvs, Matrix4x4 transformMatrix, int vertexCount) { / / Calculate the vertex indices processed by the current thread int idx = blockIdx.x * blockDim.x + threadIdx.x; if (idx>= vertexCount) return; / / Boundary check / / 1. Coordinate space transformation: Transform vertices from model space to a unified world space. positions[idx] = matrixVectorMultiply(transformMatrix, positions[idx]); / / 2. Normal vector transformation and normalization (requires the inverse of the transformation matrix) normals[idx] = normalize(matrixVectorMultiply(transformMatrixInverseTranspose, normals[idx])); / / 3. Vertex data optimization: For example, clamping UV coordinates within the range of [0,1] to prevent sampling overflow. uvs[idx].x = fmodf(uvs[idx].x, 1.0f); uvs[idx].y = fmodf(uvs[idx].y, 1.0f); } Execution configuration: Depending on the number of vertices, launch thousands of thread blocks, each containing 256 or 512 threads, to ensure that the GPU computing units are fully utilized.

[0065] 1.1.3 Optimization Strategy Merging memory accesses: This ensures that adjacent threads access adjacent memory addresses in the GPU memory, thereby merging memory accesses and greatly improving memory bandwidth utilization.

[0066] Use shared memory: Frequently accessed constant data (such as transformation matrices) is cached in thread block shared memory to reduce the latency of accessing global video memory.

[0067] 1.2 Texture Compression Acceleration The goal is to convert high-resolution raw textures (such as PNG, TGA) into GPU-friendly block compression formats (such as BC7, BC6H, ASTC) in real time, significantly reducing memory usage and bandwidth consumption.

[0068] The bottleneck of traditional solutions is that they rely on the CPU to perform complex image compression algorithms, which is extremely slow, or the CPU performs software decoding while the engine is running, which consumes a lot of CPU resources.

[0069] Specific steps for accelerating texture compression: 1.2.1 Data Preparation and Transmission On the CPU side, the unpacked texture data is decoded into standard RGBA 8-bit / channel or HDR format, and the complete texture data is copied to the GPU memory.

[0070] 1.2.2 Parallel Kernel Function Design and Execution Core idea: The texture image is divided into non-overlapping pixel blocks (e.g., 4x4 blocks in BC7 format), and each CUDA thread block is responsible for compressing one or more pixel blocks.

[0071] Kernel function execution flow: Step 1: Block loading: Each thread loads the 4x4 RGBA pixel block it is responsible for from the global video memory into the shared memory.

[0072] Step 2: Color Space Analysis: Thread collaboration within the thread block to analyze the color distribution, brightness, and alpha channel characteristics of the pixel block.

[0073] Step 3: Mode selection and endpoint fitting: Try multiple compression modes in parallel (such as the 8 modes of BC7) to find the optimal compression parameters (such as color endpoints and index assignment) for the current pixel block.

[0074] Step 4: Block data writing: Write the calculated compressed data (a 64-bit or 128-bit codeword) into the output buffer in the video memory.

[0075] Kernel function example: BC7 compression kernel __global__ void textureCompressionBC7Kernel(uchar4* inputImage,uint64_t* outputBlocks, int width, int height) { / / Calculate the coordinates of the image patch that the current thread block is responsible for processing int blockX = blockIdx.x * 4; int blockY = blockIdx.y * 4; / / Declare shared memory to store a 4x4 pixel block __shared__ uchar4 sharedBlock[4][4]; / / Cooperative loading: Each thread loads one pixel into shared memory loadBlockToSharedMemory(inputImage, sharedBlock, width, height,blockX, blockY); __syncthreads(); / / Ensure all pixels have finished loading / / Collaborative computing: Analyzing sharedBlocks to find the optimal BC7 compression mode and parameters BC7CompressionConfig bestConfig = findBestBC7Mode(sharedBlock); / / Encode the optimal configuration into a 64-bit BC7 codeword uint64_t compressedBlock = encodeBC7Block(bestConfig); / / Write the compressed block to global video memory int outputIndex = blockIdx.y * gridDim.x + blockIdx.x; outputBlocks[outputIndex] = compressedBlock; } The CUDA acceleration optimization effect is shown in Table 2.

[0076] Table 2 CUDA Acceleration Optimization Effect Table Through the meticulously designed CUDA parallel computing scheme described above, preprocessing tasks that originally took several seconds or even tens of seconds to complete on the CPU can be completed on the GPU at a sub-second speed, providing a key guarantee for the real-time performance of the entire normalization processing flow.

[0077] Step Six: Voxelization Process This stage employs an adaptive resolution strategy to convert polygonal meshes into voxel representations.

[0078] A four-stage automated production line is used for processing: 1. Curvature Analysis Layer (CPU + OpenMP): Gaussian curvature calculation is performed using parallel computing with CPU and OpenMP (8 threads), and a configurable complexity threshold is set.

[0079] Implementation steps: 1. Data partitioning: Distribute the model's vertex or face list roughly evenly across multiple computational tasks.

[0080] 2. Parallel Curvature Calculation: Each thread is responsible for curvature calculation within a partition. For each vertex, the Gaussian curvature of that point is calculated using a local triangular mesh formed by its adjacent vertices, either through the angle defect method or local surface fitting. The Gaussian curvature reflects the inherent curvature of the surface at that point (e.g., high curvature at sharp corners and near-zero curvature at flat areas).

[0081] 3. Curvature normalization: Map the calculated original curvature values ​​to a uniform range (e.g., 0.0 to 1.0) to facilitate setting a uniform threshold.

[0082] 4. Complexity Labeling: Based on a preset configurable complexity threshold (e.g., 0.15-0.25), the model region is labeled as "high detail region" (curvature > threshold) or "low detail region" (curvature ≤ threshold). This threshold can be adjusted according to the target voxelization quality and performance requirements.

[0083] 2. Resolution Decision Layer (FPGA Acceleration): FPGA acceleration algorithm flow: [Input Mesh] → [Curvature Sampling] → [Density Prediction] → [Output Voxel Size] 1. Input Mesh and Curvature Data Stream: Input the spatial bounding box of the mesh and the curvature map data stream generated in step 601 into the FPGA.

[0084] 2. Curvature Sampling: The logic units inside the FPGA perform uniform or adaptive sampling of the input three-dimensional space. For each sampling point, the curvature value of that point is quickly determined by searching for neighboring curvature data.

[0085] 3. Density Prediction: A hardwired prediction module directly calculates the required voxel density for the region based on the curvature values ​​of the sampling points using a predefined (or programmable) mapping function.

[0086] 4. Output Voxel Size: The prediction results (i.e., the voxel sizes assigned to different spatial regions) are organized into a lookup table or a 3D texture and directly output to the next stage. The parallel architecture of the FPGA allows thousands of sampling points to perform this decision-making process simultaneously, achieving extremely high throughput and microsecond-level latency.

[0087] 3. Voxel generation layer (CUDA parallel): This step is the "executor" of the adaptive strategy, responsible for converting the triangular mesh into voxel data based on the voxel size map output by the decision layer. The goal is to efficiently and accurately "fill" each triangle into the 3D voxel mesh.

[0088] Specific implementation steps: 1. Task Assignment: Distribute the model's triangle list to a large number of CUDA threads. Typically, a thread block processes a set of triangles, and a single thread processes one or more triangles.

[0089] 2. Parallel voxelization kernel function: Core logic: Each thread is responsible for one triangle.

[0090] Step 1: Determine the area of ​​influence. Calculate the 3D bounding box of the triangle.

[0091] Step 2: Query local voxel dimensions. Based on the center or vertex coordinates of the bounding box, query the voxel dimension map generated in step 602 to determine the voxel size to be used in this region.

[0092] Step 3: Traversal and Testing. The thread traverses all voxels of the specified size within the bounding box, using efficient ray intersection or voxelization algorithms based on conservative rasterization to determine whether the voxel center is inside the triangle or sufficiently close to its surface.

[0093] Step 4: Mark voxels. If they intersect or are inside each other, mark them as "occupied" in the global voxel marker array at their position coordinates.

[0094] 4. Octree compression algorithm: This step transforms the typically dense and redundant voxel data generated by the voxel generation layer into a sparse, efficient, and easily queryable data structure. While ensuring data integrity, it achieves significant storage optimization and query acceleration, reaching an average query efficiency of 3.2 accesses per voxel.

[0095] 4.1 Specific Implementation Steps of Octree Compression Step 1: Voxel data sparsification Input: A 3D dense Boolean mesh output from the voxel generation layer, indicating whether each voxel is occupied.

[0096] Sparse list generation: Traverse the entire mesh, collecting only the 3D coordinates (x, y, z) of occupied voxels to form a sparse list of voxel coordinates. This step removes all empty voxels and is a prerequisite for compression.

[0097] Step 2: 3D Morton encoding (Z-order curve encoding) The core idea is to interweave and encode three-dimensional coordinates (x, y, z) into a one-dimensional Morton code (or Z code), so that spatially adjacent voxels are as close as possible in the encoded linear sequence.

[0098] Encoding method: Represent each coordinate x, y, z in a fixed-bit binary form (e.g., 21 bits, with an addressable space of 2^21 ≈ 2 million).

[0099] By manipulating bits, these binary bits are interleaved to form a new 64-bit integer. For example, the Morton code M for a coordinate (x, y, z) can be calculated as follows: M = ... | (z1<<2) | (y1<<1) | (x1) | (z0<<2) | (y0<<1) | (x0) (where the subscripts indicate the positions of the binary bits).

[0100] Advantages: Spatial locality: It preserves the positional relationships in three-dimensional space, which is beneficial for subsequent octree construction and range queries.

[0101] Computationally efficient: Modern CPUs typically provide dedicated instructions (such as Intel's PDEP / PEXT) to accelerate this computation.

[0102] Step 3: Morton code sorting For all voxels in the sparse voxel list, sort them in ascending order according to their calculated Morton codes. The sorted list will then have voxels arranged linearly in memory according to a Z-order curve.

[0103] Step 4: Recursively construct a sparse voxel octree (SVO) The core of the algorithm is to treat the entire 3D space as the root node and then recursively divide it into 8 sub-cubes (quadrases) of equal size until each leaf node contains only one voxel or is empty.

[0104] Construction process (based on a sorted list of Morton codes): Initialization: Create a root node that represents the entire space.

[0105] Recursive partitioning: For the current node, the Morton code range of all its possible child nodes can be determined based on its spatial range.

[0106] Traverse the sorted list of voxels and divide the voxels into the corresponding 8 sub-quadrants according to the Morton code.

[0107] Key optimization: Since the list is sorted by Morton code, voxels belonging to the same child node are distributed contiguously in the list. This allows us to quickly complete the partitioning using efficient binary search or direct pointer movement, without having to perform repeated spatial checks for each voxel.

[0108] Node creation: If a octet contains at least one voxel, then create a corresponding child node for the current node and recursively perform step 2 on that child node.

[0109] If there are no voxels in a gestalt, the pointer of that child node is null, thus achieving space sparsity.

[0110] Termination condition: When a node contains only one voxel, or when the node reaches the minimum voxel size, create a leaf node and store the voxel information (such as the material index).

[0111] Step 5: Pointer Compression and Storage Optimization The problem with traditional pointers: In a 64-bit system, a pointer occupies 8 bytes. For an octree with N nodes, the pointer overhead alone is enormous.

[0112] 3D Morton encoding compression pointer: We no longer store traditional 64-bit memory pointers.

[0113] For each non-leaf node, we store a child node existence mask (1 byte, 8 bits, each bit indicating whether a quaternion has a child node) and a base offset pointing to the array of child nodes.

[0114] Since child nodes are stored contiguously in memory (thanks to Morton sorting), the actual memory address of any child node can be calculated immediately using the base address offset and the position of "1" in the mask (PopCount).

[0115] Storage Structure: Ultimately, the entire octree is stored as a tightly packed array of nodes, with each node containing only: an existence mask (8 bits), an attribute pointer / index, and the offset of the child node array base address. This reduces storage overhead by more than 80% compared to traditional tree structures.

[0116] Step 6: Efficient Query Mechanism Query process: Given a 3D coordinate system (x, y, z): Calculate the Morton code M_query for this coordinate.

[0117] Starting from the root node, determine which sub-quadrant child_index to proceed to next based on the 3 bits corresponding to the depth of M_query in the current node.

[0118] Check the existence mask of the current node and determine if the child_index bit is 1.

[0119] If the value is 1, the memory address of the child node is calculated immediately using the pointer compression formula described above, and a jump is initiated.

[0120] Repeat steps 2-4 until a leaf node is reached or the path is found to be non-existent (mask is 0).

[0121] Efficiency Analysis: Since the depth of the octree is fixed (e.g., 10 for a 1024^3 grid), and each query involves simple bitwise operations and direct memory access, querying a voxel requires an average of only 3.2 node accesses. This superior performance is due to the spatial locality provided by Morton encoding, which makes it highly likely that nodes along the query path have already been cached in memory.

[0122] def build_octree(voxels): root = OctreeNode() for v in voxels: current = root for _ inrange(8): ifnotcurrent.children: current.children = [None]*8 current = current.children[v.pos&0x7] return root Step 7: SVO Build and Render Phase like Figure 3 As shown, this stage transforms unified voxel data into a dynamic 3D scene that can be efficiently rendered and interacted with, and solves the final rendering problem across engines.

[0123] Dynamic building and updating Core task: To convert static SVOs into dynamic scene graphs that can respond to real-time data changes.

[0124] Data processing: 1. Input: Static sparse voxel octree (SVO), real-time device / POI data stream, etc.

[0125] 2. Handling: 1) Use a sparse matrix to store the spatial adjacency relationships (such as distance and connectivity) between devices / POIs. 2) Establish an incremental update mechanism: when the device state or POI attributes change, only the SVO nodes of the affected local area are recalculated and updated, rather than rebuilding the entire tree.

[0126] 3. Output: Dynamically updated SVO scene graph.

[0127] Data flow: Real-time data stream → Sparse adjacency matrix → Incremental update algorithm → Dynamic SVO.

[0128] Spatiotemporal feature aggregation 1. Input: The dynamic adjacency matrix, static attribute feature vectors of devices / POIs, and dynamic state data output above.

[0129] 2. Aggregation Engine: Employs Dynamic Graph Convolutional Network (DGCNN) as the core computational model. Devices and Points of Interest (POIs) are treated as graph nodes, and the adjacency matrix defines the connection relationships between these nodes.

[0130] 3. Feature Calculation: Each node uses its attribute features (such as device type, sensor value, POI category) as its initial feature vector.

[0131] DGCNN uses multi-layer graph convolution operations to aggregate the feature information of its neighboring nodes for each node. This process ensures that the final feature of a node not only contains its own information, but also the semantic information of its local spatial context (e.g., calculating the average temperature of devices in the region, identifying clusters of high-energy-consuming devices).

[0132] 4. Output: Generates a set of aggregated node feature vectors. These vectors encode rich spatiotemporal semantic information to drive the dynamic changes of visualization attributes.

[0133] 3D scene annotation Based on the spatial location of the device / POI, create corresponding geometries (such as spheres and cubes) in the 3D scene. Set initial color, size, and transparency for each labeled object to reflect its basic attributes. Update the color, size, and transparency of labeled objects in real time based on spatiotemporal feature aggregation results. Transform abstract data and aggregated features into intuitive 3D graphical elements.

[0134] Data processing and flow: Input: Input the spatial coordinates of the device / POI output from the above steps, and the aggregated node feature vector.

[0135] Geometry instantiation: The system dynamically creates corresponding geometries at the corresponding spatial locations of devices / POIs in a 3D scene based on a preset geometry generation strategy. For example, a device is instantiated as a textured hexahedron model, and a POI is instantiated as a cluster of spheres controlled by LOD (Level of Detail) technology.

[0136] Dynamic property mapping: The aggregated feature vector output after spatiotemporal feature aggregation is passed to the shader program of the rendering engine in real time.

[0137] Color: Based on specific characteristic values ​​(such as device load rate), it is converted into intuitive colors (such as from blue to red) through the HSL spatial brightness mapping function.

[0138] Transparency: Based on the age of the data, an exponential decay curve is applied to achieve a gradual fading effect.

[0139] Size: Dynamically scaled based on device status (e.g., online / offline) or importance metrics.

[0140] Heatmap rendering: For regional morphology, a heatmap is dynamically rendered using a fragment shader. The shader receives spatial location density information and aggregated feature values, calculates the color of each pixel in real time on the GPU, and generates a smooth heatmap.

[0141] Dynamic attribute updates Color: HSL space brightness mapping Transparency: Exponential Decline Curve Size: Scaling based on device state Unified interactive API communication interface Protocol normalization: Unify WebSocket / gRPC / RESTful into the existing GraphQL over HTTP / 2 protocol.

[0142] Data standardization: All data interfaces are defined using AVRO Schema.

[0143] Unified authentication: JWT token system based on OAuth 2.1 (used for stateless authentication and authorization in microservice architecture, implementing cross-domain authentication and access control through standard protocols).

[0144] Adapter package like Figure 4 As shown, coordinate system transformations include left-handed to right-handed coordinate system transformation and Y-axis to Z-axis transformation; automatic transformations are performed between an internal unified coordinate system (such as the Y-Up right-handed coordinate system) and an engine-specific coordinate system (such as Unreal Engine's Z-Up left-handed coordinate system).

[0145] Material format standardization: PBR parameters are standardized; An adaptation layer is written for each engine to handle compatibility issues such as differences in data format, coordinate system transformation, and material differences.

[0146] Data flow direction: The adapter receives unified assets from the resource pool and generic instructions from the instruction converter, and outputs engine-native resource objects and API calls.

[0147] Unified resource management Establish a cross-engine resource pool (raw textures and model assets are converted and stored in an intermediate format once. When the engine needs them, the resource pool converts them to the specific format required by the target engine on demand (such as converting textures to Unity's Texture2D or Unreal's UTexture2D), and is responsible for caching and lifecycle management), and maps the internal standard PBR material parameters to engine-specific material node graphs or shader code.

[0148] Data flow: The adapter receives unified assets from the resource pool and general instructions from the instruction converter, and outputs the engine's native resource objects and API calls.

[0149] This solution effectively addresses the compatibility issues between multi-engine resources and APIs in the digital twin field through innovative voxel encoding and a unified rendering pipeline, providing a standardized solution for cross-platform visualization applications.

[0150] This invention is the first to achieve unified rendering across three engines, solving the material compatibility problem between Unity / Unreal / WebGL by converting model data of different formats through the SVO structure.

[0151] This invention achieves a breakthrough in industrial-grade processing performance. The FPGA+GPU heterogeneous computing architecture reduces the processing time for million-facet models from minutes to seconds.

[0152] The present invention provides a dynamic annotation and visualization system with an innovative spatiotemporal feature aggregation algorithm that supports real-time attribute mapping (update latency <100ms).

[0153] As described above, the present invention can be implemented well.

[0154] All features disclosed in all embodiments of this specification, or steps in all methods or processes implied in the disclosure, may be combined and / or extended or replaced in any way, except for mutually exclusive features and / or steps.

[0155] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Based on the technical essence of the present invention, any simple modifications, equivalent substitutions, and improvements made to the above embodiments within the spirit and principles of the present invention shall still fall within the protection scope of the present invention.< / xs:minlength>

Claims

1. An engine data normalization processing method characterized by comprising: The method comprises the following steps: The input heterogeneous 3D model is parsed through the XML Schema and binary stream mixed architecture to generate a 3D model in a unified format; wherein the heterogeneous 3D model comprises engine data in two or more formats; The engine data in the 3D model in the unified format is subjected to data partitioning according to resolution, so that the engine data in different data partitions has different resolution intervals, the engine data in different data partitions is converted into different voxel data representations, and a static octree structure is generated; When the engine data in the static octree structure changes, the octree nodes in the engine data change area are recalculated and updated using the spatial adjacency relationship between the engine data in the static octree structure, and the static octree structure is converted into a dynamically updated octree structure.

2. The engine data normalization method of claim 1, wherein, The input heterogeneous 3D model is parsed through the XML Schema and binary stream mixed architecture to generate a 3D model in a unified format, comprising the following steps: Collect device data and POI data, use spatial feature coding to convert latitude and longitude into discrete indexes, encode time into a multi-dimensional feature vector, and normalize the static attributes of the device data and POI data to obtain a fixed-length feature vector; The legality rules of the data structure of the engine data are defined by using XML Schema, and non-text data or text data with a capacity greater than a set threshold are directly processed by using binary stream and transmitted in byte form; wherein the legality rules include one or more of the following: element type, constraint, and nesting relationship; The coupled geometry information, material information, and animation data in the 3D model are decoupled; The continuous animation data embedded in the 3D model is converted into discrete keyframe data; The 3D model preprocessing task is offloaded from the CPU to the GPU.

3. The engine data normalization method of claim 2, wherein The continuous animation data embedded in the 3D model is converted into discrete keyframe data, comprising the following steps: Initialization segmentation: segment the continuous animation data with all feature frames as initial segmentation points; Segment fitting: for each segment of data between two adjacent keyframes P0 and P3, find the optimal two control points P1 and P2 using the least squares method, so that the error between the cubic Bezier curve defined by P0, P1, P2, P3 and the original data points is minimized; Error calculation: calculate the root mean square value of all errors between the fitted curve and the original data points; Iterative subdivision and optimization: If the error > set threshold, a new keyframe is inserted at the point with the maximum error in the segmentation between P0 and P3, then the data in the segmentation between P0 and P3 is divided into two new sub-segments, and the segment fitting is repeated for the two new sub-segments; If the error <= set threshold: the segmentation between P0 and P3 and the keyframes P0, P3 and control points P1, P2 are retained.

4. The engine data normalization method of claim 2, wherein, When the 3D model preprocessing task is offloaded from the CPU to the GPU, vertex processing acceleration is performed, comprising the following steps: The extracted vertex data is allocated a corresponding buffer in the GPU memory using the CUDA interface at the CPU end, and the vertex data is asynchronously copied from the host memory to the GPU memory using the cudaMemcpy function; Map each vertex processing task to an independent CUDA thread to achieve parallel processing of vertex data.

5. The method of claim 2, wherein When offloading the 3D model preprocessing task from the CPU to the GPU, perform texture compression acceleration to convert the original texture into a block compression format in real time, including the following steps: Decode the unpacked texture data at the CPU end and copy the decoded texture data to the GPU memory; Each thread block loads a pixel block from the global memory into the shared memory; Threads within the thread block analyze the color distribution, brightness, and Alpha channel characteristics of the pixel block; Threads attempt multiple compression modes in parallel to find the optimal compression parameters for the current pixel block; Write the optimal compression parameters to the output buffer in the memory.

6. The method of claim 1 to 5, wherein, Divide the engine data in the uniform format 3D model into data partitions according to the resolution, so that the engine data in different data partitions have different resolution intervals, convert the engine data in different data partitions into different voxel data representations, and generate a static octree structure, including the following steps: Use CPU and OpenMP parallelism to calculate the Gaussian curvature of the vertices; Stream the spatial bounding box and curvature map data of the mesh into the FPGA, and the FPGA samples the curvature of the input three-dimensional space, calculates the required voxel density through a predefined or programmable mapping function, obtains the voxel size assigned to different spatial regions, and outputs as a lookup table or three-dimensional texture; Convert the contents of the lookup table or three-dimensional texture into voxel data and fill it into the three-dimensional voxel grid; Use the octree compression algorithm to convert the voxel data in the three-dimensional voxel grid into a data structure.

7. The method of claim 6, wherein Using the octree compression algorithm to convert the voxel data in the three-dimensional voxel grid into a data structure includes the following steps: The three-dimensional Boolean grid output by the voxel generation layer marks whether each voxel is occupied; traverse the entire three-dimensional Boolean grid to form a voxel coordinate list of occupied voxels; Interleave the three-dimensional coordinates into a one-dimensional Morton code; Sort all voxels in the voxel list in ascending order based on the Morton code. In the sorted list, voxels are linearly arranged in memory according to the Z-order curve; Treat the entire three-dimensional Boolean grid as a root node, and then recursively divide the three-dimensional Boolean grid into 8 equal-sized child cubes until each leaf node contains only one voxel or is empty.

8. The method of claim 1, wherein, When the engine data in the static octree structure changes, use the spatial adjacency relationship between the engine data in the static octree structure to recalculate and update the octree nodes in the engine data change area, convert the static octree structure into a dynamically updated octree structure, including the following steps: A dynamic graph convolutional network for spatio-temporal feature aggregation of attribute features in an octree structure for dynamic update is constructed, wherein the attribute features include one or more of the following: a static attribute feature vector of a device, a static attribute feature vector of a POI, dynamic state data of a device, dynamic state data of a POI, the attribute features being nodes of a graph, and a dynamic adjacency matrix defining the connection relationship of the graph nodes. The attribute features of each node are taken as initial feature vectors, and the dynamic graph convolutional network aggregates the feature information of the neighbor nodes of each node through multi-layer graph convolution operations to generate an aggregated node feature vector.

9. The method of claim 8, wherein, When the engine data in the static octree structure changes, the octree nodes in the engine data change area are recalculated and updated using the spatial adjacency relationship between the engine data in the static octree structure, and the static octree structure is converted into a dynamically updated octree structure, including the following steps: According to the spatial positions of the devices and / or POIs, geometric bodies corresponding to the devices and / or POIs are created in a three-dimensional scene, and each geometric body is set with an initial color, size, and transparency. According to the spatio-temporal feature aggregation results, the color, size, and transparency of the geometric body are updated in real time, and the spatial position and aggregated features are converted into three-dimensional graphical elements.

10. The method of claim 9, wherein, When the engine data in the static octree structure changes, the octree nodes in the engine data change area are recalculated and updated using the spatial adjacency relationship between the engine data in the static octree structure, and the static octree structure is converted into a dynamically updated octree structure, including the following steps: The output aggregated feature vector after spatio-temporal feature aggregation is transmitted to the shader program of the rendering engine in real time; The feature value is converted into a color through an HSL space brightness mapping function; Based on the device state or importance index, the geometric body is dynamically scaled to realize size conversion; An exponential decay curve is used to convert the new and old degree of data into transparency; The spatial position density information and aggregated feature value of the geometric body are received by a fragment shader, and the color of each pixel of the geometric body is calculated in real time on the GPU to generate a heat distribution map.

Images