Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in this application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise, the "plurality" generally includes at least two.
The words "if", as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination" or "in response to a detection", depending on the context. Similarly, the phrase "if determined" or "if detected (stated condition or event)" may be interpreted as "when determined" or "in response to determination" or "when detected (stated condition or event)" or "in response to detection (stated condition or event), depending on the context.
In addition, the sequence of steps in the method embodiments described below is only an example and is not strictly limited.
Fig. 1 is a flowchart of an engineering project configuration method provided in an embodiment of the present invention, where the method may be applied to a terminal. As shown in fig. 1, the method comprises the steps of:
101. In response to an operation of creating the target engineering project, a function package list which is currently published in the cloud is displayed, wherein the function package list comprises a plurality of function packages, and the function packages are used for providing graphics rendering related functions in a graphics engine.
102. In response to a selection operation of a target feature pack in the feature pack list, a first feature pack on which the target feature pack depends is determined.
103. And downloading the target function package and the first function package from the cloud.
104. Importing the target function package and the first function package into a graphic engine, and generating a target engineering project based on the imported target function package and the first function package configuration.
In the embodiment of the invention, an engineering project configuration method will be described, and before the configuration method is actually described, several concepts will be described first to facilitate a deep understanding of the method provided by the embodiment of the invention.
In the embodiment of the invention, the concept of the functional package is provided, and codes of all functional modules are not scattered any more and are organized into the functional package according to a certain rule. The feature pack provides a certain function that can be implemented in the graphics engine, and if the technician needs to use the function provided by the feature pack, the corresponding feature pack can be installed in the graphics engine, and if the technician no longer needs to use the function provided by the feature pack, the feature pack can be removed from the graphics engine, so that the graphics engine is more lightweight. That is, the graphics engine is pluggable.
In practical applications, functional modules in the graphics engine may be abstracted to modules, and functional units may be abstracted to components. Wherein a plurality of functional units may be considered as constituting a functional module, the functional units being arranged to implement a certain sub-function of the functional module. FIG. 2 is a schematic diagram of the relationship among a graphics Engine (Engine), functional modules, functional units, and objects (objects). As shown in the figure, a plurality of functional modules form a graphic engine, a plurality of functional units form functional modules, and the functional units in different functional modules are commonly applied to the same engineering project. The functional modules are mutually different, so that the coupling degree is reduced to the minimum. The technician can define the behavior of an object by combining functional units, while the back of each behavior is actually responsible for execution by the corresponding functional module.
Although the use of a reasonable architecture can reduce the degree of coupling between functional modules, the coupling cannot be completely eliminated. For example, it is difficult for the edit display module, the resource processing module, and the serialization module to be unassociated with a new function module. The components defined in the functional modules need to be serialized, interface edited and even new resource types need to be introduced, and the requirements of the functional modules need to increase the coupling degree with other functional modules. Thus, there is a need to control these necessarily existing couplings by reasonable means in order and controllable.
When function module A is to use certain functions to function module B, the logic of function module B may be invoked at the appropriate time by a callback event. Specifically, the main body of the graphic engine can send out callback events at a proper time, the functional module can monitor the callback events, and when the functional module monitors the callback events, the functional module can respond to the operation logic of the main body of the graphic engine. Wherein the execution logic may refresh the display in the screen frame by frame. The function modules needing to be associated can also be associated at a proper time in a mode of monitoring callback events.
In practical application, when the association relationship between the function modules is relatively simple, callback events can be adopted to enable the function modules to generate association at proper time. In another application scenario, when the association relationship between the function modules is complex, if the function modules are associated together by adopting a callback event mode, the operation is complicated, and at this time, a plurality of function modules with complex association relationship can be associated by adopting a broadcast interface mode.
Specifically, as shown in fig. 3, the functional module may inherit, rewrite, and register the functions of the interface class into the manager. At the appropriate time, the manager will broadcast an event signal, triggering callback of all registered interface classes. The mode of adopting the broadcast interface class is more complex than the mode of adopting callback events, but can directly expose all the occasions of the callbacks which can be injected in the functional module, thereby being convenient for technicians to use.
In the embodiment of the invention, the function module is independently injected into the main body operation logic architecture of the graphic engine, and the architecture of the pluggable graphic engine can be realized through the function module which is connected with callback event and broadcast interface type specification. Through pluggable graphics engines, the feature pack can be installed or removed as desired.
The related concepts of the feature pack are described below.
The functional package in the embodiment of the invention can separate the functional modules from the physical layer. A functional package may include a plurality of functional modules, may include only one functional module, and may even include only a resource file. When only a resource file is included in a function package, the function package may also be referred to as a resource package. When a feature pack contains a plurality of feature modules, each feature module can implement its own function as described above, and the combination of these features can implement a larger overall function that the feature pack can implement in the graphics engine.
In practical applications, there are many ways in which the functional modules can be divided into the same functional packages. For example, different functional modules developed at the same time can be put into the same functional package according to development time, or different functional modules which can be applied to the same application scene can be put into the same functional package according to the application scene.
There may be dependencies between different functional packages. The dependency relationship means that some file contents in the functional package B are declared to be used in the functional package a, and then the functional package a depends on the functional package B, and the functional package B depends on the functional package a, so that the file contents applied by the functional package a in the functional package B need to be contained in the corresponding file of the functional package a.
A plurality of different types of files may be included in a feature pack, the different types of files together forming the feature pack. A functional package may include code files, resource files, library files, test cases, etc. for all of the functional modules that it contains.
As shown in fig. 4, a structural example of a feature pack is provided. In this example, the feature package may include code files, library files, resource files, examples, documents, description files, change logs, and license regulations. Wherein the code file includes an editor code and an execution code. The editor code is an implementation of the functional modules contained in the feature pack on the editor of the graphics engine so that it can customize the manner in which it is displayed and manipulated on the editor. The running code is a carrier of main functions of the function modules contained in the function package, and needs to be run both at the time of scene editing and at the time of release.
The foregoing introduces that there may be a dependency relationship between the function packages, which file contents in a certain function package may be relied on by other function packages, and which file contents may not be relied on by other function packages, and may be sequentially described in public, private in the inclusion directory. public allows the current feature pack and the feature pack dependent on the current feature pack to be included, private allows only the current feature pack to be included. By the method, the file content exposed to the outside in the functional package can be effectively managed.
Other library files in the feature package may be package-imported third party library content. The resource file may contain resources that need to be imported with the feature package, which may be texture images, for example. When there is no resource file in the feature pack, the feature pack is a pure code pack for implementing the feature logic. In addition, as described above, the function package is allowed to contain only the resource file, and the function package exists as a resource package only for managing the resource.
An example in a feature pack is a file that draws the example code and the example resource separately for exposing the use case to a technician desiring to use the feature pack. The document mainly describes design, use, or redevelopment considerations of the feature pack. The description file is used for describing the content, version, dependency relationship and the like of the function package, and is a file of the docking package manager. The description file may have a fixed format and entries that can facilitate retrieval of the feature pack by the graphics engine. The change log describes changes made by the feature pack relative to the previous version of the feature pack. The license regulations are used to describe the license conditions for using the package.
The above describes the architecture of the pluggable graphics engine and the relevant content of the composition of the package, on the basis of which a free access of functional packages to the graphics engine is possible. It will be appreciated that the operation of an engineering project depends on the functionality provided by at least one feature pack in the graphics engine. In the embodiment of the invention, the graphic engine does not support all functions by default, but splits various functions into various functional packages, and when a technician needs to use which function in a certain engineering project, the corresponding functional package can be installed.
Specifically, the technician may be guided to create the target engineering project in the interface, and when the target engineering project is created, the technician may be guided to input necessary or optional information corresponding to the target engineering project in the interface, and after the input is completed, the technician may click on the creation control. In response to the operation of creating the target engineering project, a list of function packages that have been currently published in the cloud may be presented in an interface, where the list of function packages may include a plurality of function packages that may be developed and published in the cloud by a current technician or other technician. It will be appreciated that the feature pack available from the cloud is one that the developer of the feature pack would like to use for other technicians either gratuitously or in a paid sharing.
The technician may select a target feature pack to be used in the feature pack list. In some optional application scenarios, in order to enable a technician to know the functions supported by the function packages in the function package list so as to facilitate selection, description information of the function packages may be added under entries corresponding to the respective function packages, or resources, examples, etc. in the function packages may be displayed, so that the technician can quickly grasp the roles of the respective function packages in the function package list, how to use them, which resources are involved, etc. through the information.
In addition to the above, to facilitate selection by the technician, the feature pack may be displayed by category. Based on the above, optionally, displaying a function package list according to the classification of the function packages which are currently published in the cloud; the classification of the function packages comprises a built-in type function package and an extension type function package in the graphic engine, a development version function package and a formal release version function package, a static library link type function package and a dynamic library link type function package.
In the embodiment of the invention, three specific ways of dividing the functional package are provided, and in practical application, the functional package can be divided according to actual requirements in other ways.
In practical applications, the function packages may be divided into a built-in type function package and an extended type function package. The division is determined according to the relation between the functional package and the graphic engine: the functions supported by the graphic engine can be theoretically split into function packages, but the functions of some function packages are difficult to be removed from the graphic engine or the cost of the functions of the function packages is higher than the benefit of the removal, such as a rendering module, a display and editing module and the like, and the function modules are needed for almost every engineering project. Similar to the above-mentioned function modules with high use frequency can be divided into the function packages of built-in type, and other function modules can be correspondingly divided into the function packages of extended type. For built-in type feature packs, they may still be accessed into the graphics engine in the form of a feature pack, but disabling the technician from removing them may allow the technician to disable them.
The feature pack may be further divided into a development version feature pack and a formal release version feature pack. Specifically, the function package may be divided into a development version of the function package and a formal release version of the function package according to whether the development of the function package is completed. For the development version of the functional package, the header file and the source file are included in the functional package, so that the technical personnel can be helped to continue developing the functional package. For the functional packages of the formal release, the technicians are not concerned about how they operate to implement the functions they support, and only want to download, install and use these functional packages conveniently, so that the compiled library files can be provided in the functional packages of the formal release.
Furthermore, the function packages may be divided into a static library link type function package and a dynamic library link type function package. The static library linking mode and the dynamic library linking mode of the function package directly influence the use experience of technicians, and even influence the range of the technicians who use the function package, so that the function package can be divided in the linking mode of the function package, and the technicians can know the linking mode of the used function package.
The technician may select a target feature pack from the feature pack list according to the use requirement. In response to a selection operation of the target feature pack, the device may determine a first feature pack on which the target feature pack depends. It should be noted that, as described above, one feature pack may depend on another feature pack, and when the target feature pack depends on the first feature pack, a specific operation manner indicating that the target feature pack is applied to some file content in the first feature pack, for example, a certain piece of code in the target feature pack is defined in the first feature pack.
Since the dependency relationship is allowed between the function packages in the embodiment of the present invention, it may be determined whether the target function package depends on the first function package after the technician selects the target function package. If such a first package is present, the first package may be added directly to the download list along with the target package. Thus, a technician can obtain the target function package and the first function package at the same time, so that the obtained function packages are guaranteed to be comprehensive, and the function packages can be guaranteed to normally run.
After the target function package and the first function package depending on the target function package are selected, the target function package and the first function package can be downloaded from the cloud. The technician may then be directed to invoke the feature pack import interface so that the device can automatically import the target feature pack as well as the first feature pack into the graphics engine. After the target feature pack and the first feature pack are successfully imported, a target engineering project may be generated based on the imported target feature pack and the first feature pack configuration.
The manner in which the function package list is displayed to the technician is described, and the technician selects the target function package in the function package list, in another possible implementation manner, optionally, a plurality of prefabricated scenes and application resources and application examples corresponding to each prefabricated scene may be displayed; determining at least one second function package corresponding to a target prefabricated scene in response to a selection operation of the target prefabricated scene in the plurality of prefabricated scenes; downloading a second function package from the cloud; and importing the second functional package into a graphic engine, and generating a target engineering project based on the imported second functional package configuration.
In order to further improve the automation degree of function package selection, some prefabricated scenes can be set, application resources and application examples corresponding to the prefabricated scenes are provided for technicians, so that the technicians can know what resources are used by the prefabricated scenes and what can be done by utilizing the prefabricated scenes, and further the technicians can select proper prefabricated scenes according to requirements. For example, in a preset scenario of a building model, a building design template may be applied, in which a PBR (physical-Based Rendering) Rendering package, a UI (User Interface Design, user interaction interface) display package, an FBX (popular 3D data exchange format) pipeline package, and the like may be integrated.
It should be noted that, the prefabricated scenes and the function packages are bound, that is, in order to realize what prefabricated scenes need to use which function packages are fixed, when a technician selects a target prefabricated scene, a second function package corresponding to the target prefabricated scene can be automatically downloaded from the cloud. The technician may then be directed to invoke the feature pack import interface so that the device can automatically import the second feature pack into the graphics engine. After the second feature pack is successfully imported, a target engineering project may be generated based on the imported second feature pack configuration. It will be appreciated that the second feature pack should be comprehensive, including all dependent feature packs.
Compared with the mode of enabling technicians to select target function packages in the function package list, the mode of directly providing the prefabricated scenes for the technicians to select is more convenient and visual.
A specific implementation of importing a functional package and generating a target engineering project will be described below. Alternatively, the process of importing the target function package and the first function package into the graphics engine, and generating the target engineering project based on the imported target function package and the first function package configuration may be implemented as follows: determining first dependency information corresponding to the target function package and second dependency information corresponding to the first function package; determining whether the function package relied on by the target function package and the function package relied on by the first function package are all imported to the graphic engine or not based on the first dependency information and the second dependency information; if the function package relied on by the target function package and the function package relied on by the first function package are all imported into the graphic engine, acquiring engineering description files corresponding to the target function package and the first function package; and creating a target engineering project in the graphic engine based on the target functional package and the engineering description file corresponding to the first functional package, and registering the running codes in the target functional package and the first functional package to the graphic engine.
Referring to fig. 5, in order to access the target function package and the first function package into the graphic engine, first, the target function package and the first function package may be optionally decompressed to a first designated location. In addition, optionally, it may also be checked whether the decompressed target function package and the first function package include a file of a preset type, and whether the content of the file of the preset type meets the specification. The file of the preset type may be the description file described above. If the decompressed target function package or the first function package does not contain the description file of the specification, the target function package or the first function package fails to be accessed.
If the decompressed target function package or the first function package contains the canonical description file, the description file can be read to obtain the type, file format, version number, dependency relationship information, platform related information and the like of the target function package or the first function package recorded in the description file.
The decompressed target package and the first package may then optionally be checked for integrity and version conflict issues based on the content recorded in the description file. If the verification is not passed, the target function packet and the first function packet fail to be accessed.
Then, it can be checked whether the dependency items of the target function package and the first function package are complete according to the dependency information recorded in the description file. Wherein, whether the dependent item is complete refers to whether the target function package and other function packages on which the first function package depends are all imported into the graphics engine.
Theoretically, after the technician selects the target package, the cloud should automatically pull the target package and all packages it depends on into the download list, so the dependencies should be complete. It should be noted that the first function package on which the target function package depends may also depend on other function packages, and the target function package, the first function package, the other function packages and the function packages on which the further depended function package are further depended should be downloaded together into the device, so that it is ensured that the dependency check can be passed.
In practice, there are default provided but not required feature packages in the graphics engine that are not installed by default into the target engineering project. However, if the target or first feature pack is dependent on the default feature pack, the technician may manually import the dependent feature pack into the graphics engine, or the graphics engine may automatically import the dependent feature pack.
Optionally, after the target functional package and the first functional package are successfully imported, a dependency graph may be updated, where the dependency graph describes dependency information between all functional packages added in the graphics engine corresponding to the target engineering project; and generating a target function package and an engineering description file corresponding to the first function package based on the updated dependency graph.
In the dependency graph, a ring structure is not allowed to appear, for example, the function package a depends on the function package B, the function package B depends on the function package C, and the function package C depends on the function package a, so that the dependency of the function package A, B, C forms a ring structure. One feature pack in the dependency graph may depend on a plurality of other feature packs, and different feature packs may cross-depend.
In practical application, after updating the dependency graph, the manager may regenerate the target function package and the external engineering description file (cmakelists. Txt) corresponding to the first function package according to the updated dependency. It should be noted that, when there are multiple functional packages recursively imported into the graphics engine, it is necessary to ensure that the step of regenerating the outer layer cmakelist. Wherein cmakendss txt describes the creation location of the target project, how to create, etc. information.
Finally, a CMake instruction can be called, and the target engineering project is generated through reconfiguration of the target function package and the outer layer CMake Lists.
The way of accessing the target function package and the first function package to the graphics engine is described above in general, and in theory, the target function package and the first function package need to be accessed to the graphics engine through two aspects, including engineering access and code access.
The problem that engineering access mainly solves is how to access the running code and library files of the target functional package and the first functional package to a graphic engine so that the target engineering project can link the target functional package and the first functional package within the target engineering project when the target engineering project is configured and generated.
To solve this problem, embodiments of the present invention use a CMake (CMake is a cross-platform installation (compilation) tool, and simple statements may be used to describe the platform installation (compilation) process) to manage engineering projects. The CMake has flexible grammar, stable function, convenient automatic generation and adjustment and is suitable for various code languages and platforms. When the target function package and the first function package are accessed in the graphic engine, the CMake can be used for inquiring whether the access mode of the target function package or the first function package is dynamic or static, whether the organization type of the target function package or the first function package is pure code or a combination of running code and library files, and the like. Because the dependency relationship between the target function package and the first function package is determined in advance, in the process of accessing the target function package, the library file on which the target function package depends can be directly inquired through the CMake and automatically contained, so that the process is automated to improve the operation efficiency, and meanwhile, the use cost can be reduced.
After engineering access, in order for the functional module to function properly, a code access process is also required to complete to embed the functional module into the body operating logic of the graphics engine. In general, graphic engines are developed in the c++ language in most cases, and the reason why the c++ language is used is that the language is powerful, deep into the bottom layer, and has high operation efficiency. The embodiment of the invention also provides a C++ code access method, so that the scheme provided by the embodiment of the invention has universality. Because the graphics engine uses a modular organization and has a pluggable architecture, if the target function package and the first function package need to be accessed, the graphics engine is equivalent to a plurality of function modules accessing the target function package and the first function package.
Specifically, the body architecture of the graphics engine provides a base class IModu for all functional modules and adds virtual interfaces for initialization, updating, destruction, etc. for the IModu. A new functional module can be easily written by inheriting from the IMmodule. In addition, since all the function modules come from the same parent IMmodule, a register module interface can be realized for the parent pointer, and the register module interface is responsible for registering new function modules with the graphic engine and transmitting dependency information such as the priorities of the function modules in interface parameters. The operation of the function modules depends on the unified interface Update of the parent IMod, the graphic engine can Update all the function modules in the main body operation logic, and the updating sequence of each function module is determined by the priority of the function module, and the priority can be determined by the developer of the function module.
The above describes how the target function packet and the first function packet are accessed into the graphics engine, and the manner in which the second function packet or other function packets are accessed into the graphics engine is the same, and the description thereof will not be repeated. In some alternative embodiments, when the function provided by the target function package and the first function package is no longer needed, the files in the target function package and the first function package are correspondingly supported to be removed from the graphic engine, so that the graphic engine is lighter.
In some alternative embodiments, the technician may be guided to create a feature pack in addition to the target engineering project. When the cloud end does not have the function package meeting the use requirement of the technical personnel, the technical personnel can also select the self-development function package. Alternatively, the process may be implemented as: responding to the operation of creating the third functional package, obtaining a necessary file corresponding to the third functional package, wherein the necessary file at least comprises a header file and a source file; acquiring a description file corresponding to the third functional package; and generating an engineering description file corresponding to the third functional package based on the acquired file, wherein the engineering description file is used for accessing the third functional package to the graphic engine from engineering.
In practical application, a technician can be guided to establish a third functional package in an interface according to the prompt, and the equipment responds to the operation of establishing the third functional package, and can prompt the technician to input necessary files corresponding to the third functional package, wherein the necessary files at least can comprise header files and source files, and are necessary files when the third functional package operates. Of course, the technician can optionally enter more files than those listed above.
In addition, the technician can be guided to enter the description file corresponding to the third functional package, wherein the function of the description file and the content of the file are introduced in the foregoing, and are not repeated here.
After all files are entered, the technician may click on the confirmation control. The device may invoke an interface to create an engineering description file in response to a triggering operation of the validation control to automatically generate an engineering description file corresponding to the third functional package based on the obtained file. The third feature pack may be engineering accessed to the graphics engine via the engineering description file.
In further alternative embodiments, the technician may also derive the installed feature pack from the graphics engine. Based on this, alternatively, the process may be implemented as: creating an engine built-in compression packet in response to an export operation for a fourth function packet imported in the graphic engine; determining a file path corresponding to the fourth functional package; searching files belonging to the fourth functional package based on the file path; storing the searched file into an engine built-in compression packet and outputting the file to a designated position.
In practical applications, if the technician considers which function packages (fourth function packages) in the graphics engine are better used, the interface for exporting the fourth function packages can be triggered to be invoked. The device responds to the export operation of the fourth functional package, an engine built-in compression package can be created, then a file path corresponding to the fourth functional package is obtained, files belonging to the fourth functional package are searched one by one based on the file path, and finally the searched files are placed in the engine built-in compression package and output to a designated position. Here, the engine built-in compression package and the fourth function package may be understood as package files including the same file.
In an alternative embodiment, the exported engine built-in compression package may also be shared for use by other technicians. Based on this, alternatively, the process may be implemented as: and uploading the built-in compression packet of the engine to the cloud end in response to the uploading operation of the built-in compression packet of the engine.
By the method, the engine built-in compression package can be shared to the cloud, so that the engine built-in compression package can appear in the function package list for other technicians to select.
In practical application, except that the engine built-in compression package can be shared to the cloud, if a technician writes a third function package by himself/herself, the third function package can also be uploaded to the cloud, and thus other technicians can also use the third function package.
It should be noted that the cloud end may check the engine built-in compression package or the third function package uploaded by the technician to determine whether the engine built-in compression package or the third function package includes a complete file, for example, check whether the engine built-in compression package or the third function package includes a description file, etc. If the engine built-in compression package or the third functional package comprises a complete file, the uploading is successful. If the engine is internally provided with a compression package or a third functional package lacks files, a technician can be prompted to fill up the lacking files and upload the files again.
By adopting the invention, the function modules can be freely organized into the function packages by realizing the architecture of the pluggable graphic engine, and then the function packages can be freely imported into the graphic engine according to the use requirement. The degree of coupling between the functional modules is minimized and each functional module can be injected independently into the graphics engine. When the target engineering project is created, a proper target function package can be selected according to the specific application scene of the target engineering project. While downloading the target function package, it is checked whether the target function package depends on the first function package, and if such a function package exists, the first function package is downloaded to the device together. Therefore, the target function package and the first function package can be orderly installed in the graphic engine according to the dependency relationship, so that the normal operation of the target function package and the first function package is ensured, and the success of the creation of the target engineering project is further ensured.
An engineering project configuration apparatus of one or more embodiments of the present invention will be described in detail below. Those skilled in the art will appreciate that these engineering project configuration apparatuses may be constructed using commercially available hardware components configured by the steps taught by the present solution.
Fig. 6 is a schematic structural diagram of an engineering project configuration apparatus according to an embodiment of the present invention, as shown in fig. 6, where the apparatus includes:
the display module 61 is configured to respond to an operation of creating a target engineering project, and display a function package list that has been currently published in the cloud, where the function package list includes a plurality of function packages, and the function packages are used to provide graphics rendering related functions in a graphics engine;
a determining module 62, configured to determine, in response to a selection operation of a target function package in the function package list, a first function package on which the target function package depends;
a downloading module 63, configured to download the target function package and the first function package from the cloud;
an importing module 64, configured to import the target function package and the first function package into the graphics engine, and generate the target engineering project based on the imported target function package and the first function package configuration.
Optionally, the importing module 64 is further configured to:
displaying a plurality of prefabricated scenes and application resources and application examples corresponding to the prefabricated scenes;
determining at least one second function package corresponding to a target prefabricated scene in the plurality of prefabricated scenes in response to a selection operation of the target prefabricated scene;
downloading the second function package from the cloud;
and importing the second functional package into the graphic engine, and generating the target engineering project based on the imported second functional package configuration.
Optionally, the display module 61 is configured to:
displaying the function package list according to the classification of the function packages which are released at the cloud end at present;
the classification of the function packages comprises a function package of a built-in type and a function package of an extension type in the graphic engine, a function package of a development version and a function package of a formal release version, a function package of a static library link type and a function package of a dynamic library link type.
Optionally, the apparatus further includes a creation module, configured to:
responding to the operation of creating a third functional package, and acquiring a necessary file corresponding to the third functional package, wherein the necessary file at least comprises a header file and a source file;
Acquiring a description file corresponding to the third functional package;
and generating an engineering description file corresponding to the third functional package based on the acquired file, wherein the engineering description file is used for accessing the third functional package to the graphic engine from engineering.
Optionally, the apparatus further comprises a deriving module, configured to:
creating an engine built-in compression packet in response to an export operation for a fourth function packet imported in the graphic engine;
determining a file path corresponding to the fourth functional package;
searching files belonging to the fourth functional package based on the file path;
storing the searched file into the built-in compression package of the engine, and outputting the file to a designated position.
Optionally, the device further includes an upload module, where the upload module is configured to:
and uploading the built-in compression packet of the engine to the cloud end in response to the uploading operation of the built-in compression packet of the engine.
Optionally, the importing module 64 is configured to:
determining first dependency information corresponding to the target function package and second dependency information corresponding to the first function package;
determining whether a function package on which the target function package depends and a function package on which the first function package depends are all imported to the graphics engine based on the first dependency information and the second dependency information;
If the function package relied on by the target function package and the function package relied on by the first function package are all imported to the graphic engine, acquiring engineering description files corresponding to the target function package and the first function package;
and creating the target engineering project in the graphic engine based on the target functional package and the engineering description file corresponding to the first functional package, and registering the running codes in the target functional package and the first functional package to the graphic engine.
Optionally, the importing module 64 is configured to:
updating a dependency graph, wherein the dependency graph describes dependency information among all function packages added corresponding to the target engineering project in the graphic engine;
and generating the target function package and an engineering description file corresponding to the first function package based on the updated dependency graph.
The apparatus shown in fig. 6 may perform the engineering project configuration method provided in the foregoing embodiments shown in fig. 1 to 5, and detailed execution and technical effects are referred to the description in the foregoing embodiments and are not repeated herein.
In one possible design, the structure of the project configuration apparatus shown in fig. 6 may be implemented as a terminal, as shown in fig. 7, where the terminal may include: a processor 91 and a memory 92. Wherein the memory 92 has executable code stored thereon, which when executed by the processor 91, causes the processor 91 to at least implement the engineering project configuration method as provided in the embodiments of fig. 1 to 5 described above.
Optionally, the terminal may further include a communication interface 93 for communicating with other devices.
In addition, embodiments of the present invention provide a non-transitory machine-readable storage medium having executable code stored thereon, which when executed by a processor of a terminal, causes the processor to at least implement the engineering project configuration method provided in the embodiments shown in the foregoing fig. 1 to 5.
The apparatus embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
From the above description of the embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by adding necessary general purpose hardware platforms, or may be implemented by a combination of hardware and software. Based on such understanding, the foregoing aspects, in essence and portions contributing to the art, may be embodied in the form of a computer program product, which may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The project configuration method provided by the embodiment of the invention can be executed by a certain program/software, the program/software can be provided by a network side, the terminal mentioned in the previous embodiment can download the program/software into a local nonvolatile storage medium, and when the terminal needs to execute the project configuration method, the program/software is read into a memory by a CPU, and then the CPU executes the program/software to realize the project configuration method provided in the previous embodiment, and the execution process can be referred to as schematic in fig. 1 to 5.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.