CN114528043A

CN114528043A - File loading method, device, equipment and computer readable storage medium

Info

Publication number: CN114528043A
Application number: CN202210129513.7A
Authority: CN
Inventors: 周家炜; 孙凌峰
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-02-11
Filing date: 2022-02-11
Publication date: 2022-05-24
Anticipated expiration: 2042-02-11
Also published as: CN114528043B

Abstract

The application provides a file loading method, a device, equipment and a computer readable storage medium; the method comprises the following steps: acquiring a file to be loaded, wherein the file to be loaded comprises object information of a plurality of virtual objects, and the object information of the virtual objects has no nested relation; acquiring component information of each virtual object from object information of each virtual object, and allocating a memory space of each virtual object in operation based on the object information of each virtual object; acquiring the object type of each virtual object, and filling information into the memory space of each virtual object during operation based on the object type and the component information of each virtual object; and constructing a hierarchical structure among the virtual objects based on the object information of the virtual objects, and displaying the virtual objects based on the hierarchical structure. By the method and the device, the file loading speed can be improved.

Description

File loading method, device, equipment and computer readable storage medium

Technical Field

The present application relates to file processing technologies, and in particular, to a file loading method, device, and apparatus, and a computer-readable storage medium.

Background

At present, when an engine loads a virtual scene file, because the virtual scene file reserves the nesting level of a virtual object in a virtual scene displayed by an editor, a very deep nesting hierarchical structure can be generated when a complex virtual scene is processed, the engine is constrained to instantiate the virtual object in the file only strictly from high to low, and the efficiency of loading the virtual scene file by the engine is greatly influenced. Some virtual scene files locate a scene or a prefabricated part file through a file head Hash (Hash) value, a specific attribute value in a certain file is located through a virtual object Hash value or a virtual component Hash value, and when a certain virtual object is instantiated in the scene loading process, the whole game object component data can be acquired only by jumping to different positions of different files according to the stored component Hash value. This approach requires a lot of performance loss to obtain the complete data of each virtual object, and also reduces the loading speed of the virtual scene file.

Disclosure of Invention

The embodiment of the application provides a file loading method, a file loading device and a computer readable storage medium, which can improve the file loading speed.

The technical scheme of the embodiment of the application is realized as follows:

an embodiment of the present application provides a file loading method, including:

acquiring a file to be loaded, wherein the file to be loaded comprises object information of a plurality of virtual objects, and the object information of the plurality of virtual objects has no nested relation;

acquiring component information of each virtual object from object information of each virtual object, and allocating a memory space of each virtual object in operation based on the object information of each virtual object;

acquiring the object type of each virtual object, and filling information into the memory space of each virtual object during operation based on the object type and the component information of each virtual object;

and constructing a hierarchical structure among the virtual objects based on the object information of the virtual objects, and displaying the virtual objects based on the hierarchical structure.

An embodiment of the present application provides a file loading apparatus, including: .

The device comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring a file to be loaded, the file to be loaded comprises object information of a plurality of virtual objects, and the object information of the virtual objects is not nested;

the second acquisition module is used for acquiring the component information of each virtual object from the object information of each virtual object and allocating the memory space of each virtual object during operation based on the object information of each virtual object;

the information filling module is used for acquiring the object type of each virtual object and filling information into the memory space of each virtual object during operation based on the object type and the component information of each virtual object;

and the hierarchy building module is used for building a hierarchy between the virtual objects based on the object information of the virtual objects and displaying the virtual objects based on the hierarchy.

In some embodiments, the object information includes attribute information and component information of the virtual object, and the corresponding second obtaining module is further configured to:

and directly acquiring the component identification of each component and the component content information of each component included in the ith virtual object from the object information of the ith virtual object, wherein i is 1, 2, …, and N is the total number of the virtual objects.

In some embodiments, the second obtaining module is further configured to:

acquiring component combination information of each virtual object from the attribute information of each virtual object;

determining component identifications contained in the virtual objects based on the component combination information;

and allocating the memory space of each virtual object when running based on the component identification contained in each virtual object.

In some embodiments, the information populating module is further to:

determining component filling information of the ith virtual object when running based on the object type and the component information of the ith virtual object;

determining a component system corresponding to each component based on the component identification of each component included in the ith virtual object;

and filling the component filling information into the memory space of each virtual object during operation by using the deserialization function in the component system corresponding to each component.

In some embodiments, the information populating module is further to:

and when the object type of the ith virtual object is a scene self-creation object, determining the component content information of each component as the component filling information when the ith virtual object runs.

In some embodiments, the information populating module is further to:

when the object type of the ith virtual object is a prefabricated part example object, determining an original prefabricated part path and a prefabricated part example identifier of the ith virtual object based on the attribute information of the ith virtual object;

obtaining original component information based on the original preform path and the preform instance identifier;

determining whether the component information of the ith virtual object is empty;

and when the component information of the ith virtual object is empty, determining the original component information as the component filling information when the ith virtual object runs.

In some embodiments, the information populating module is further to:

when the component information of the ith virtual object is not empty, determining whether the ith virtual object contains a deleted component;

when the ith virtual object contains a deleted component, acquiring component content information corresponding to the deleted component, wherein the component content information comprises a deleted component identifier;

determining component content information of other components as difference information of the other components, wherein the other components are components of the ith virtual object except for the deleted component;

determining component fill information for the ith virtual object based on the original component information, the deleted component identification, and the difference information for the other components.

In some embodiments, the information populating module is further to:

deleting the component information corresponding to the deleted component identification in the original component information to obtain deleted component information;

updating the deleted component information based on the difference information of the other components to obtain updated component information;

and determining the updated component information as the component filling information of the ith virtual object.

In some embodiments, the information populating module is further to:

when the ith virtual object does not contain a deleted component, determining the component content information of each component as the difference information of each component;

determining component fill information for the ith virtual object based on the original component information and the difference information for the respective components.

In some embodiments, the hierarchy building module is further configured to:

