1) Local resource detection and Overdraw related problems in special effect detection 2) How to speed up the determination of whether the Bundle file exists on Android 3) Xlua pcall exception capture 4) Mipmap and bandwidth 5) When the Timeline is stuck seriously, the Clip is completely skipped without execution

This is the 230th post of UWA technical knowledge sharing. Today, we continue to select a number of issues related to development and optimization for you. It is recommended that you read for 10 minutes.

UWA Q&A Community: Answer.uwa4d.com UWA QQ Group 2:793972859 (The group is full)

Rendering

Q: There is a big gap between the Overdraw and the actual detection of the special effect resource. Is the statistical peak better? It is possible for a special effect to play for a very long time, but the peak time is very short, so the average Overdraw is very low.

A: First, let’s talk about the definition of Overdraw:

  1. Overdraw is a concept that describes the number of times a pixel is repeatedly drawn. The number of redraws per pixel is easy to understand, but there is no accepted “standard” formula for calculating an Overdraw, and there is no “official” definition.

For a frame, the Overdraw value can be defined as the total number of pixels drawn for that frame/the number of pixels actually drawn on the screen. This value cannot simply be understood as “the number of layers drawn”. If you draw a total of 1000 pixels on the screen, and only one of them is drawn at 10 levels, then the contribution of this redrawn pixel to Overdraw is negligible. The result is 1009/1000=1.009. As for the Overdraw in the whole process of special effects playing, how to define the specific formula is another problem.

  1. Sunbrando’s open source libraryThe calculation method of: During the whole broadcasting process,

The numerator is the sum of the number of pixels drawn per frame, and the denominator is the sum of the number of pixels actually displayed on the screen per frame.

This formula does measure the Overdraw of a special effect as a whole during playback. However, there is a problem with this calculation: some frame effects occupy a large proportion of the screen, and some frame effects occupy a small proportion of the screen, and the results of the calculation are more affected by the large proportion of the screen. For example, if the first frame draws 1000 pixels and only draws 1 layer, and the second frame draws 2 pixels and 10 layers, then the calculated value is :(1000×1 + 2×10)/(1000 + 2) = 1.018.

The calculation of UWA local resource detection for special effect Overdraw is the same as the calculation formula of the above open source library. The difference is the logic of special effect playing and the way of camera alignment.

The factors that influence the different calculation results of the two tools include:

  1. Cameras are aligned in different ways. UWA tools have a set of automatic camera alignment logic, the camera placement will cause different Overdraw.
  2. The timing is different. UWA’s tool will automatically load and instantiate the special effects after creating the scene, and then play it. The solution of the open source library, ParticleEffectProfiler, is to put the effects into the scene first, then start the scene and then execute the relevant logic for detection.

In the case of the author, the calculation results of the two tools are different due to the different ways of the camera alignment, which is largely affected by the playing time of the acquired special effects.

The open source library tool was used for detection, and it was found that the Overdraw data of the camera had been updated three times before being captured, as shown in the figure below. That is, the Overdraw of the special effects is counted from frame 4. This is related to the code logic of the tool, and I won’t analyze why.

And the first three frames are exactly the frames that contribute the most numerically. As shown in the figure below, one of the first three frames of effects occupies a large screen space.

Starting with frame 4, the pixel ratio of the effect is much smaller.

This is why Overdraw’s calculations are not the same for both tools, even if they use the same alignment.

In addition, there is another problem in UWA’s special effect detection: the Size of the camera’s view cone is constantly adjusted, so the screen proportion of different frame effects will change accordingly, and the amount of pixels drawn will be different, which will make different contributions to the calculation formula of the Overdraw value. That is to say, the smaller the frame Size of the camera, the larger the proportion of the special effects screen, and the greater the impact on the results.

Here are two solutions:

  1. Change the formula, calculate the overdraRate for each frame, and then average it.
  2. By customizing the camera, the camera’s cone stays fixed, giving up automatic alignment and making the camera Settings more similar to the user’s actual environment.

UWA’s tools are constantly iterating to find the best possible set of strategies to help developers standardize their projects based on their needs.

If you are using tools to detect and measure the results of your optimization, it is recommended that you use a set of tools. Using the same set of criteria allows at least one ranking of the performance of a resource to be selected to prioritize optimization and to evaluate the optimization results using the same set of criteria.

Thanks to the Prin@UWA Q&A community for the answers

AssetBundle

Q: When we package on Android, we put bundles into Streaming Assets and Patch files into the persistent directory. At startup: Patch directory has a Bundle with the Patch directory, no see Streaming Assets have directory.

The problem is: Android determines if there is a file in the Streaming Assets using WWW or UnityWebRequest. Both of these are asynchronous file reads, and waiting for the asynchronous operation to finish can take more than a few milliseconds, resulting in long (bundle-heavy) judgment logic.

Would like to ask you how to deal with the file determination problem on Android?

