Shulou(Shulou.com)06/02 Report--

What are the taboos when using the unity engine, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail, people with this need can come to learn, I hope you can gain something.

In terms of procedure:

Taboo 1: mistakenly think that Unity has the function of Terrain.

Unity doesn't have this feature, and the component you see is a toy, so tell yourself that often. Want to do the big terrain of the open world? OK, do your own Procedural Virtual Texture, do your own quad tree LOD, stream load, Terrain Decal... There will be no Unity, anyway, I am doing this work by myself at the moment, because this component really doesn't work at all. The team needs to do this, don't think too much about pulling a rendering team to do it yourself, after all, their own wheels are reliable.

Taboo 2: use the Resources folder.

My experience tells me that there is no need to use this folder, if it is art resources or Shader, you should use ScriptableObject for global management, and if binary files should be read directly using .net files, this feature is not officially recommended, whether from the implementation efficiency or project management, directly using the address to read project resources seems to be a very inefficient way.

Taboo 3: confuse the relationship between FixedUpdate and Update when writing code.

In fact, the design itself is a very smart design, using a separate fixed frame time for physical calculations. Assuming that the default FixedUpdate is one frame of 20ms, and the actual execution time of each frame is 10ms, then FixedUpdate will execute every two frames, and if the actual execution time of each frame is 40ms, then FixedUpdate will execute twice per frame, so that the physics engine will not have clock problems. So it is wrong to write code such as input and output in FixedUpdate, because FixedUpdate is not executed at all when it is possible to trigger, so the right thing to do is to manage input and output uniformly, send out keyboard and mouse input in the form of message methods, and process messages when FixedUpdate is executed. This point many old programs just transferred to Unity is easy to turn the skin in the sewer, you should pay special attention to it.

Taboo 4: logic is against the main thread.

In fact, now Unity multithreading has been relatively open, and even Transform has a TransformAccess such a thing, and multithreaded computing logic in most of the time can bring significant performance improvement, after all, now four cores are small, six cores and eight cores are almost mainstream. The attribute values of some built-in components, such as Light.intensity {get;set;}, cannot be accessed by threads. However, the calculation of this type of assignment is actually very small, and the most time-consuming calculation logic can be calculated in Job System, which greatly reduces the burden on the main thread.

Taboo 5: extensive memory management.

In general, the high consumption caused by GC is absolutely not allowed in game development. Tens of milliseconds of GC time even if equipped with an I9 processor has to kneel down obediently, while 99% of the high GC consumption actually comes from the developer's negligence. For example, the unmanaged data type can be allocated using the Memory Allocator that comes with the engine. Every time you new, you have to think about whether this new can be reused, whether it will be buried higher and higher like the riverbed of the Yellow River, and the hidden danger will become bigger and bigger, resulting in "dike break" and irreparable and devastating losses. If it is the GC pressure caused by UI, you can consider changing the UI layer source code by submitting a reference to a string rather than a tough deep copy. Generally, the right thing to do is to directly call UnityEngine.Scripting.GarbageCollector to turn off automatic GC, and manually call GC when needed. If the memory is directly blown up during the game, it is ready to split the pot to see who writes the code constantly creating memory garbage, causing memory leaks.

A large number of multi_compile branches are used in taboo 6:Shader.

Multi_compile is an awkward design, and it is a hidden danger that will lead to the huge increase of package volume. If you need to do branch function, it is recommended to use multiple Pass and other operations to reduce the number of multi_compile as much as possible.

Taboo 7: excessive encapsulation of the project.

Excessive encapsulation is a common problem for some inexperienced development teams. Excessive encapsulation is often caused by the distrust among the members of the development team and enables the project to work through multiple layers of protection and restrictions, but this will make the project development efficiency and operational efficiency seriously inefficient. If the boss hires a bunch of low-wage brick movers in order to save costs, and then expects to rely on a small number of experts to do the framework to encapsulate the project so that the bricklayers can honestly move bricks, then the end of this project can be imagined. Anyway, the masters can live anywhere, so if they can't change the boss's mind, make another plan.

Art (TA):

Taboo 1: there are multiple sets of UV when importing the model.

Of course, it is a feasible solution to divide the UV2 in the DCC software. If you divide the UV by yourself, you'd better make the Lightmap directly in the software, and package the Lightmap into a whole piece in the engine, such as TexArray, for the scene. If not to bake the light in advance, try not to divide the UV2 in the DCC.

Taboo 2: use a lot of SubMesh/SubMaterial.

The more expensive part of Drawcall is re-binding material asset properties, that is, SetPass Call, where multiple materials on the same object will force the engine to SetPass Call multiple times at a time. If there is only one material, the engine may unify the surrounding area using the same material for SetPass, and the drawing efficiency can be greatly improved. Therefore, after ensuring that a unified physical-based shading model is used, the types of materials and Shader can be greatly reduced, and SubMesh can be eliminated as much as possible.

Taboo 3: use GPU Skinning cautiously.

The GPU Skinning provided by Unity is weak, and sometimes there is no optimization but negative optimization, which is a problem left over from history. If you want to use the GPU Skinning recommendation to export bone matrix data in Job using the TransformAccess mentioned above, and pass it to Compute Buffer for calculation in Compute Shader, I talked about this in my article:

MaxwellGeng:GPGPU Computing Animation & Skinning zhuanlan.zhihu.com

Https://zhuanlan.zhihu.com/p/50640269

Taboo 4: the model LOD is not handled properly.

Unity's built-in LOD Group component is not practical, after all, it is a very old component. In the actual development process, different LOD methods should be adopted according to the requirements, such as HLOD for buildings with open terrain, dynamic surface subdivision for characters, quadtree for flat terrain and sea surface, etc. Distribution according to demand is the right solution.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.