circle-loader
0
by
0/ 1301/ /4

1) How to check Mono memory allocation within Instruments

2) Questions about Addressable v1.11.2

3) The number of Mesh vertices increases when UV2 is expanded

4) Speed up the code compilation in the Unity editor

5) Questions about Renderdoc debugging


Memory

Q: For example, when a 10MB array is allocated, it can be found that at least 10MB Mono memory will be opened up in the Unity Profiler. So, how to view the allocated memory information in Instruments? Is the information in Allocations all the memory information allocated in this process? I have tried to allocate 100MB of memory, but the statistics in Allocations did not increase.

A: I also did a test here:

 

Created an int array in 100MB, the Size should actually be 400MB. Then check in Profile:

 

You can see that ManagedHeap correctly allocated the 400MB of space.

Then package the iOS buddle and run it in Xcode. Before running, firstly check the Malloc Stack of the Scheme.

 

After running, click Memory and export the Memory Graph to check:

 

Since the memory of the application is allocated in the VirtualMemory space, therefore, we will check the VM_ALLOCATE part of VM Regions.

 

It can be found that the allocation of 128X3+16 is exactly 400MB.

The call stack is also very easy to determine, which is exactly our test code:

 

Then let’s check Instruments. The first one is the Allocations section. One thing to note is that there are some options in the lower part of the column:

 

Pay attention to the last option, if you choose the first one:

All Heap & Anonymous VM: All Heap corresponds to the physical space actually allocated by the App, excluding the VM.

The official explanation of Anonymous VM is interesting VM regions such as graphics- and Core Data-related. Hides mapped files, dylibs, and some large reserved VM regions.

Therefore, some relatively large reserved allocated space will not be displayed.

Switch this option to All VM Regions, you can see the allocated 400M:

 

And the details page on the right also correctly displays the call stack: 

 

In addition, we can also observe from VM Tracker. Open VMTracker’s Snapshots:

 

You can see the detailed allocation information of this 400MB:

 

It can be found that the Virtual Size is slightly larger than 400MB because other parts of the program also need to apply for some memory. The 400MB is stored in Resident and Swapped respectively. The Resident part is basically equal to the Dirty Size, indicating that this part of the space is marked as Dirty and cannot be swapped out. The remaining 240MB is Clean space, which can be temporarily swapped out to ensure that there is enough physical space to use. This is also because we only applied for this part of the space, and did not carry out specific assignment initialization and use.

What if the assignment is done? Let’s modify the code to test:

 

Check after running Instruments:

 

It can be clearly found that these 400MB are all within the Dirty Size. This situation will put memory pressure on the App and iOS.


Addressable

Q: How to address the issue that the editor fails to obtain SubAsset when running in the “Fast Mode” mode in Addressable v1.11.2 and later?

A: I just upgraded my project from 1.8.4 to 1.14.2 using the Addressables system. Suddenly it was discovered that when the resource pointed to by AssetReference was instantiated, it will always report an invalid Key error. After investigation, it was found that starting from v1.11.2, in order to further speed up FastMode, the official has revised the process.

In the previous version, even if it was in Fast Mode, a build was required, and the Catalog generated by the build was read during playing. The Catalog would serialize all AssetEntry and SubAsset, generate ResourceLocationMap objects and then retrieve them. We use a lot of AssetReference to point to the use of SubAsset. There is no problem to use at this time.

Starting from version 1.11.2, Fast Mode directly provides the GUID of the AddressableAssetSettings object in the editor environment instead of the catalog file path. Therefore, the FastModeInitializationOperation dedicated to FastMode will be enabled when it is initialized after Play. At this time, it is not ResourceLocationMap but AddressableAssetSettingsLocator that is generated. This Locator only traverses the AssetEntry in the visible Group in the Editor Group window, and the SubAsset inside the AssetEntry will not be traversed. Therefore, if the SubAsset is used in the game, it will report an invalid Key error.