acquiring the hierarchy information of each virtual object from the object information of each virtual object, wherein the hierarchy information comprises an object identifier of a parent object of the virtual object, an object identifier of a child object of the virtual object, an object identifier of a previous brother object of the virtual object, and an object identifier of a next brother object of the virtual object;

and constructing a hierarchical structure among the virtual objects based on the hierarchical information of the virtual objects.

An embodiment of the present application provides a computer device, including:

a memory for storing executable instructions;

and the processor is used for realizing the file loading method provided by the embodiment of the application when the executable instructions stored in the memory are executed.

The embodiment of the present application provides a computer-readable storage medium, which stores executable instructions for causing a processor to execute the computer-readable storage medium to implement the file loading method provided by the embodiment of the present application.

The embodiment of the application has the following beneficial effects:

after a file to be loaded is obtained, the file to be loaded comprises object information of a plurality of virtual objects, component information of each virtual object is obtained from the object information of each virtual object, and a memory space of each virtual object in operation is allocated based on the object information of each virtual object; and acquiring the object type of each virtual object, filling information into the memory space of each virtual object during running based on the object type and the component information of each virtual object, then constructing a hierarchical structure among the virtual objects based on the object information of each virtual object, and displaying each virtual object based on the hierarchical structure. In addition, when the file is loaded, memory space of each virtual object in operation is distributed through the object information, and then the memory space of each virtual object in operation is filled with information according to component information in parallel, so that the file loading speed can be increased, and the file loading performance of an engine is improved.

Drawings

FIG. 1A is a schematic view of a game scenario;

FIG. 1B is a schematic representation of a preform consisting of only one game object;

FIG. 1C is a diagram showing the relationship between game scenes, preforms and examples of preforms;

FIG. 1D is a schematic illustration of the game scene file and the content contained in the preform file;

FIG. 1E is a diagram illustrating the contents of a scene file in the related art;

fig. 2 is a schematic structural diagram of a file loading system architecture according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of a file loading terminal 400 according to an embodiment of the present application;

fig. 4 is a schematic flowchart of an implementation flow of a file loading method provided in an embodiment of the present application;

FIG. 5 is a flow chart illustrating an implementation of determining component fill information according to an embodiment of the present disclosure; (ii) a

FIG. 6A is a diagram illustrating the correspondence between different components and component systems in the engine;

FIG. 6B is a schematic diagram of a hierarchy of virtual objects;

FIG. 7A is a schematic diagram of an application environment of a scene file and a preform file provided in an embodiment of the present application;

FIG. 7B is a diagram illustrating the contents of a game installation package according to an embodiment of the present disclosure;

FIG. 8 is a block diagram of an overall framework for a file format provided by an embodiment of the present application;

FIG. 9 is a schematic diagram of file header information provided in an embodiment of the present application;

FIG. 10 is a diagram illustrating the contents of a file body in a file format according to an embodiment of the present application;

FIG. 11 is a schematic diagram of difference information between game objects in an example preform and corresponding game objects in the preform provided in an embodiment of the present application;

FIG. 12 is a schematic diagram illustrating storage of difference information provided in an embodiment of the present application;

fig. 13 is a schematic diagram of a file format of an example preform provided in an embodiment of the present application.

Detailed Description

In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the accompanying drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without making creative efforts fall within the protection scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the following description, references to the terms "first \ second \ third" are only to distinguish similar objects and do not denote a particular order, but rather the terms "first \ second \ third" are used to interchange specific orders or sequences, where appropriate, so as to enable the embodiments of the application described herein to be practiced in other than the order shown or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.

1) Component (Component), a collection of several attributes that describe some type of function of a game object. Depending on the function, a game object actually has several components.

2) Game objects (GameObject), which are used to mount the basic units of various system components during game development.

3) A game Scene (Scene) containing a set of game objects to describe the objects of the game content.

4) A Prefab (Prefab), a reusable resource template composed of one or more game objects, for accelerating game scene construction.

5) PrefabInstance, a set of game objects that are quickly created in a game editor using Prefab.

6) Key value pairs, the way in which a key indexes a corresponding value. Keywords are typically basic types, typically strings, numbers, and the like. While the values may be of a complex type, such as an array.

In order to better understand the game data rendering method provided by the embodiment of the present application, a description is first given of a game scene file and a prefabricated part file for rendering in the related art. FIG. 1A illustrates a game scenario. The scene is composed of 4 game objects, where Sphere (Sphere) game object 111 is the parent-child node of Plane (Plane) game object 112. Cube (Cube) game object 113 and Cube2 game object 114 are siblings of Sphere, respectively.

FIG. 1B is a schematic representation of a fabricated part consisting of only one game object. By dragging the preform into the scene, a preform instance can be created. Cube game object and Cube2 game object as in fig. 1A are two examples of preforms, respectively.

FIG. 1C is a diagram showing the relationship between game scenes, preforms and examples of preforms. Taking game object 1 as an example, as shown in fig. 1C, the prefabricated part file corresponding to game object 1 includes the data of game object 1 itself and the Json data of each component, and after the prefabricated part made by art is dragged to the game scene, a real runtime state game object is generated in the game scene according to the data of the game object and the component in the prefabricated part (Prefab) file, and the game objects created by Prefab come from the same prefabricated part Instance (Prefab Instance). When a user modifies a game object (GameObject)1 in a game scene and component information in the game object, the prefab embodiment maintains difference information of information stored in the game scene and the prefab.

Fig. 1D is a schematic diagram of the content of the game scene file and the prefabricated part file, as shown in fig. 1D, the game scene file includes game object information, baking information, routing information and other scene information, and the game object information in the game scene includes information of game objects created by the game scene itself and information of game objects managed by the prefabricated part instances created by the prefabricated part. Because the preform is a template used to generate the game object, no data relating to non-game objects is contained, and therefore only game object information is included in the preform file.

