As we all know, the main components of unity3d are scene graphs. nodes in the scene graphs constitute a tree.
Each node corresponds to a gameobject object.
Then each gameobject has several components.
Some components are related to resources. For example, meshrenderer associates materials with shader and texture.
A part of the scenario diagram can be saved as a preset, prefab.
Sometimes we need to use presets for reuse, and the preset loading seems to be only packaged through AB. In fact, we have an open source library to solve this problem.
Why not use AB? refer to the previous article, loading (1). If AB is not used, all resources are unified on the platform, and there is no painful packaging time, the resource dependency is easy to handle.
Code in GitHub https://github.com/lightszero/easydown
The unity_sceneexport demo scenario is generated.
Unity demo scenario loading.
I. file generation
Let's edit a scenario at will.
Then, select the node and import the gameobject component and myjson component.
One more item is displayed on the menu. Click it.
All nodes are displayed. Click parser.
Note that because names are important information, duplicate names may affect the export process. Ensure that object names at the same level are not repeated.
Modify it and then export it.
The preset is exported to the custom format. Then easydown can load the scenario without using AB.
These files will be generated later.
Ii. File Loading
There is such a line in the example. Please analyze the specific design freely.
If this scenario is executed normally, it will be loaded.
Iii. Analysis
It is easy to use and load, but you will be curious about how to complete it.
You can analyze the code on your own. Let's analyze the general idea here.
The scenario tree and the information of each component are saved in a JSON format.
Then, some special processing is done here for saving the component, because the component parameters may be associated with other components on the tree or gameobject. There is another relational table here.
Finally, some reusable resources, such as textures and models, are stored independently.
A Layout dependency resource is also exported for the layout.
In this way, the layout file is loaded first, and then the corresponding resources are loaded Based on the dependency file.
Finally, the layout file is restored to the scenario tree.
This is not something that can be solved by a framework. Because we cannot use the official serialization and restoration methods of components, we need to write a processing program for each component.
In this example, the processing program of the components involved in rendering a model has been introduced.
In our project, this framework is used to scatter every interface of ngui.
Since open-source projects cannot carry ngui, I have commented out these components temporarily, but you can find them from GitHub projects.
In addition, I wrote another framework for this demonstration, and made some modulation in the original code. The ngui component processor may have to be slightly rewritten.
However, for those who can thoroughly understand this mechanism and understand this framework, this is nothing.