Official Changelog: 

Refactored Play Mode Script for "Use Asset Database" to pull data directly from the settings. 
This reduces the time needed to enter play mode.

Suggestions:

  • Temporarily use v1.8.4 version (after long-term use by projects, it is relatively stable)
  • It is not recommended to use the versions from 1.9.2 to 1.11.2, there are other bugs
  • When upgrading to the latest situation, use Simulate Groups mode for development
  • Wait for the official follow-up improvement

Rendering

Q: Auto-expanding UV2 (Generate Lightmap UVs) in Unity will increase the number of vertices in the Mesh of individual objects. For a ground that I automatically expanded, the number of vertices changed from 134 to 136. If UV2 is not expanded, there is no such problem. Is there any way to not increase the number of vertices when unfolding UV2?

When importing the FBX model, the “Optimize Mesh” and other options that affect the vertices are not checked.

A: Because 2 patches will sometimes correspond to 2 discontinuous areas on the Lightmap, and the vertices on the two patches may be shared, so they need to be split into 2 vertices with the rest data remaining the same, but the UV2 is different. This is normal.

If you do not want it to increase, unless the artists manually set the UV2 and export it; even so, if the model is enclosed on some patches, it is difficult to ensure that the vertices are not repeated. In fact, at this time, the vertices may have already been increased in tools such as Maya exported and then exporting, which you may not see changes in Unity.


Build

Q: Is there any way to improve the compilation speed of the code in the Unity editor? Every time we modify the code, the waiting time for compilation is nearly half a minute.

A1: For large projects, this is indeed a situation that everyone often encounters. Generally speaking, the Unity Editor compiles the code according to the dependencies of the script, which is mainly divided into the following four steps:

  • Compile Runtime Script in the Standard Assets, Pro Standard Assets and Plugins folders;
  • Compile the Script under the Editor folder in the above three folders;
  • Compile all remaining Runtime Scripts in the project (Scripts outside the Editor folder);
  • Compile the remaining Script (that is, the Script in the Editor folder).

After knowing the script compilation feature of the Unity editor, we suggest that the R&D team can put some script codes that do not need to be changed for a long time (such as various plug-in codes) into the Standard Assets, Pro Standard Assets or Plugins folders, so these codes only need to be compiled once, and the subsequent time can be saved.

One of my friends has done a test, and after the above changes in their project, the original compilation time of the project has dropped from 23s to 7s. Think about it, how much time this will save you and your team!

Recommended plug-in: Mad Compile Time Optimizer

 

A2: Add assembly definition:

https://docs.unity.cn/cn/2020.2/Manual/ScriptCompilationAssemblyDefinitionFiles.html

 

A3: Split the project and compile it into different DLLs. After Unity 2017, you can use the tools that come with the engine to define them into different projects.


Rendering

Q: The test button of my project: Pixel Context is gray:

Debug Vertex is also gray:

Why is this?

A1: Add #pragma enable_d3d11_debug_symbols to Shader of pixel debugging.

 

A2: The official document says that it can only be debugged in D3D11 or D3D12:

https://renderdoc.org/docs/how/how_debug_shader.html#hlsl-debugging


That’s all for today’s sharing. Of course, life may have its limit but knowledge knows no bounds. In the long development cycle, these problems you see maybe just the tip of the iceberg. We have already prepared many technical topics on the UWA blog, waiting for you to explore and share them together. You are welcome to join in, who loves progress. Perhaps your method can solve the urgent needs of others, and the “stone” of other mountains can also attack your “jade”.

YOU MAY ALSO LIKE!!!

UWA Website: https://en.uwa4d.com

UWA Blogs: https://blog.en.uwa4d.com

LinkedIn: https://www.linkedin.com/company/uwahub

Facebook: https://www.facebook.com/uwa4d

Twitter: https://twitter.com/uwa4d

Related Topics

Post a Reply

Your email address will not be published.