Fig. 1E is a schematic diagram of file contents of a scene file in the related art, and fig. 1E shows two formats of the scene file commonly used in a game engine in the related art. When the game engine uses the scene file 1 as the scene file saving format, the prefab file format used by the game engine basically coincides with the scene file 1 except that it does not contain the baking, routing, and other scene information shown in fig. 1E. The file format flattens all storage relationships of game objects and components. Nested relationships between game objects are maintained by a Transform component (that maintains parent and child game objects for the current game object). The game object stores the hash value of the component contained therein. Corresponding component information can be found in the file according to the component hash value, and the game object in running can be instantiated in the engine according to the information. For the game object in the prefabricated part example, the file format needs to be restored into real component information according to the difference information maintained by the file format and all the component information of the game object in the corresponding prefabricated part, so that the game object in the running process is instantiated in the engine.

Part of the game engine stores the scene file using the file format of the scene file 2 in fig. 1E. The file format manages nesting of game objects directly according to indentation or a self-contained hierarchical structure such as xml markup language. The component contents of each game object are in its own sub-hierarchy. And the use of preforms in scenes is rarely considered based on this type of scene content.

The following explains the disadvantages of the two scene file formats

Scene file 1 describes the scene and the prefabricated parts in a file format that flattens all game objects and game components. The scene or prefabricated file is located by the head Hash value of the file head information shown in fig. 1E, and the specific attribute value in a certain file is located by the game content Hash value (such as the game object Hash value and the game component Hash value). According to the scheme, firstly, a game engine is required to maintain a manager of a global hash value and file corresponding relation so as to know which file on a disk corresponds to a file in the hash value of the file. When the scene or the prefab content is modified, the hash value of the scene and prefab files changes, and the scene and prefab files need to be synchronized to relevant places. This solution is very complex to implement and when scene or preform modifications occur, because the Hash value also changes. Secondly, when a certain game object is instantiated in the process of loading a scene, the game object component data can be acquired by jumping to different positions of different files according to the stored component hash values (

component hash values

1 and 2 … N in the game object in fig. 1E). This approach requires a significant performance penalty in order to obtain the complete data for each GameObject.

In addition, the scheme also finds the content of the corresponding game object or the content of the game component in the Prefab file according to the file hash and the game content hash, then updates the content of the game object or the content of the game component according to the difference character string (the character string formed by the component attributes, such as the x-coordinate attribute in the translation attribute in transformformat) according to the value stored in the Prefab instance, and instantiates the game object in the engine by taking the updated data. The way of synchronizing the changes of PrefabInstance and Prefab to obtain the data of the completed game object by the difference character string stored in the file is complicated and very performance-consuming.

Although the scene file 2 has a simple structure and maintains the nested hierarchy of game objects in the game scene displayed by the editor, a very deep nested hierarchy structure appears when a complex game scene is processed, and the engine is constrained to instantiate the game objects in the file only strictly from high to low. Furthermore, this file format is also difficult to support with respect to the preform capabilities.

Based on the above problems, an embodiment of the present application provides a file loading method, in which a file format capable of supporting both an expression prefabricated part and a scene is used, and complexity and performance overhead are avoided by using hash value index file content and a difference character string to make a watchband in a scene file 1 in the related art. In addition, the manner of describing the GameObject and the Component (Component) in the embodiments of the present application can be applied to various implementations of engine loading scenes and prefabricated parts, and is not limited to parsing out all contents based on nesting starting from several gameobjects in a file. The file format provided by the embodiment of the application can support different engine architectures, can meet the requirement that a part of engines instantiate game objects by taking the combination type of a plurality of components as granularity, and improves the performance of the engines.

Embodiments of the present application provide a file loading method, apparatus, device, and computer-readable storage medium, which can increase a file loading speed and improve engine performance, and an exemplary application of a computer device provided in an embodiment of the present application is described below. In the following, an exemplary application will be explained when the device is implemented as a terminal.

Referring to fig. 2, fig. 2 is a schematic structural diagram of a document processing system 100 according to an embodiment of the present disclosure, as shown in fig. 2, the document processing system 100 includes an art design terminal 200, a network 300, and a document loading terminal 400, which are connected to the art design terminal 200 through the network 300, where the network 300 may be a wide area network or a local area network, or a combination of the two.

When the file loading terminal 400 and the art design terminal 200 establish a direct communication connection through the network 300, the art design terminal 200 may transmit a file to the file loading terminal 400 after completing a scene design or a preform design. The file loading terminal 400 obtains a file to be loaded, where the file to be loaded includes object information of multiple virtual objects, where there is no nested relationship between the object information of the multiple virtual objects, that is, the object information of the multiple virtual objects is stored in a flattened manner, and there is no nested relationship between storage levels, and the file can be simultaneously obtained so as to improve a reading rate, then obtains component information of each virtual object from the object information of each virtual object, and allocates a memory space in which each virtual object operates based on the object information of each virtual object, then obtains an object type of each virtual object, and fills information into the memory space in which each virtual object operates based on the object type of each virtual object and the component information, and finally constructs a hierarchical structure between each virtual object based on the object information of each virtual object, and displaying each virtual object based on the hierarchical structure, and finishing the file loading process at this time.

In some embodiments, the art design terminal 200 may further connect to a server through the network 300, the file loading terminal 400 also connects to the server through the network 300, the art design terminal 200 may send a file to the server after completing scene design or preform design, and the file loading terminal 400 obtains the file to be loaded from the server when the file needs to be loaded.

In some embodiments, the server may be an independent physical server, may also be a server cluster or a distributed system formed by a plurality of physical servers, and may also be a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, a middleware service, a domain name service, a security service, a CDN, and a big data and artificial intelligence platform. The file loading terminal 400 may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a smart car device, and the like. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the embodiment of the present application is not limited.

Referring to fig. 3, fig. 3 is a schematic structural diagram of a file loading terminal 400 according to an embodiment of the present application, where the file loading terminal 400 shown in fig. 3 includes: at least one processor 410, memory 450, at least one network interface 420, and a user interface 430. The various components in the file loading terminal 400 are coupled together by a bus system 440. It is understood that the bus system 440 is used to enable communications among the components. The bus system 440 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 440 in FIG. 3.

The Processor 410 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.

