- Author: admin
- /
- Time: September 23, 2019
- /
- Browse:1285 times
- /
- Category: Accumulate thin hair
1) Terrain scheme comparison
2) Understanding of Batch.DrawInstanced
3) Particle system problem
4) How to locate Physics.Raycast time-consuming
5) How to use code to safely hide a certain part of the Spine role in Unity
This is the 176th UWA technical knowledge sharing push. Today, we continue to select a number of issues related to development and optimization for you. It is recommended that you read it for 10 minutes. After reading carefully, you will be rewarded.
UWA Q&A community: answer.uwa4d.com
UWA QQ group 2: 793972859 (the original group is full)
Terrian
Q: What is the principle of Terrain implementation in Unity? What are the advantages of T4M? Are there other feasible solutions on the mobile platform?
A: The implementation principle of Unity Terrain, this problem is a bit big. However, the subject can be understood as an implementation based on Heightmap, and it will generate different LOD detail layers, and at the same time generate different terrain patches according to different editing operations of the user, and then show different details at different distances. In the past, Unity Terrain was most criticized because it would generate a large amount of Draw Call and Terrain Data after the user edited too much, which made it time-consuming to render on mobile devices, large memory, and time-consuming to load. Therefore, its Not much use in current mobile projects.
However, the Unity engine has greatly improved the Terrain system after 2018.3, and greatly accelerated the rendering efficiency of Terrain through GPU Instancing, and also reduced the Terrain Data data, thereby speeding up the loading efficiency. However, for the specific effect, the subject still needs to try it out according to his own needs. In the current mobile projects, there are still very few projects that use this feature.
The advantage of T4M is that it is simple, open source, and you can change it whatever you want.
As far as the current commercial games are concerned, there are no other more mainstream terrain production schemes yet, which are basically based on T4M. I saw the World Creator tool on GDC before . If the subject is interested, you can try it yourself. The picture below is its production rendering.
It is also recommended to pay attention to Procedual Terrain in the follow-up. With the substantial increase of game scenes, this method will be further applied in large-scale scenes. Related open source libraries stamp this .
The answer is provided by UWA, and everyone is welcome to go to the community to exchange:
https://answer.uwa4d.com/question/5d80d30ff6bfcf23aea6a7e9
Rendering
Q: I see in the UWA performance report that Batch.DrawInstanced takes a lot of time. What does this mean, and how do I generally start?
A: From the picture, I don't see that the Batch.DrawInstanced of your project is very high. On the contrary, it still looks normal.
Batch.DrawInstanced is the time-consuming of GPU Instancing on the CPU side. It is generally done to save Draw Call. Therefore, in most cases, the time-consuming of GPU Instancing is relatively low. However, in some special cases, GPU Instancing rendering of a large number of semi-transparent objects can be time-consuming, which can be very time-consuming. This is the point of our UWA DAY 2019 course "Unity Engine Rendering, UI, Logic Code Module Quantitative Analysis A detailed explanation is given in "And Optimization Methods" , and it is recommended that the subject of the subject go through the overall view when free.
The answer is provided by UWA, everyone is welcome to go to the community to exchange:
https://answer.uwa4d.com/question/5d823fa491262623a9fc7609
Particle
Q: My Unity version is 2017.4.25. Multi-threaded rendering is enabled in the project. Currently, I found an error "Sub-emitters must be children of the system that spawns them". For example: There are 10 special effects in the scene.
A: https://unity.cn/releases/lts/2017/2017.4.31f1
There is a similar one in 2017.4.31:
Shuriken: Fixed erroneous sub-emitter error message. (949522, 1164014)
You can install one and try to see if it works Whether to solve your problem.
Thank you deviljz@UWA Q&A community for providing answers, welcome everyone to go to the community to exchange:
https://answer.uwa4d.com/question/5d6f68acc494b506d2673ba3
Physics
Q: How to locate the time consuming of Physics.Raycast? If we call Physics.Raycast in our code, will it be reflected in the physics module of the performance report? You still need to manually manage to get specific data, because there are still many places to call Physics.Raycast in the code.
A: If you need to manually call the Raycast operation, it is generally recommended that the R&D team directly monitor its performance problems through management.
Not only Raycast, but also for Rigidbody and Character Controller API calls, we recommend monitoring and checking through the above methods.
The answer is provided by UWA, everyone is welcome to go to the community to exchange:
https://answer.uwa4d.com/question/5d79c22d91262623a9fc7524
Animation
Q: If a monster is holding an axe in his hand, the display, hiding, displacement or scaling of the axe is controlled by the animation curve. If I want to use code to hide it at any time, what should I do?
I have tried several ways to achieve partial hiding:
1. Get the Slot where the axe is located, and modify the A value of the Slot to 0. However, this value will be controlled by the animation curve. If there is a key frame for this A value in the animation, the control will return to the animation.
2. Modify ScaleX and ScaleY of Bone of the axe to 0. But encountering the same problem as above, these two values are controlled by the animation curve. Moreover, Bone is static data, and modifying static data does not feel good or safe.
3. Set the axe Attachment to null. Still encountering similar problems as above, this Attachment may be changed back after being called by other interfaces.
There is another method. There is no verification for the time being. A new skin is generated at runtime, and the attachment of the axe is not added to the new skin, and then the skin is switched when it needs to be visible or hidden. But will frequent skin switching have a performance impact? Or is there a better way?
A: Method 1: There is a relatively simple method. After FBX imports the animation, copy the clip file, and then delete the scale curve on the animation corresponding to the axe, so that the clip file will not affect the clip of the axe. The code is controlled at will. But if you check Optimize Game Objects, then if you want to process the animation curve of the axe, you can only modify the copied clip file. If you need to modify the clip dynamically at runtime, it will be more troublesome.
Method 2: Let the artist export the axe separately, mount the code to the hanging point, and process it independently.
Thanks for the simple @UWA Q&A community for providing answers, welcome everyone to go to the community to exchange:
https://answer.uwa4d.com/question/5d6931f080d96a06d776ddb1
That's all for today's sharing. Of course, there is no limit to knowing. In the long development cycle, these problems you see may be just the tip of the iceberg. We have already prepared more technical topics on the UWA Q&A website for you to explore and share together. You are welcome to join in, who loves progress. Maybe your method can solve the urgent needs of others; and the "stone" of other mountains can also attack your "jade".