A data processing method
Patent Information
- Application Number
- CN202610821193.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-08
- Publication Date
- 2026-09-01
Smart Images

Figure CN122673162A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer image processing technology, and more specifically, to a data processing method. Background Technology
[0002] In cross-platform transfer and online visualization applications of 3D digital assets, the processing and display of target proprietary format engineering files are involved. Related technologies typically require first importing the source file into its corresponding local modeling environment, exporting it into a universal cross-platform exchange format, and then having the client-side rendering engine load and visualize it; alternatively, the file can be uploaded to a network server, where the server performs format conversion and data extraction, and then sends the processing results to the front-end client for rendering and display. Summary of the Invention
[0003] In view of this, the purpose of this application is to provide a data processing method to overcome at least one of the above-mentioned defects.
[0004] In a first aspect, embodiments of this application provide a data processing method, including: In response to a display command for a target proprietary format project file, a script execution environment is loaded in the client. This script execution environment is used to run a pre-defined type of scripting language in the client. In the script execution environment, the original data at the bottom layer of the target private format project file to be displayed is extracted, and the original data is reconstructed into intermediate layer data; The intermediate layer data is dynamically mapped to the objects to be displayed that the rendering engine needs, so that the objects to be displayed can be rendered.
[0005] In an optional implementation, the step of extracting the underlying raw data of the target private format project file to be displayed and reconstructing the raw data into intermediate layer data in the script execution environment includes: using a binary parsing engine running in an independent thread to bypass the interface of the 3D modeling software corresponding to the target private format project file in a pure code manner, directly parsing the underlying data of the target private format project file to obtain the raw data carrying software specificity. The binary parsing engine is built based on a scripting language of a preset type.
[0006] In an optional implementation, the target private format project file is a first private format project file. The underlying data of the target private format project file is parsed in the following way to obtain the original data carrying software specificity: the directory structure corresponding to the first private format project file is parsed, and the data stream of a specified type in the directory structure is determined as the target data stream, which includes multiple data blocks; the data of the multiple data blocks is extracted to obtain the original data.
[0007] In an optional implementation, the step of extracting data from multiple data blocks to obtain the original data includes: for each data block in the target data stream, determining the type of the data block based on the class identifier and block identifier of the data block; and parsing the data block according to the parsing method corresponding to the data block type to obtain the original data.
[0008] In an optional implementation, the step of parsing the directory structure corresponding to the first private format project file and determining the data stream of a specified type in the directory structure as the target data stream includes: performing a validity check on the first private format project file; if the validity check passes, loading the directory structure and querying the data stream of a specified type from the directory structure as the target data stream.
[0009] In an optional implementation, the target private format project file is a second private format project file or a .mb format file. The target private format project file is parsed in the following way: target nodes of a preset type are selected from the node graph of the second private format project file; the node attributes of the target nodes are extracted, and the component list is standardized and mapped to obtain the original data.
[0010] In an optional implementation, the step of reconstructing the original data into intermediate data includes: standardizing and reconstructing the original data in a binary parsing engine to obtain intermediate data in JSON format.
[0011] In an optional implementation, the step of dynamically mapping intermediate layer data to objects to be displayed required by the rendering engine for rendering the objects to be displayed in the client includes: obtaining geometric and material information from the intermediate layer data; mapping the geometric information to geometric objects recognizable by the rendering engine; mapping the material information to physically based rendering (PBR) material parameters and constructing material objects based on the PBR material parameters; combining the geometric objects and material objects into objects to be displayed, assembling them hierarchically, and then displaying them in the client.
[0012] In an optional implementation, the step of combining geometric objects and material objects into objects to be displayed, assembling them hierarchically, and then displaying them on the client includes: adding all mesh nodes to the model group object according to the parent-child hierarchy to generate the objects to be displayed; determining the bounding box of the objects to be displayed, and determining the optimal viewing distance of the camera based on the bounding box.
[0013] In an optional implementation, after obtaining geometric and material information from the intermediate layer data, the method further includes: determining the span of the vertex bounding box of the mesh node in the intermediate layer data; and using a heuristic method to detect and correct the vertical axis of the mesh node based on the span.
[0014] The embodiments of this application bring the following beneficial effects: The data processing method provided in this application embodiment can directly parse 3D proprietary formats on the client side without relying on native software such as 3ds Max / Maya. It has the advantages of high processing efficiency, data security and easy architecture expansion. Compared with the data processing methods in the prior art, it solves the problems of heavy reliance on native 3D modeling software when displaying existing 3D proprietary format files, the inability of the client to directly preview 3D proprietary format files, and the low conversion efficiency of the server.
[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 A flowchart of the data processing method provided in an embodiment of this application is shown; Figure 2 A flowchart illustrating the steps for extracting raw data from a first proprietary format project file provided in this application embodiment is shown. Figure 3 A flowchart illustrating the steps for extracting raw data from a second proprietary format project file provided in this application embodiment is shown. Figure 4 A flowchart illustrating the steps for generating the object to be shown, as provided in an embodiment of this application, is shown. Figure 5 A schematic diagram of the structure of the data processing apparatus provided in an embodiment of this application is shown; Figure 6 A schematic diagram of the structure of the electronic device provided in the embodiments of this application is shown. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.
[0019] It is worth noting that prior to this application, mainstream 3D modeling software such as 3ds Max and Maya generally used proprietary formats (such as .max format) to store project files. These proprietary formats lack publicly available unified parsing standards and contain complex data structures such as hierarchical nodes, mesh data, material parameters, texture maps, and animation information. Their data organization and storage methods exhibit strong software-specific characteristics. This data closedness restricts the use of 3D digital assets to specific software ecosystems, making cross-platform and cross-software reuse difficult, significantly reducing cross-platform collaborative work efficiency and failing to meet the cross-platform circulation needs of 3D digital assets. Furthermore, 3D assets cannot achieve lightweight online preview and interactive operations directly outside of native modeling software environments. Currently, the industry mainly relies on two methods for previewing or converting proprietary 3D format files: one is to open the file locally using native software such as 3ds Max or Maya and export it to a universal format; the other is to upload the file to a server deploying the native software, convert it in the backend, and then distribute it to the frontend for display.
[0020] However, in the first method, browsers cannot natively read such private formats, and native previewing is not possible on the web, resulting in poor cross-software compatibility and hindering the circulation of digital assets. In the second method, confidential or unpublished 3D private format files need to be uploaded to the server, which poses a risk of digital asset leakage. Furthermore, the server-side conversion efficiency is low, resulting in poor real-time file processing.
[0021] The following explains the terms used in the embodiments of this application.
[0022] Object Linking and Embedding (OLE): A composite document storage format. In this article, it specifically refers to the underlying binary data storage structure of 3ds Max (.max) files.
[0023] Intermediate Representation (IR): In this application, it refers to a standardized JSON data structure used to uniformly store data extracted from different 3D software source files (such as meshes, materials, transformation matrices, etc.).
[0024] Pyodide: An open-source project for compiling the Python interpreter into WebAssembly (Wasm), enabling Python code to run directly in a web browser environment.
[0025] Web Worker: A multi-threaded mechanism provided by HTML5 that allows JavaScript to run in a background thread, enabling time-consuming tasks to be performed in the browser without blocking the main thread.
[0026] Three.js: A lightweight, cross-browser JavaScript 3D library for rendering 3D graphics on the web based on WebGL.
[0027] To facilitate understanding of this embodiment, the following description uses the data processing method provided in this application embodiment applied to a browser plugin as an example to illustrate the above exemplary steps provided in this application embodiment.
[0028] Please see Figure 1 , Figure 1 This is a flowchart illustrating a data processing method provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the data processing method includes: Step S101: In response to the display instruction for the target private format project file, load the script execution environment in the client.
[0029] Target proprietary format project files can refer to 3D files generated by professional 3D modeling software, which use a non-public, software-specific closed data structure for storage and have no unified public parsing standard. Target proprietary format project files include complete project information such as model mesh, materials, textures, node levels, and animations. For example, professional 3D modeling software can be 3ds Max or Maya.
[0030] The target proprietary format project file includes a first proprietary format project file and a second proprietary format project file. For example, the first proprietary format project file may refer to the target proprietary format project file corresponding to the 3D modeling software 3ds Max, such as a ".max" format file, and the second proprietary format project file may refer to the target proprietary format project file corresponding to the 3D modeling software Maya, such as a ".ma" format file and a ".mb" format file.
[0031] A display command can refer to an operation command triggered by a user to request the opening and rendering of a target proprietary format project file in the client. It is a trigger signal to start the file processing and rendering process. For example, a display command can refer to a command generated when a user drags and drops a target proprietary format project file to a preset location in the client plugin.
[0032] The script runtime environment is used to run a predefined type of scripting language on the client. For example, the script runtime environment can be the Pyodide environment (Wasm), and the predefined type of scripting language can refer to Python.
[0033] In this embodiment, after the user selects a target proprietary format project file on the client (browser), the client reads the target proprietary format project file as a native ArrayBuffer. Then, the main thread initializes a WebWorker, uses the WebWorker to create an independent thread within the client's main thread, and loads the script execution environment Pyodide in the independent thread. Once the script execution environment Pyodide is ready, the WebWorker writes the ArrayBuffer to its virtual WebAssembly memory file system (e.g., / tmp.max), and the WebWorker internally calls a pre-compiled binary parsing engine to parse the ArrayBuffer.
[0034] Step S102: In the script running environment, extract the original data of the underlying private format project file to be displayed, and reconstruct the original data into intermediate layer data.
[0035] Raw data can refer to software-specific data that is directly extracted from the underlying binary stream or node structure of the target proprietary format project file (such as a .max file) without standardization processing. Raw data includes native information such as mesh, vertices, faces, UVs, normals, materials, transformation matrices, and node levels.
[0036] In this embodiment of the application, before extracting the underlying raw data of the target private format project file to be displayed, a binary parsing engine can be built based on a preset type of scripting language and run in an independent thread. By using the binary parsing engine running in an independent thread, the API interface of the 3D modeling software corresponding to the target private format project file can be bypassed in a pure code manner, and the underlying data of the target private format project file can be directly parsed to obtain the raw data carrying software specificity.
[0037] The methods for extracting raw data from target proprietary format project files differ depending on their format. See below for reference. Figure 2 This section will introduce the process of extracting raw data from the first proprietary format project file.
[0038] Figure 2 A flowchart illustrating the steps for extracting raw data from a first proprietary format project file provided in this application embodiment is shown, such as... Figure 2 As shown, the steps for extracting the raw data from the first proprietary format project file include: Step S1021: Parse the directory structure corresponding to the first private format project file, and determine the data stream of the specified type in the directory structure as the target data stream.
[0039] The specified data stream type can refer to a Scene stream, and the target data stream includes multiple data blocks marked with block identifiers.
[0040] If the header signature of the first private format project file is valid, then the file allocation table and directory structure are loaded; the specified type of data stream is retrieved from the directory structure as the target data stream.
[0041] For example: First, the file header signature of the first proprietary format project file is read and verified to determine if it is a valid OLE file. The first proprietary format project file is essentially an OLE (Object Linking and Embedding) file. If the first proprietary format project file passes verification, the File Allocation Table (FAT) and directory structure are obtained. The directory structure within the OLE file is traversed to locate and read the Scene stream and the ClassDirectory. The Scene stream is used as the target data stream, and the starting block identifier and total size are extracted from the directory entries corresponding to the target data stream as the addressing basis for the target data stream.
[0042] Simultaneously, class identifiers (including Super ID and Class ID) are extracted from the ClassDirectory to determine which category a node belongs to: mesh, material, transformation, controller, or dummy. A node can refer to a basic building block in a 3D scene, including objects such as mesh, material, transformation, controller, and dummy.
[0043] The file allocation table records the number of the next data block for each data block, forming a complete chain of addresses between data blocks. The directory structure records the name, location, size, and attributes of all data streams and storage containers within the OLE file. It serves as the index entry point for the parser to locate the core data of the .max file. For example, it records that the Scene stream starts from data block N and occupies a total of M data blocks. The Super ID can refer to a major category identifier, such as Mesh, Material, Controller, or Layer. The Mesh class indicates that the referenced object belongs to the mesh / geometry category; the Material class indicates that the referenced object belongs to the material category; the Controller class indicates that the referenced object belongs to the transformation or animation controller category; and the Layer class indicates that the referenced object belongs to the layer or organizational structure category. The Class ID indicates the specific object type, such as: EDIT_MESH Editable Mesh, EDIT_POLY Editable Poly, POLY_MESH Polygonal Mesh, STANDARD_MTL Standard Material, PHYS_MTL Physical Material, SURF_MTL Surface Material, MULTI_MTL Multidimensional Submaterial, DUMMY Empty Node / Auxiliary Object, and BIPED_ANIMBiped Animation Controller.
[0044] Additionally, query the file allocation table to find all data blocks under the target data stream and determine the block identifier of each data block under the target data stream.
[0045] Step S1022: Extract data from multiple data blocks to obtain the original data.
[0046] For each data block in the target data stream, the type of the data block is determined based on its class identifier and block identifier; the data block is then recursively parsed according to the parsing method corresponding to its type to obtain the original data.
[0047] For example, since different types of data blocks have different data storage structures and parsing logics, it is necessary to first determine the type of each data block. Then, each data block in the target data stream is recursively traversed to extract the original data under each data block according to the corresponding parsing method. For example, for Mesh nodes, geometric data such as vertices, faces, UVs, and normals can be extracted based on the Chunk ID, and triangulation, coordinate system transformation, and geometric reconstruction can be performed. For Material nodes, rendering parameters such as diffuse reflection, metallicity, roughness, and texture paths can be extracted based on the Chunk ID, and PBR (Physically Based Rendering) normalization mapping can be performed. In this way, original data such as vertex arrays, face arrays, UV coordinates, UV face indices, material IDs, material parameters, texture paths, node names, parent-child hierarchy, positions, and rotations can be extracted from different types of data blocks.
[0048] Figure 3 A flowchart illustrating the steps for extracting raw data from a second proprietary format project file provided in this application embodiment is shown, such as... Figure 3 As shown, the steps for extracting the raw data from the second proprietary format project file include: Step S1023: Select target nodes of preset types from the node graph of the second private format project file.
[0049] The first proprietary format project file uses a binary block structure based on OLE compound documents for storage. Data types need to be identified and extracted recursively using ChunkID. The second proprietary format project file uses a Maya node graph model for storage. The ".ma" format file is an ASCII command stream, and the ".mb" format file is the corresponding binary compressed format. Both organize data with nodes and attributes as the core. Therefore, attributes can be extracted through syntax trees or node graphs. Nodes in the node graph form relationships through attribute connections.
[0050] For example: The process reads and parses the node graph corresponding to the second proprietary format project file to obtain the node list and attribute values. If the file is in ".ma" format, an AST syntax tree is directly constructed using MEL commands; if it is in ".mb" format, the node graph is reconstructed through binary deserialization. Target nodes needed for rendering, such as Mesh nodes, Material nodes, and Transform nodes, are then selected from the node graph.
[0051] Step S1024: Extract the node attributes of the target node and perform standardized mapping on the component list to obtain the raw data.
[0052] The component list can refer to the collection of abbreviations and keywords used internally by the 3D modeling software Maya to store elements such as vertices, faces, normals, UVs, and colors.
[0053] For example, for Mesh nodes, extract node attributes such as vertices, faces, UVs, normals, and colors; for Material nodes, extract node attributes such as diffuse reflection, metallicity, roughness, texture path, and transparency.
[0054] Additionally, because the 3D modeling software Maya stores data using abbreviated keywords, it's necessary to map these abbreviated keywords to standard fields to obtain the original data from the second proprietary format process file. For example, if `vt` is the abbreviated keyword for vertex, then `vt` is mapped to vertex coordinates; if `vc` is the abbreviated keyword for vertex color, then `vc` is mapped to vertex color.
[0055] In one embodiment, when reconstructing the original data into intermediate data, the original data can be standardized and reconstructed in a binary parsing engine to obtain intermediate data in JSON format.
[0056] Specifically, the extracted raw data is first cleaned and standardized. For example, each face's vertex index is checked for out-of-bounds errors, null values, duplicates, or invalid values, and invalid faces (such as invalid faces with fewer than 3 vertices) are removed. All UV layers are read from the raw data, retaining UV channels with actual data, non-null values, and dimensions matching the number of vertices, while removing empty channels, abnormal channels, and redundant plugin channels. Material indices are processed, such as reading face-level material IDs, filling in missing material IDs, and removing out-of-bounds material indices. The 3ds Max Z-up coordinate system is marked in the intermediate layer data; for 3ds Max files, the Z-axis is upward; for Maya files, the Y-axis is upward. Data in the raw data may contain Euler angles, quaternions, or rotation matrices; all are standardized to quaternions (x, y, z, w). Finally, material parameters are standardized to data fields usable by Three.js or PBR to generate intermediate layer data with a unified structure for direct use by the subsequent Web rendering module.
[0057] Step S103: Dynamically map the intermediate layer data to the object to be displayed required by the rendering engine, so as to render the object to be displayed.
[0058] The intermediate layer data is output by the binary parsing engine. The binary parsing engine ultimately outputs a very lightweight JSON structure of intermediate layer data, which includes, but is not limited to: an array of objects (including hierarchy, mesh vertex coordinates, UVs, normals, and sub-material indices), an array of materials (including diffuse, roughness, and texture paths), and stats (statistical information).
[0059] After reconstructing the original data into intermediate-layer data, the intermediate-layer data can be sent to the main thread for parsing. Once the main thread receives the intermediate-layer data from the Web Worker, it uses the Three.js adapter to build a 3D visualization scene.
[0060] The following reference Figure 4 Let's introduce the process of generating the object to be shown.
[0061] Figure 4 A flowchart illustrating the steps for generating the object to be demonstrated, as provided in an embodiment of this application, is shown. Figure 4 As shown, the steps for generating the object to be displayed include: Step S1031: Obtain geometric and material information from the intermediate layer data.
[0062] Geometric information includes, but is not limited to: vertex, face, and texture coordinates. Material information includes, but is not limited to: basic physical optical parameters, texture mapping paths, and multi-dimensional sub-materials. Among these, basic physical optical parameters include, but are not limited to: diffuse color, metallicity, roughness, and transparency.
[0063] Step S1032: Map the geometric information into geometric objects that the rendering engine can recognize.
[0064] Based on the geometric information extracted in step S1031, construct a geometric object, that is, construct a BufferGeometry object of Three.js.
[0065] Step S1033: Map the material information to physically based rendering (PBR) material parameters, and construct a material object based on the PBR material parameters.
[0066] Material information such as diffuse reflection, metallicity, roughness, transparency, self-illumination, and various texture paths is read from the intermediate layer data. The proprietary material parameters of different 3D modeling software are uniformly mapped to standard PBR physically based rendering fields, completing texture loading and channel binding. Then, a MeshStandardMaterial material object supported by the Three.js rendering engine is constructed based on the standardized PBR parameters.
[0067] Step S1034: Combine the geometric objects and material objects into objects to be displayed, assemble them hierarchically, and then display them in the client.
[0068] Bind the material object to the geometry (BufferGeometry) grouped according to the face-level material index to generate a mesh object. Add all mesh nodes to the model group object (modelGroup) according to the parent-child hierarchy to generate the object to be displayed. Then, determine the bounding box of the object to be displayed and determine the optimal viewing distance of the camera based on the bounding box.
[0069] The following section details the entire process of generating the object to be displayed.
[0070] The first step is to read the data: read the target fields from the intermediate layer data and extract geometric information from the target fields. Target fields include, but are not limited to: Objects, Materials, and stats.
[0071] The second step is to traverse the object data: process each object in the intermediate layer data one by one to determine whether the object is a grid node, an empty node, or an auxiliary node. If it is a grid node, proceed to the third step.
[0072] The third step is coordinate system determination: For each mesh node, the span of the vertex bounding box is traversed. Based on the span, a heuristic determination is made using the span of the vertex bounding box to confirm whether the mesh data was obtained from the first proprietary format project file or the second proprietary format project file, thus determining whether the mesh node needs a vertical axis transformation. If the vertical axis of the mesh node is Z-up, then the fourth step is executed; if the vertical axis of the mesh node is Y-up, then the mesh node is used directly without needing a vertical axis transformation.
[0073] For example: traverse all vertices of the grid nodes, calculate the minimum and maximum values in the X, Y, and Z directions respectively, and obtain the span in each of the three directions. For instance, the minimum value in the X direction is denoted as... The maximum value in the X direction is denoted as If the span in the X direction is spanX, then Then, the Up-Axis is inferred based on the span relationship between the Y-axis and the Z-axis. If the ratio of the span in the Y-direction to the model height direction is within a preset range, the data can be judged to be close to Y-up; if the ratio of the span in the Z-direction to the model height direction is within a preset range, the data can be judged to be Z-up. The fourth step is to construct the geometry object: read the vertex coordinates, face indices, UV coordinates, UV face indices, and material Ids from object.mesh, and construct the geometry object based on the vertex coordinates, face indices, UV coordinates, UV face indices, and material Ids.
[0074] Then, coordinate system transformation is performed: if the intermediate layer data comes from the first proprietary format project file, it is usually Z-up and needs to be converted to Y-up commonly used in Three.js or WebGL; if the intermediate layer data comes from the second proprietary format project file, it is usually Y-up, which is completely consistent with the Y-up coordinate system of the Three.js / WebGL standard, and no axial transformation is required, so it can be used directly.
[0075] Step 5: Face data cleaning and triangulation: If the face is a triangle, it is used directly; if the face is a quadrilateral, it is split into two triangles; if the face is a polygon, it is split into multiple triangles in a sector pattern to handle illegal faces, duplicate faces, and face reordering issues.
[0076] Step 6: Write UV and Material Groups: If UV data exists in the intermediate layer data, write the UV coordinates corresponding to each vertex into the uv property of the geometry object (BufferGeometry) according to the UV face index array (uvIndices). If face-level material indices (materialIds) exist, call the addGroup() function according to the material ID to group the triangles into face-level materials, and simultaneously call the geometry.addGroup function so that Three.js can use different sub-materials on different faces of the same mesh.
[0077] Step 7: Determine vertex normals: If the intermediate layer data does not provide normals, the vertex normals are calculated using the `geometry.computeVertexNormals()` function based on the face data, or generated using the `computeVertexNormals()` function from Three.js. For example, if normal information is missing in the intermediate layer data, the adapter dynamically calculates the face normals using the vector cross product method based on the face vertex indices, and uses the characteristic of adjacent faces sharing vertices to perform normal accumulation and normalization processing, achieving smooth shading and rendering of the model surface.
[0078] Step 8: Construct Material Objects: Based on the material data or multi-dimensional sub-materials in the intermediate layer data, construct the MeshStandardMaterial. The MeshStandardMaterial refers to the standard PBR material object built into the Three.js rendering engine. It is used to receive physically based rendering parameters that have been standardized and mapped. It can be constructed as a single material object (material array). After binding the material object with a geometry object (BufferGeometry), physically based optical rendering of the 3D model is achieved.
[0079] Step 9: Create the mesh: Combine the geometry object BufferGeometry and the material object Material into the Three.js Mesh object to be displayed.
[0080] Step 10: Apply Transform: Apply the position, rotation, and scale data from the intermediate layer data to the object to be displayed, and perform necessary transformations based on the coordinate system.
[0081] Step 11, Assemble the parent-child hierarchy: Based on the parent node name (parent), parent node identifier (parent Id), name (name) and other fields in the intermediate layer data, mount the object to be displayed or Object3D to the corresponding parent node. If there is no parent node, add the object to be displayed to the model group object (modelGroup).
[0082] Step 12, Scene Display: Add the model group object to the Three.js Scene, determine the bounding box of the model group object, determine the optimal viewing distance of the camera based on the bounding box, and start real-time rendering to achieve automatic centering and full display of the model after loading.
[0083] The data processing method provided in this application embodiment is based on a binary direct parsing method in a pure code environment (without 3ds Max / Maya environment), and combines WebAssembly technology to solve the problem of ultra-fast parsing and visualization rendering of target private format project files in a pure front-end environment, and has the following beneficial effects: First, the front-end local high-speed parsing significantly improves response speed and reduces server load: Based on Pyodide (WebAssembly), the entire client-side local parsing process is achieved, eliminating the need to upload 3D source files to the server. This avoids queuing and network transmission delays associated with cloud conversion, enabling second-level online preview of 3D models. Simultaneously, all computational tasks are completed on the client side, completely freeing up server computing power and bandwidth resources, supporting massive concurrent user access. Furthermore, the use of WebWorker background threads for parsing ensures smooth front-end interaction without blocking the client's UI main thread.
[0084] Secondly, the entire process is performed locally to ensure data security and privacy: the parsing, conversion, and rendering of 3D private format files are all completed in the client's local memory. The source files do not need to leave the user's device, which fundamentally eliminates the risk of leakage caused by uploading confidential or unpublished 3D digital assets to third-party servers.
[0085] Third, a unified middleware architecture provides strong scalability and cross-platform adaptability: By introducing standardized middleware data, the underlying parsing and upper-layer rendering are completely decoupled, and the binary parsing engine can simultaneously support multiple proprietary formats. When adding a new format to the parsing, there is no need to modify the upper-layer rendering logic; only the underlying parsing module needs to be extended.
[0086] Fourth, it offers high cross-platform rendering consistency and fully reproduces the original file's effect: It can automatically identify and unify the coordinate systems (Z-up / Y-up) of different software, solving the problems of model orientation reversal and misalignment. It also maps 3ds Max standard materials and Maya node materials to standard PBR material parameters, ensuring consistent material rendering effects.
[0087] Based on the same inventive concept, this application also provides a data processing device corresponding to the data processing method. Since the principle of the device in this application to solve the problem is similar to the data processing method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0088] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of this application. Figure 5 As shown, the data processing device 200 includes: The environment loading module 201 is used to load a script execution environment in the client in response to a display instruction for a target private format project file. The script execution environment is used to run a preset type of script language in the client. Data generation module 202 is used to extract the original data of the underlying layer of the target private format project file to be displayed in the script running environment, and reconstruct the original data into intermediate layer data; The object display module 203 is used to dynamically map the intermediate layer data to the object to be displayed corresponding to the rendering engine, so as to render the object to be displayed.
[0089] In an optional implementation, the data generation module 202 is specifically used to: use a binary parsing engine running in an independent thread to bypass the interface of the 3D modeling software corresponding to the target private format project file in a pure code manner, and directly parse the underlying data of the target private format project file to obtain the original data carrying software specificity. The binary parsing engine is built based on a scripting language of a preset type.
[0090] In an optional implementation, the target private format project file is a first private format project file. The data generation module 202 includes a first data generation module, which includes a first parsing module and a first extraction module. The first parsing module is used to: parse the directory structure corresponding to the first private format project file and determine the data stream of a specified type in the directory structure as the target data stream. The target data stream includes multiple data blocks. The first extraction module is used to: extract data from the multiple data blocks to obtain the original data.
[0091] In an optional implementation, the first extraction module is specifically used to: for each data block in the target data stream, determine the type of the data block based on the class identifier and block identifier of the data block; parse the data block according to the parsing method corresponding to the data block type to obtain the original data.
[0092] In an optional implementation, the first parsing module is specifically used to: perform a validity check on the first private format project file; if the validity check passes, load the directory structure and query a data stream of a specified type from the directory structure as the target data stream.
[0093] In an optional implementation, the target private format project file is a second private format project file. The data generation module 202 includes a second data generation module, which includes a second extraction module. The second extraction module is used to: filter out target nodes of a preset type from the node graph of the second private format project file; extract the node attributes of the target nodes; and perform standardized mapping on the component list to obtain the original data.
[0094] In an optional implementation, the data generation module 202 is further specifically used to: standardize and reconstruct the original data in the binary parsing engine to obtain intermediate layer data in JSON format.
[0095] In an optional implementation, the object display module 203 includes an information acquisition module, a geometric object construction module, a material object construction module, and an object combination module. The information acquisition module is used to: acquire geometric information and material information from intermediate layer data; the geometric object construction module is used to: map geometric information into geometric objects that the rendering engine can recognize; the material object construction module is used to: map material information into physically based rendering (PBR) material parameters and construct material objects based on the PBR material parameters; the object combination module is used to: combine geometric objects and material objects into objects to be displayed, assemble them hierarchically, and display them on the client.
[0096] In an optional implementation, the object composition module is specifically used to: add all mesh nodes to the model group object according to the parent-child hierarchy to generate the object to be displayed; determine the bounding box of the object to be displayed, and determine the optimal viewing distance of the camera based on the bounding box.
[0097] In an optional implementation, the information acquisition module is further configured to: determine the span of the vertex bounding box of the grid node in the intermediate layer data; and, based on the span, use a heuristic method to detect and correct the vertical axis of the grid node.
[0098] The data processing device provided in this application embodiment can directly parse 3D proprietary formats on the client side without relying on native software such as 3ds Max / Maya. It has the advantages of high processing efficiency, data security and easy architecture expansion. Compared with the data processing methods in the prior art, it solves the problems of heavy reliance on native 3D modeling software when displaying existing 3D proprietary format files, the inability of the client to directly preview 3D proprietary format files and the low conversion efficiency of the server.
[0099] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 300 includes a processor 310, a memory 320, and a bus 330.
[0100] The memory 320 stores machine-readable instructions executable by the processor 310. When the electronic device 300 is running, the processor 310 and the memory 320 communicate via the bus 330. When the machine-readable instructions are executed by the processor 310, they can perform the operations described above. Figure 1 The steps of the data processing method in the illustrated embodiment are specifically implemented as follows: In response to the display instruction for the target private format project file, a script execution environment is loaded in the client. The script execution environment is used to run a script language of a preset type in the client. In the script execution environment, the original data of the underlying layer of the target private format project file to be displayed is extracted, and the original data is reconstructed into intermediate layer data. The intermediate layer data is dynamically mapped to the object to be displayed required by the rendering engine to render the object to be displayed.
[0101] The electronic device provided in this application embodiment can directly parse 3D proprietary formats on the client side without relying on native software such as 3ds Max / Maya. It has the advantages of high processing efficiency, data security and easy architecture expansion. Compared with the data processing methods in the prior art, it solves the problems of heavy reliance on native 3D modeling software when displaying existing 3D proprietary format files, the inability of the client to directly preview 3D proprietary format files and the low conversion efficiency of the server.
[0102] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the data processing method in the illustrated embodiment are specifically implemented as follows: In response to the display instruction for the target private format project file, a script execution environment is loaded in the client. The script execution environment is used to run a script language of a preset type in the client. In the script execution environment, the original data of the underlying layer of the target private format project file to be displayed is extracted, and the original data is reconstructed into intermediate layer data. The intermediate layer data is dynamically mapped to the object to be displayed required by the rendering engine to render the object to be displayed.
[0103] The computer-readable storage medium provided in this application embodiment can directly parse 3D proprietary formats on the client side without relying on native software such as 3ds Max / Maya. It has the advantages of high processing efficiency, data security and easy architecture expansion. Compared with the data processing methods in the prior art, it solves the problems of heavy reliance on native 3D modeling software when displaying existing 3D proprietary format files, the inability of the client to directly preview 3D proprietary format files and the low conversion efficiency of the server.
[0104] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0105] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0106] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0107] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0108] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0109] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A data processing method, characterized in that, include: In response to a display command for a target proprietary format project file, a script execution environment is loaded in the client, the script execution environment being used to run a pre-defined type of script language in the client; In the script execution environment, the original data of the underlying layer of the target private format project file to be displayed is extracted, and the original data is reconstructed into intermediate layer data; The intermediate layer data is dynamically mapped to the object to be displayed required by the rendering engine, so as to render the object to be displayed.
2. The method according to claim 1, characterized in that, The step of extracting the original data from the underlying layer of the target private format project file to be displayed and reconstructing the original data into intermediate layer data in the script execution environment includes: By utilizing a binary parsing engine running in the independent thread, the interface of the 3D modeling software corresponding to the target proprietary format project file is bypassed, and the underlying data of the target proprietary format project file is directly parsed to obtain the original data carrying software specificity. The binary parsing engine is built based on the preset type of scripting language.
3. The method according to claim 2, characterized in that, The target proprietary format project file is a first proprietary format project file. The underlying data of the target proprietary format project file is parsed in the following way to obtain the original data carrying software specificity: Parse the directory structure corresponding to the first private format project file, and determine the data stream of a specified type in the directory structure as the target data stream, wherein the target data stream includes multiple data blocks; Data is extracted from the multiple data blocks to obtain the original data.
4. The method according to claim 3, characterized in that, The step of extracting data from the multiple data blocks to obtain the original data includes: For each data block in the target data stream, the type of the data block is determined based on the class identifier and block identifier of the data block; The data block is parsed according to the parsing method corresponding to the data block type to obtain the original data.
5. The method according to claim 3, characterized in that, The step of parsing the directory structure corresponding to the first private format project file and determining the data stream of a specified type in the directory structure as the target data stream includes: Perform a validity check on the first private format project file; If the validity check is passed, the directory structure is loaded, and a data stream of the specified type is queried from the directory structure as the target data stream.
6. The method according to claim 1, characterized in that, The target proprietary format project file is a second proprietary format project file, and the target proprietary format project file is parsed in the following way: Filter out target nodes of a preset type from the node graph of the second private format project file; Extract the node attributes of the target node and perform standardized mapping on the component list to obtain the raw data.
7. The method according to claim 2, characterized in that, The step of reconstructing the original data into intermediate layer data includes: In the binary parsing engine, the original data is standardized and reconstructed to obtain intermediate layer data in JSON format.
8. The method according to claim 1, characterized in that, The step of dynamically mapping the intermediate layer data to the object to be displayed required by the rendering engine, and rendering the object to be displayed, includes: Geometric and material information are obtained from the intermediate layer data; The geometric information is mapped into geometric objects that the rendering engine can recognize; The material information is mapped to physically based rendering (PBR) material parameters, and a material object is constructed based on the PBR material parameters. The geometric object and the material object are combined into an object to be displayed, and then assembled in a hierarchical manner and displayed in the client.
9. The method according to claim 8, characterized in that, The step of combining the geometric object and the material object into a displayable object, assembling them hierarchically, and then displaying them on the client includes: Add all mesh nodes to the model group object according to the parent-child hierarchy to generate the object to be displayed; Determine the bounding box of the object to be displayed, and determine the optimal viewing distance of the camera based on the bounding box.
10. The method according to claim 8, characterized in that, After obtaining geometric and material information from the intermediate layer data, the process also includes: Determine the span of the vertex bounding box of the grid node in the intermediate layer data; Based on the span, a heuristic method is used to detect and correct the vertical axis of the grid nodes.