The user interface 430 includes one or more output devices 431, including one or more speakers and/or one or more visual displays, that enable the presentation of media content. The user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 450 optionally includes one or more storage devices physically located remote from processor 410.

The memory 450 includes either volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. The nonvolatile memory may be a Read Only Memory (ROM), and the volatile memory may be a Random Access Memory (RAM). The memory 450 described in embodiments herein is intended to comprise any suitable type of memory.

In some embodiments, memory 450 is capable of storing data, examples of which include programs, modules, and data structures, or a subset or superset thereof, to support various operations, as exemplified below.

An operating system 451, including system programs for handling various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and handling hardware-based tasks;

a network communication module 452 for communicating to other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

a presentation module 453 for enabling presentation of information (e.g., user interfaces for operating peripherals and displaying content and information) via one or more output devices 431 (e.g., display screens, speakers, etc.) associated with user interface 430;

an input processing module 454 for detecting one or more user inputs or interactions from one of the one or more input devices 432 and translating the detected inputs or interactions.

In some embodiments, the apparatus provided in this embodiment of the present application may be implemented in software, and fig. 3 illustrates a file loading apparatus 455 stored in the memory 450, which may be software in the form of programs and plug-ins, and includes the following software modules: a first acquiring module 4551, a second acquiring module 4552, an information padding module 4553 and a hierarchy building module 4554, which are logical and thus may be arbitrarily combined or further divided according to the functions implemented. The functions of the respective modules will be explained below.

In other embodiments, the apparatus provided in this embodiment may be implemented in hardware, and for example, the apparatus provided in this embodiment may be a processor in the form of a hardware decoding processor, which is programmed to execute the file loading method provided in this embodiment, for example, the processor in the form of the hardware decoding processor may be one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), Field Programmable Gate Arrays (FPGAs), or other electronic components.

The file loading method provided by the embodiment of the present application will be described with reference to exemplary applications and implementations of the terminal provided by the embodiment of the present application.

Fig. 4 is a schematic flow chart illustrating an implementation of the file loading method according to an embodiment of the present application, and each step of the file loading method according to the embodiment of the present application will be described with reference to fig. 4.

And step S101, acquiring a file to be loaded.

The file to be loaded can be a virtual scene file or a prefabricated file. The file to be loaded comprises object information of a plurality of virtual objects, and the object information of the virtual objects has no nested relation. When the file to be loaded is a virtual scene file, the virtual object contained in the file to be loaded may be a scene file created by itself, or may be from a prefabricated part example, that is, the virtual scene file may include object information of two types of virtual objects. When the file to be loaded is a preform file, the virtual objects contained in the file to be loaded are all from the preform instance, that is, the preform file only includes the object information of one type of virtual object.

The object information of the virtual object includes attribute information and component information of the virtual object, and in the embodiment of the present application, the attribute information and the component information of the virtual object are different based on the type of the virtual object. When the type of the virtual object is self-created of the scene file, the attribute information comprises a virtual object name, a virtual object unique identification number, a component combination type and a mark field for marking whether the virtual object is from a prefabricated part example, and the component information comprises complete information of each component; when the type of the virtual object is from the prefabricated part example, the attribute information comprises a prefabricated part example ID, a prefabricated part path and a prefabricated part ID besides a virtual object name, a virtual object unique identification number, a component combination type and a mark field for marking whether the virtual object is from the prefabricated part example; the component information comprises the difference information which is the same as the original component content information in the prefabricated part example, but the content format of the difference information is the same as that of the original component content information, and is different from the hash value for storing the difference information in the related technology, so that the actual component content information can be directly determined based on the difference information and the original component content information, and the information processing efficiency is improved.

Step S102, obtaining the component information of each virtual object from the object information of each virtual object, and allocating the memory space of each virtual object when running based on the object information of each virtual object.

In the embodiment of the present application, the component information of each virtual object includes content information of each component. The component identifiers and component content information of all the virtual objects are stored under the component keywords of the object information of the virtual objects. The data format of each component is determined by the component system of the engine.

When the memory space of each virtual object in operation is allocated based on the object information of each virtual object, the component identifier of the component included in the virtual object can be determined by the component combination type field in the attribute information included in the object information of the virtual object, and the memory space of the virtual object in operation is allocated based on each component identifier.

Step S103, acquiring the object type of each virtual object, and filling information for the memory space of each virtual object during operation based on the object type and the component information of each virtual object.

When the virtual object type is obtained, a field value of a mark field used for marking whether the virtual object is from a prefabricated part example or not in object information can be obtained, the field value is a Boolean type numerical value and is tr ue or false, when the mark field is false, the virtual object is not from the prefabricated part example, namely the object type of the virtual object is self-creation of a scene file; when the flag field is true, it indicates that the virtual object is from the instance of the preform, i.e. the object type of the virtual object is from the instance of the preform.

When the information filling is carried out on the memory space of each virtual object during the operation based on the object type and the component information of each virtual object, firstly, the component filling information of each component is determined according to the object type and the component information of the virtual object, and then the processing system corresponding to each component fills the component filling information into the corresponding memory space. When the object type of the virtual object is the self-creation of the scene file, the component information is the component filling information; when the object type of the virtual object is the object of the prefabricated part instance, the component information is the difference information with the original component content in the prefabricated part instance, and the component filling content needs to be determined through the difference information and the original component content information.

And step S104, constructing a hierarchical structure among the virtual objects based on the object information of the virtual objects, and displaying the virtual objects based on the hierarchical structure.

In this embodiment, the object information of the virtual object includes an object identifier of a parent object of the virtual object, an object identifier of a child object of the virtual object, an object identifier of a previous sibling object of the virtual object, and an object identifier of a next sibling object of the virtual object, and after acquiring the object identifier of the parent object of each virtual object, the object identifier of the child object of the virtual object, the object identifier of the previous sibling object of the virtual object, and the object identifier of the next sibling object of the virtual object, a hierarchical structure between the virtual objects can be constructed according to these pieces of information. And then, based on the hierarchical structure information, rendering and displaying each virtual object to finish the file loading process.