The A1: Streaming puts a resource dictionary file and uses this judgment.

Thanks to the lanyt@UWA Q&A community for the answers

A2: It can be handled like this:


There is a global Bundle resource configuration file that records information about all bundles, including their relative paths. Only asynchronously reads the file from the package, and synchronously reads the file from the Patch directory (for example, using FileStream).


After getting the relative paths of all bundles, when loading a Bundle, first use file.exist or directly determine whether the return value of AssetBundle. loadFromFile is null to determine whether there is a Bundle in Patch directory. If not, call AssetBundle. loadFromFile again using the path inside the package.


The Patch directory can be directly used as File. If it does not exist, it is considered to be in the Streaming Assets directory. Finally, the results of Load are used to update to see if there are any records.

Thanks to Fan Jun @uwa Answers community for providing the answer

A3: There is a nice open source library that synchronously reads files in StreamingAssets:


“BetterStreamingAssets”

Thanks to Zhang Di @uwa Q&A community for providing the answer

LUA

Q: What should you pay attention to when using pcall/xpcall to implement Try Catch in C# in XLua?

Since I am not familiar with the underlying layer of Lua, I want to confirm whether it is feasible to use the online project. What is the performance cost of this? Can it be used in UPDATE?

The project uses XLua, version 2.1.14, and Unity version 2019.4.

A: In widespread use, pcall and xpcall themselves certainly have some performance impact, but we haven’t done A thorough performance comparison. Impression had done some retrieval before, did not find a particularly clear answer.


A comparison of the Lua source code can be found here:


https://stackoverflow.com/questions/16642073/whats-the-difference-behind-normal-function-call-and-pcall/16642612


You can see that pcall does a little more than a regular call, but it’s the only way Lua can do exception catching, and it’s the only way you can use it when you don’t want your game logic to be interrupted by error messages.


Pcall/XPcall has no problem except for a slight performance impact on various platforms and emulators, because it is native to Lua. If you use Luajit, notice the difference between encapsulation under Lua and Luajit.

Thanks to Jia Weihao @uwa Answers Community for providing the answer

Rendering

Q1: Could Mipmap reduce the bandwidth on earth? If not, could you tell me the reason in detail? Thank you.

A1: It can be lowered!


Mipmap is a way of dealing with Texel and Pixel not having a 1:1 match. In general, if the rendering of distant objects still uses normal texture sampling, then in fact, one Pixel will need to sample multiple non-adjacent Texels [1:n relation], then non-adjacent may involve a Cache Miss problem. A Cache Miss will need to resample the texture data from video memory, which will consume bandwidth.

Thanks to the Coder@UWA question-and-answer community for providing an answer

A2: It can reduce the bandwidth overhead.


This is mainly due to the fact that the Texel sampled may not be contiguous in memory when rendering adjacent Pixels, and the GPU’s Texture Cache is small.


Without MipMap, the GPU would have to keep accessing parts of its Texture Memory when rendering distant objects, resulting in a severe Cache Miss. Using Mipmap increases the area of the Texture covered by each Texel offline. This increases the hit ratio of the Texture Cache and reduces the number of times you need to read data directly from memory, thus saving on bandwidth.

Thanks to Fan Jun @uwa Answers community for providing the answer

1. The size of the Texture covered by each Texel will increase offline when using Mipmap. 2. Also, Memeory refers to memory, right? Didn’t you already submit a picture to GPU video memory?

A: Take A look at my answer on Zhihu to help you with your questions about Pixel and Texel:


“What does fwidth or DDX /ddy mean in shader?”

Thanks to the @uwa question-and-answer community for this answer

Timeline

Q: Timeline. If there is a serious lag in the playback, the Clip in the previous position will be completely skipped without execution. Has anyone encountered similar problems in the Timeline?

Is this description of the Timeline signal still executed even if the signal is skipped? The Retroactive property, when enabled, Will trigger the signal if the timeline begins playing after the signal’s time. The Emit Once property, when enabled, will trigger the signal only once when the timeline loops.

A: hook on is executed, then specific logic can reference TimeNotificationBehaviour script (Signal in the Timeline Track mixer logic script), made A simple comment as follows:

If you want it to Trigger backwards, you can also refer to this extension for its own Timeline.

Thanks to the @uwa Q&A community for providing the answer

Cover image Source: Barracuda Style Transfer Code Sample

That’s all for today’s sharing. Life, of course, is long and knowledge is long. The questions you may see are just the tip of the iceberg in the long development cycle, and we have already prepared more technical topics for you to explore and share on the UWA Q&A website. Welcome you who love progress to join us. Maybe your method can solve others’ urgent need. And the “stone” of another mountain can attack your “jade”.

Website: www.uwa4d.com Official Technology Blog: blog.uwa4d.com Official Q&A Community: Answer.uwa4d.com Official Technology QQ Group: 793972859 (The original group is full)