0/ 41/ /0

This time we will share several technical topics which are related to Program development. It is recommended to read for 15 minutes. Any unique insights or discoveries, please feel free to contact us or discuss.



Q1: I use two cameras to see the same object. When RenderPipelineAsset in Graphics is not set, two models can be seen normally in Game view. But once RenderPipelineAsset is set, two models cannot be displayed normally, only one can be seen. So does this RenderPipeline need any special settings?


As shown in the figure, in the Game view at the bottom, we can only see the content of the first camera. I set the “depth only” for both cameras.

Are you using LWRP? LWRP does not support the way of drawing multiple camera contents into the same view as in built-in, but the drawing of each camera to its own viewport (by adjusting view port rect) still works normally. The reason for not supporting this to be called Multi-Camera Tracking:


Therefore, the previous bypass method is to draw a Camera to RenderTexture firstly, but it seems that the new version of LWRP has made a Camera Tracking System to achieve similar functions. You can refer to:

Thanks to Len for providing the answer above.


Q2: There is a requirement here, I divide a large map into several small pieces, the purpose is to facilitate artists to operate, and then bake a single small map to generate NavMesh. NavMeshLink provided by Unity needs to be equipped with points, which is not convenient for operation. Is there any other way?

Unity’s native system still has too few to API. You can try this plugin A* Pathfinding Project Pro. It is a complete RecastNavigation implementation of C # version. It also contains traditional Grid pathfinding, so you can control more; As for For this dynamic NavMesh, you may consider trying TileMesh. For details, you can check TileMesh in RecastDemo, which can be created one by one on demand.

Thanks to Yaukey for providing the answer above.


Q3: In UGUI ScrollRect, if I want to load a large number of pictures from the server (the size of the picture is not large), should I use RawImage to display, or create Sprite to display with Image? The pictures themselves may have been uploaded by users themselves, so they cannot be packaged into atlases in advance. I would like to ask, what is the general practice?

1. First, use ScrollRect which has higher performance, such as LoopScrollRect and Super ScrollView.


2. Secondly, the server needs to pre-process pictures uploaded by users to standardize the picture size and format.


3. If the UI interface will be frequently swiped by the user, the dynamic generation of the atlas will not be considered, RawImage is superior to Image, because Sprite is an abstract area on Texture, and it needs to be created on the basis of Texture, directly using Texture can save this step .


4. If the UI interface is still for a long time and the pressure of DrawCall is large, you can use the RuntimeAtlas program to reduce DrawCall, then use Image at this time.

For 3 and 4, can I understand like this: Using RawImage actually saves the consumption of Sprite.Create, and the Sprite created at runtime cannot specify the Packing Tag, so it cannot be directly packaged into an atlas, and it cannot be batched in fact. There is a question here. For UI, since the Sprite created by Sprite.Create () cannot be batched, is this process unnecessary? If I really need to package to the atlas, I need to use a similar solution like Runtime Atlas.

Yes, if the Texture has only one sprite of the same size, it is really superfluous. Sprite can be regarded as the encapsulation and utilization of the Texture area, such as achieving the nine-grid stretching by border, setting anchor points, etc.. If you simply want to display the entire image, you can use Texture.

Thanks to Zhang Di for providing the answer above.


Q4: What is this Text.get_cachedTextGenerator, why does it take up so much memory?

It will be called every time Text is instantiated or active. It can be speculated from the stack information that it is likely that a large number of Text components will be active when click it, resulting in a high mono memory allocation. It is recommended that you examine the mono memory allocation diagram and check whether the allocation is reasonable according to the specific screenshot.

This answer is provided by UWA


Q5: In the same frame, I find that the data in the Profiler, Stats and the Frame Debugger are different. Does anyone know the reason?

Stats and Frame Debugger are theoretically compatible with Total Batches of Profiler, but maybe some special rules are different. For example, Clear operation is considered as Batch. Looking at the comparison between the two groups, the difference is not too great.


As for the difference between DrawCall and Total Batches in Profiler, you can refer to this question:

This answer is provided by UWA

This is the 68th UWA Technology Sharing for Unity Development. As we all know, Our life has a limit but knowledge has none. These problems are only the tip of the iceberg and there are more technical problems during our program development which deserve to discuss. Welcome to join UWA Q&A community, let‘s explore and share knowledge together!




Post a Reply