In the embodiment of the application, after a file loading terminal acquires a file to be loaded, the file to be loaded comprises object information of a plurality of virtual objects, component information of each virtual object is acquired from the object information of each virtual object, and a memory space of each virtual object during operation is allocated based on the object information of each virtual object; and acquiring the object type of each virtual object, filling information into the memory space of each virtual object during running based on the object type and the component information of each virtual object, then constructing a hierarchical structure among the virtual objects based on the object information of each virtual object, and displaying each virtual object based on the hierarchical structure. In addition, when the file is loaded, memory space of each virtual object in operation is distributed through the object information, and then the memory space of each virtual object in operation is filled with information in parallel according to the component information, so that the file loading speed can be increased, and the file loading performance of an engine can be improved.

In some embodiments, the object information includes attribute information and component information of the virtual object, and the step S102 of acquiring the component information of each virtual object from the object information of each virtual object and allocating the memory space of each virtual object when running based on the object information of each virtual object may be implemented by:

step S1021, directly acquire, from the object information of the ith virtual object, the component identifiers of the components included in the ith virtual object and the component content information of the components.

Wherein i is 1, 2, …, N is the total number of virtual objects, and N is a positive integer.

In the embodiment of the present application, the object information of different virtual objects is stored in a flattened manner, while the component information of virtual objects is all stored in the object information of each virtual object, and in implementation, the component information may be stored in the content corresponding to a keyword "components" in the object information. The component information includes component identification and component content information for each component. The Component identifier may be a Component name, such as Mesh Component, Camera Component, Light Component, and the like, and the Component content information may be complete Component content information or Component difference information.

Step S1022, acquiring component combination information of each virtual object from the attribute information of each virtual object.

In this embodiment of the present application, a value of a key "prototype" in the attribute information of the virtual object may be obtained, where the value corresponding to the "prototype" key is a hash value calculated by using a hash algorithm on component identifiers of each component included in the virtual object.

Step S1023, based on the component combination information, determines the component identifiers of the components included in the respective virtual objects.

When the step is implemented, the component combination information of each virtual object can be analyzed according to a preset hash algorithm, so that the component identification contained in each virtual object is obtained.

Step S1024, allocating a memory space of each virtual object during running based on the component identifier of the component included in each virtual object.

After the component identifier of the component included in each virtual object is obtained, the memory space required by the component corresponding to each component identifier can be obtained, and further the memory space required by the running of each virtual object can be determined.

Through the steps S1021 to S1024, component combination information may be stored in the attribute information of the virtual object in advance, so that the component identifier of the component included in the virtual object may be determined by analyzing the component combination information, and further, the memory space required by the running of each virtual object is determined and pre-allocated, thereby providing a basis for the subsequent parallel execution of information filling. And because the component combination information is stored, the requirement that a part of engines instantiate virtual objects by taking the combination type of a plurality of components as granularity can be met, and the performance of loading scenes and prefabricated parts by the engines is improved.

In some embodiments, the "filling information for the memory space of each runtime virtual object based on the object type and the component information of each virtual object" in the step S103 may be implemented by:

and step S1031, determining component filling information when the ith virtual object runs based on the object type and the component information of the ith virtual object.

The component information comprises a component identifier and component content information, because when the object type of the ith virtual object is a scene self-creation object, the component content information comprises complete component information, the component content information is determined to be component filling information, and when the object type of the ith virtual object is a prefabricated part example object, the component content information comprises difference information, corresponding original component information needs to be determined through the component identifier in the component information, and the component filling information corresponding to the component is determined based on the original component information and the difference information.

Step S1032, determine a component system corresponding to each component based on the component identifier of each component included in the ith virtual object.

The engine includes a plurality of component systems, fig. 6A is a schematic diagram of correspondence between different components and component systems in the engine, and as shown in fig. 6A, different component identifiers correspond to different component systems, for example, a grid system corresponding to a grid component, an illumination system corresponding to an illumination component, and a transformation system corresponding to a transformation component.

Step S1033, filling the component filling information into the memory space of each virtual object in operation by using the deserialization function in the component system corresponding to each component.

In the embodiment of the present application, the component system includes a serialization function and an deserialization function, wherein the deserialization function can fill the component filling information into the memory space of each virtual object during running, and the serialization function can store the component content of the virtual object during running to a text state. And the deserialization function is used for converting the text state into the component information of the virtual object in the runtime.

Through the steps S1031 to S1033, after the component filling information when the ith virtual object runs is determined based on the object type and the component information of the ith virtual object, the component system corresponding to each component identifier is determined, and then the component filling information corresponding to each component is filled into the memory space by calling the deserialization function of each component system in parallel, so that the loading time can be shortened, and the loading efficiency can be improved.

In some embodiments, the step S1031 "determining component filling information when each virtual object runs based on the object type and the component information of each virtual object" may be implemented by steps S311 to S3112 shown in fig. 5, and each step is described below with reference to fig. 5.

Step S311, determining whether the ith virtual object is a scene self-creation object.

When the step is implemented, a field value of a mark field "isprefab instance" used for marking whether the virtual object is from the preform instance in the attribute information of the ith virtual object may be obtained, and when the field value of "isPr efab instance" is false, it indicates that the object type of the ith virtual object is the scene creation object, and then the step proceeds to step S312; when the field value of "isprefaface instance" is true, it indicates that the object type of the i-th virtual object is the preform instance object, and then step S313 is entered.

In step S312, the component content information of each component is determined as the component filling information when the ith virtual object runs.

Since the complete component data is included in the component content information of the scene-created virtual object, the component content information may be determined as component fill information.

Step 313, determining an original preform path and a preform instance identifier of the ith virtual object based on the attribute information of the ith virtual object.

When the ith virtual object is a preform instance object, the value of the "instanceId" keyword may be obtained from the attribute information of the ith virtual object to obtain a preform instance identifier, and the original preform path is obtained by obtaining the value of the "prefabPat" keyword.

In step S314, original component information is obtained based on the original preform path and the preform instance identifier.

