The full name of DOTS is Data-Oriented Tech Stack, which translates to multi-threaded data-oriented technology stack (DOTS). It consists of three parts: Job System, Entity Component System (ECS), and Burst Compiler.
ECS + JobSystem + BurstCompile = high performance + multithreading + compilation level optimization
DOTS ensures that the same type of components are arranged in order in the memory, which greatly increases the cache hit rate. In addition, with the Job System, developers do not have to worry about the trouble of manually unlocking data when accessing data from multiple threads at the same time, and finally blessing Burst Compiler makes performance fly.
ECS, JobSystem, Burst , these three components can be used independently of each other. It does not mean that one of these three components must be used at the same time. You can choose one of them to use for different application scenarios.
If we need to use JobSystem, in fact, it has nothing to do with ECS. You can use it in ECS or not in ECS. You can use it wherever parallel computing is required.
The same is true for Burst. It does not need to be used with ECS, nor does it need to be used in conjunction with parallel computing. Its function is only to perform compiler optimization for some complex and computationally intensive things to achieve performance improvement.
As long as it is computationally intensive, Burst can be used, as is the synchronous method.
Regarding ECS, there is a big misunderstanding. Maybe everyone thinks that after using ECS, everything can be written in ECS, and they will think about how to implement the business logic of UI using ECS. You don't have to. It doesn't mean to use ECS, everything needs to be done with ECS, but you can choose which part is suitable for writing with ECS according to the project requirements, and the rest still use the traditional object-oriented method. To write, there is no problem, as long as the code is a little combined.
Using the example of ECS in Tides of Darkness, we rendered a large number of monsters through ECS. Monsters in our game usually have a characteristic. A group of monsters is composed of several elites with one or two kinds of minions. You can see that there are only three kinds of monsters in the picture on the right. If you use the default SkinMeshRenderer, there are A very serious problem, there is no way to combine the batch, how many monsters on the screen, how many DrawCalls and the Animator overhead is not small, there is another problem, the GameObject is .Instantiate the overhead is relatively large, if I want to simultaneously If there are 30 or 40 monsters, it will definitely freeze. Using ECS can solve these three problems better.
Use ECS to first bake the entire animation information onto such an animation map, perform skinning operations in the GPU, and then implement the view frustum culling and update the animation system through JobSystem and Burst, and finally we will be in the object-oriented business. The logic block can control ECS Enity. That is to say, for the part of ECS, we only provide the structure of rendering and action, and other parts of the business logic are completely implemented by object-oriented, which is equivalent to each taking their own advantages.
The biggest benefit of using ECS is performance.
First of all, because we use GPU skinning, the number of the entire DrawCall is reduced to a few strange ones, which is a few DrawCalls, which is very good. The instantiation is also very fast. ECS is basically insensitive and consumes on extreme machines. Even if you brush a thousand monsters at the same time, it is less than 1 millisecond. With the help of Burst power, it is similar to culling these computationally intensive operations. It is also negligible on board.
You can see the screenshot below to demonstrate our entire animation update stage, which was also measured on the Snapdragon 450 SoC. In the case of about 100 monsters, the entire animation update process only took 0.008 milliseconds, which is negligible, not at all. An order of magnitude to consider. Through ECS, the rendering of monsters on our screen depends entirely on the rendering performance of the GPU itself, and the CPU overhead does not need to be considered at all, so there will be no lag.
Second, we use the Jobsystem to achieve the effect of the monster knocking up. You can see that the monster was knocked off the cliff. If it hits the wall, it must be blocked by the wall, and some physical calculations are required. If you use Unity directly Ragdoll is a ragdoll system, and its physical calculation is very complex, which causes a relatively large performance burden for low-end opportunities. We simplified this process a little bit. All these monsters are using pre-made animations when they are knocked into the air, and we only need to calculate their trajectory.
We first use Job to calculate the analysis trajectories of these monsters in parallel, and then use the multi-threaded Raycast method provided by Unity to perform ray detection to determine whether it hits a wall or hits the ground. Finally, if we still have some non-ECS objects, we can synchronize the positions of all GameObjects through a separate Job after the calculation is completed.
The third, what we achieved through Burst is the ray skill, which looks very simple, but actually needs to interact with the entire scene and all monsters and other objects. Rays hitting the wall can generate reflections in real time. Our thing needs to perform ray detection on the entire scene every frame. The entire calculation process is actually relatively expensive. Through Burst, we are equivalent to making this thing into a Job, and calling it directly through the Job.Run method is the operation performed on the current thread.
Using it is not much different from a static method, and as you can see, there will be a large number of bullets, and we also need to calculate the running trajectory of these bullets. Burst is very effective to reduce these two computational costs to a very low level. After Burst is enabled, its performance can be improved by hundreds of times. By implementing synchronous calls in the way of Job.Run just mentioned, we do not You need to open an additional thread, directly in the current thread, and a single static method can be called directly, which is also very convenient.
You can take a look at the difference between enabling and not enabling the Burst effect. The left side is enabled and the right side is not enabled. We tested it in a computational system model tool. The left side only took 241 milliseconds, and the right side took 20 milliseconds, which is a hundred times faster. difference. Instead of saying that it uses multiple threads to make it faster, you can see that each thread is 100 times faster. If you calculate the total time, it took 143 seconds here, and only 1 second here. The time of the thread adds up, which is a 100-fold difference, and the effect is very obvious.
What projects use Dots?
Projects with lots of operations of the same type, e.g. RTS, SLG, minecraft type block sandbox.
The Dots solution can only be optimized for the CPU for the time being, and the GPU direction is looking forward to the follow-up plan of Unity.
Burst is currently still in Preview, and there may be many pits in the official project.
https://aladdin.blog.csdn.net/article/details/105081530
A Brief Analysis of Unity DOTS Technology - IT's Blog - CSDN Blog
[Unity Events]-Unity DOTS Technology Detailed Explanation- Xuan Yusong _ beep mile _bilibili
ILRuntime author Lin Ruofeng shares: how to render next-generation mobile games – yqqlm
Unity2019 Dots first test - Hello Captain - CSDN Blog
Unity DOTS learning tutorial summary_Learning endless column - CSDN Blog
An introduction link to an ECS-like design paradigm: https://pan.baidu.com/s/1hH3YwgPvB9m39_e3HzlAcA Extraction code: 5wwm