In this step, raw assembly information is obtained for each assembly in the preform example. Assuming that the preform example includes 10 components, the raw component information for the 10 components is obtained in this step. The original component information includes component identification and original component content information.

In step S315, it is determined whether the component information of the ith virtual object is empty.

Since the difference information is stored in the component information of the virtual object from the fabricated part example, when the component information of the ith virtual object is empty, it indicates that the original component information in the fabricated part example is not modified, and then step S316 is performed; when the component information of the ith virtual object is not empty, it is described that there is a modification to the original component information in the preform example, and then the process proceeds to step S317.

Step S316, determining the original component information as component filling information when the ith virtual object runs.

Since the component information of the ith virtual object is empty, which indicates that no modification is performed on the components of the preform instance, the original component information may be determined as the component filling information when the ith virtual object runs.

In step S317, it is determined whether the i-th virtual object includes a delete component.

When the step is implemented, it may be obtained whether the component information includes a component corresponding to the deleted component identifier, for example, the preset deleted component identifier is "deleted Components", and when the component information includes a component corresponding to the "deleted Components", it is determined that the ith virtual object includes the deleted component, then step S318 is performed; if the component information does not include a component corresponding to "deleted Components", the process proceeds to step S3113 if it is determined that the deleted component is not included.

In step S318, component content information corresponding to the deleted component is acquired.

The component content information corresponding to the deleted component includes a deleted component identification.

In step S319, the component content information of the other component is determined as the difference information of the other component.

The other components are the components of the ith virtual object except the deleted component.

In step S3110, component filling information of the ith virtual object is determined based on the original component information, the deleted component identifier, and the difference information of the other components.

This step can be achieved by:

step S31101, deleting the component information corresponding to the deleted component identifier in the original component information, to obtain the deleted component information.

And step S31102, updating the deleted component information based on the difference information of other components to obtain updated component information.

In the embodiment of the application, the difference information keeps the same nesting mode as the original component content, the difference information is not expressed by a character string of single difference information, the difference information comprises keywords with different values and corresponding difference values with the original component information, and the original value corresponding to the keywords in the difference information is updated to the difference value during the step, so that the cost and the performance of recovering the complete component information can be greatly reduced, and the difficulty of realizing a game engine is greatly simplified.

Step S31103, determining the updated component information as the component fill information of the i-th virtual object.

In step S3111, the component content information of each component is determined as the difference information of each component.

And when the component information of the ith virtual object is not null and does not contain the deleted component, determining the component content information of each component to the difference information of each component. Assuming that 10 components are included in the preform example, wherein 3 components are modified, the difference information of 3 components is included in the ith virtual object of the file to be loaded at this time.

Step S3112, determining component filling information of the i-th virtual object based on the original component information and the difference information of each component.

When the step is realized, updating the original component information based on the difference information of each component to obtain updated component information, and determining the updated component information as the component filling information of the ith virtual object.

In connection with the above example, it is assumed that the original component information includes component identifiers of 10 components and original component contents of 10 components, where the ith virtual object includes difference information of 3 components, and the difference information of each component includes a keyword having a different value from the original component content information of the component and a corresponding difference value, and when the step is implemented, the original values corresponding to the keywords included in the difference information of the three components are updated to the difference values, that is, the original component information is updated, so as to obtain updated component information.

In some embodiments, the step S104 "building a hierarchical structure between each virtual object based on the object information of each virtual object" may be implemented by:

step S1041, obtaining the hierarchical information of each virtual object from the object information of each virtual object.

The hierarchical information includes an object identifier of a parent object of a virtual object, an object identifier of a child object of the virtual object, an object identifier of a previous sibling object of the virtual object, and an object identifier of a next sibling object of the virtual object.

In the embodiment of the present application, the hierarchy information may be stored in attribute information of the object information, or may be stored in component information of the object information. When the hierarchy information is stored in the component information, it may be stored in the transformation component as shown in other embodiments. It should be noted that, when the hierarchy information is stored in the component information, when determining that the component filling information of each virtual object in the running process is implemented based on the object type and the component information of each virtual object, the mentioned component information does not include the transformation component information, that is, the hierarchy information in the transformation component is not used for determining the component filling information.

Step S1042, building a hierarchical structure between the virtual objects based on the hierarchical information of the virtual objects.

After the object identifier of the parent object of each virtual object, the object identifier of the child object of the virtual object, the object identifier of the previous brother object of the virtual object, and the object identifier of the next brother object of the virtual object are obtained, the hierarchical structure among the virtual objects can be constructed according to the obtained hierarchical information.

For example, there are four virtual objects A, B, C, D, wherein the object id of the parent object of virtual object a is null, the object ids of the children are B and C, the object id of the previous sibling object is null, and the object id of the next sibling object is null; the object identifier of the parent object of the virtual object B is A, the object identifier of the child object is D, the object identifier of the previous brother object is empty, and the object identifier of the next brother object is C; the object identifier of the parent object of the virtual object C is A, the object identifier of the child object is null, the object identifier of the previous brother object is B, and the object identifier of the next brother object is null; the object id of the parent object of the virtual object D is B, the object id of the child object is null, the object id of the previous sibling object is null, and the object id of the next sibling object is null, and based on the above-mentioned hierarchical information, the hierarchical structure shown in fig. 6B is obtained.

In the embodiment of the application, the hierarchical structure of the virtual object is constructed through the hierarchical information in the object information, the virtual object is not required to be in a strict nesting relation during storage, the complexity of realizing object information storage can be reduced, the reading efficiency of the object information is improved, and the hierarchical structure of the quasigroup can be constructed based on the hierarchical information to ensure the accuracy of file loading.

Next, an exemplary application of the embodiment of the present application in a practical application scenario will be described.

Fig. 7A is a schematic diagram of an application software environment of a scene file and a preform file provided in an embodiment of the present application, and as shown in fig. 7A, the application software environment includes a game engine 701, an editor 702, a loading system 703, and a file resource 704. Wherein:

the game engine 701 includes a plurality of game scenes, each scene has its own loading system 703(L oadingSystem), the loading system 703 is used for managing the game scenes and the prefabricated parts, and correspondingly, the loading system 703 includes a prefabricated part manager 7031(PrefabManager) and a scene manager 7032(scene ma nager). Prefab manager 7031 is used to generate the preform file provided by the embodiments of the present application and create the preform instance by editing operations received based on editor 702. The SceneManager 7032 is configured to generate the game scene file and the loading scene provided in the embodiment of the present application based on the editing operations received by the editor 702. The user may create a preform instance in the scene from the preform and support modifying the properties of several game objects in the preform instance during use of editor 702.

Fig. 7B is a schematic content diagram of a game installation package provided in the embodiment of the present application, and as shown in fig. 7B, the game installation package includes contents: texture, animation, material, sound, script, scene, prefab, etc., wherein scene and prefab resources are important resources in the game loading, unloading and running processes.

The scene and the prefabricated part are described by the same file format, the situation that the engine loading realization capacity is deeply restricted by the nesting level of game objects and components in a complex game scene is avoided, the requirements of various loading scenes and prefabricated parts of different game engines can be met, and the simple and efficient scene and prefabricated part loading and unloading logic can be conveniently realized by the game engine. In addition, the game engine developer can add and delete customized contents in the file conveniently, the requirements of various and complex games are met, and the game engine developer has higher degree of freedom.

Fig. 8 is a schematic diagram of an overall framework of a file format provided in an embodiment of the present application, where the file format is json-based. As shown in fig. 8, the file format content mainly includes two parts, i.e., file header information 801 and file body information 802, and is composed of two Json objects. The file format can be freely expanded according to the requirements of different engines, and the content of the file format is explained below.

Fig. 9 is a schematic diagram of file header information provided in an embodiment of the present application, and as shown in fig. 9, the file header information includes a file version, a file type, and other resource files on which a current file depends. Because the game engine is iteratively updated during normal game development, small modifications are sometimes made to the scene and pre-production files, but backwards compatibility with legacy scene and pre-production files is guaranteed. It is important that a version information (Ve run) key is needed to distinguish different file versions at this time.

The "resource dependency" is the other resource on which the partial components describing the game objects in the scene and the prefabricated part depend. As shown in fig. 9, the relative path manner is used in the embodiment of the present application to store other resources that are dependent and are loaded into the game engine in advance before the game objects are instantiated according to the scene and the prefab file contents provided in the embodiment of the present application. Fig. 9 is only an example of the actual use of the file format, and the content of keywords and the like in the object can be customized according to the requirement of the engine.

There are a variety of resources in the game, such as grids, textures, maps, shaders, etc. And marking the scene file and the prefabricated part file by using a file type (FileType) to prevent the game engine from mistakenly processing the scene file and the prefabricated part file into other resource files.

Fig. 10 is a schematic diagram of the content of the document body in the document format provided in the embodiment of the present application, where the document body information may be slightly different for the prefabricated document and the game scene document. The game scene file has more key value pairs 1001 as EditorData, SceneData shown in fig. 10 than the prefabricated part file, and the content of the key value pairs varies according to the engine. These two contents will store data relating only to the scene, except for the GameObject.

The contents regarding the value following the GameObjectList keyword in the file body contents shown in fig. 10 include two parts, one is the value of the RootGameObject keyword and the other is the value of the GameObjectList keyword.

Wherein, the euid in the RootGameObject is used to describe which root node of all game objects is, and isperfab resource is used to describe whether the file is a prefabricated file. The euid is used in the game engine to uniquely mark a game object, and in the embodiment of the application, a unique 128-bit number is created for each game object, and then a character string obtained by converting the 16-ary value is used as the value of the euid. Because of the uniqueness of the euid, a parent game object, a first child game object, a previous game object of the same hierarchy, and a next game object of the same hierarchy of this game object can be described in the hierarchy of the transformation component of the engine.

The content described by the GameObjectList keyword is a key-value pair of the euid and game object content. All game objects in the scene are stored flattened in this GameObjectList keyword. However, unlike the related art, all components are not flattened in the embodiment of the present application to avoid the cost of combining information according to hash values.

As shown in fig. 10, the GameObjectId _1 is a value of euid of one of the game objects, and the content corresponding to the value includes two types. The attributes of the game object and the component information contained in the game object are provided. As in the embodiments of the present application, it is not specifically to distinguish game objects from the preform examples. So all the attributes of the game object themselves are shown in table 1:

TABLE 1 table of attribute information of game object

In the embodiment of the present application, the game objects have different attributes according to whether the game objects come from the prefabricated parts (which can be judged according to isperfab I span attributes). The game objects of the preform example have all the attribute values in table 1, while instanceId, prefabPath, prefabEuid are used exclusively for the preform type game objects. Among the attributes shown in table 1, the prototype attribute is specifically used by an engine supporting the ECS architecture, and the engine of the architecture optimizes the game objects in the same component type combination manner by sequentially storing the game objects in the memory. Therefore, when the file provided by the embodiment of the application is used, the component combination of the game object can be rapidly classified according to the attribute, so that the speed of loading scenes and prefabricated parts is increased.

The prefabricated member instance may be composed of one or more game objects, and in the embodiment of the application, the game objects are stored in a flat mode to avoid deep nesting in the hierarchy. The game objects from the instance of the game piece will have an instanceId value to determine which instance of the game piece belongs to. The string of values is also translated by the engine responsible for creating the unique 128-bit number.

Although it is known from which instance of the preform (instanceId) a game object comes, it is not sufficient from which path of the preform (prefabPath). Since the game object of the prefabricated member example is stored in the scene or the prefabricated member, the whole information of the component is not stored, but the difference value between the game object and the component content of the original game object in the corresponding prefabricated member is stored, prefabeeuid is also needed to mark which game object in which prefabricated member the game object comes from, so as to obtain the true whole component information value according to the partial information of the game object and the original game object.

As shown in fig. 10, the content in the game object may contain content information of the component in addition to its own attribute. All components and their own data are stored under the components keywords. The data format of each component is determined by the component system of the game engine. The flattened game object structure provided by the embodiment of the application can meet the requirements of various game engines for loading scenes or prefabricated parts, and meanwhile, information for reconstructing the hierarchical structure of the game object is also required to be provided. Information of the parent game object, the first child game object, and the preceding and succeeding sibling game objects of the game object should be correctly stored in the transformpublic component.

Fig. 11 is a schematic diagram of difference information between a game object in a prefabricated part example and a game object in a corresponding prefabricated part according to an embodiment of the present application, where 1101 shows raw data of a certain component of the game object in the prefabricated part, and after a prefabricated part example is created in a scene or other prefabricated part by using the prefabricated part, part of the data may be modified by an editor to obtain data of the game object in the prefabricated part example shown in 1102. When the game object is stored in a scene or a prefabricated part, only the difference information shown in 1103 is stored.

Fig. 12 is a schematic diagram illustrating storage of difference information provided in the embodiment of the present application, and as shown in fig. 12, component difference information in a game object of a preform example in the embodiment of the present application is not expressed by a character string of single difference information, but a nested mode as the complete content of a component is maintained, so that cost and performance of recovering complete component information can be greatly reduced, and difficulty in implementing a game engine is greatly simplified.

Fig. 13 is a schematic diagram of a file format of an example of a prefabricated part provided in an embodiment of the present application, and as shown in fig. 13, a special "DestroyedComponents" keyword 1301 is also maintained for game objects in the example of the prefabricated part to describe which components of the game objects in the corresponding prefabricated part are deleted from the game objects in the example of the prefabricated part. Because the editor can add or delete components in addition to modifying the attribute values of the components when modifying the information of the game objects in the example of the prefabricated member. For added components, only the next component needs to be saved in the game object in the prefabricated part example, and for deleted components, the component needs to be specially saved in the value corresponding to the DestroyedComponents key word.

The embodiment of the application provides a file format capable of simultaneously supporting the expression prefabricated part and the scene, and the realization complexity is greatly reduced and the performance expense is reduced by flattening the stored game object and storing the self component information in the game object. In addition, the mode of describing the difference information of the game objects in the prefabricated part examples in the embodiment of the application does not need to specially analyze complex character strings, and the method is simple to implement and easy to maintain. The file format can support different engine architectures, can meet the requirement that a part of engines instantiate game objects by taking the combination type of a plurality of components as granularity, and improves the performance of loading scenes and prefabricated parts by the engines.

Continuing with the exemplary structure of the file loading apparatus 455 provided by the embodiments of the present application implemented as software modules, in some embodiments, as shown in fig. 3, the software modules stored in the file loading apparatus 455 of the memory 450 may include:

a first obtaining module 4551, configured to obtain a file to be loaded, where the file to be loaded includes object information of multiple virtual objects, and there is no nested relationship between the object information of the multiple virtual objects;

a second obtaining module 4552, configured to obtain component information of each virtual object from object information of each virtual object, and allocate a memory space in which each virtual object runs based on the object information of each virtual object;

an information filling module 4553, configured to obtain an object type of each virtual object, and perform information filling for a memory space in which each virtual object runs based on the object type and component information of each virtual object;

a hierarchy construction module 4554 configured to construct a hierarchy between the virtual objects based on object information of the virtual objects, and display the virtual objects based on the hierarchy.

In some embodiments, the second obtaining module is further configured to:

In some embodiments, the information populating module is further to:

In some embodiments, the hierarchy building module is further configured to:

It should be noted that, the embodiments of the present application are described with respect to a file loading apparatus, and similar to the description of the method embodiments described above, and have similar beneficial effects to the method embodiments. For technical details not disclosed in the embodiments of the apparatus, reference is made to the description of the embodiments of the method of the present application for understanding.

Embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the file loading method described in the embodiment of the present application.

Embodiments of the present application provide a computer-readable storage medium storing executable instructions, which when executed by a processor, will cause the processor to perform a file loading method provided by embodiments of the present application, for example, a file loading method as illustrated in fig. 4, 5 and 6.

In some embodiments, the computer-readable storage medium may be memory such as FRAM, ROM, PROM, EP ROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

The above description is only an example of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A file loading method, characterized in that the method comprises:

2. The method according to claim 1, wherein the object information includes attribute information and component information of the virtual object, and the obtaining the component information of each virtual object from the object information of each virtual object includes:

3. The method of claim 2, wherein allocating the memory space of each virtual object when running based on the object information of each virtual object comprises:

4. The method of claim 2, wherein the populating information into the memory space of each virtual object during its operation based on the object type and component information of each virtual object comprises:

5. The method of claim 4, wherein determining component fill information for each virtual object runtime based on the object type and component information for each virtual object comprises:

6. The method of claim 4, wherein determining component fill information for each virtual object runtime based on the object type and component information for each virtual object comprises:

7. The method of claim 6, wherein determining component fill information for each virtual object runtime based on the object type and component information for each virtual object comprises:

8. The method of claim 7, wherein determining component fill information for the ith virtual object based on the original component information, the deleted component identifier, and the difference information for the other components comprises:

9. The method of claim 7, wherein determining component fill information for each virtual object runtime based on the object type and component information for each virtual object comprises:

determining component padding information of the i-th virtual object based on the original component information and the difference information of the respective components.

10. The method according to claim 1, wherein the constructing a hierarchy between the virtual objects based on the object information of the virtual objects comprises:

11. A file loading apparatus, characterized in that the apparatus comprises:

12. A computer device, characterized in that the computer device comprises:

a memory for storing executable instructions;

a processor for implementing the method of any one of claims 1 to 10 when executing executable instructions stored in the memory.

13. A computer-readable storage medium storing executable instructions, wherein the executable instructions, when executed by a processor, implement the method of any one of claims 1 to 10.

14. A computer program product comprising a computer program or instructions, characterized in that the computer program or instructions, when executed by a processor, implement the method of any of claims 1 to 10.