選自過去1~2周 自己所看到外文內容：https://twitter.com/unity3d 和各種其他博客來源吧 早就有了，抱歉才發！
1、 Unity Transform 性能優化摘要
https://qiita.com/sator_imaging/items/ff5811885f515a0a4998
由於我有機會在逐幀的基礎上處理大量的Transform ，我想總結一下Unity中更新Transform 的方法以及比較和優化性能的方法。
這意味着值得考慮是否有數百或更多個Transform 的 .position 或 .rotation / .eulerAngles 。
- Unity 2018.4.0f1（Unity 2018 LTS）
- Windows 10 64bit @ Intel Core i9-9900K 3.6GHz
始終在rotation / eulerAngles中緩存對xyzw的訪問
有些數據Transform中是沒有緩存的！
vector3.x = 0 和 transform.position.x = 0 看起來訪問方式很像。但實際上很大差別。 即使你緩存了Transform （高版本的Unity已經在底層進行了緩存，不需要開發者進行緩存了）
..... = new Vector3(cache.eulerAngles.x, cache.eulerAngles.y, cache.eulerAngles.z);
例如上，如果您訪問成員三次，將生成三個Vector3副本。
在Transform.position，Transform.rotation，Transform.eulerAngles等中，getter不是在字段中而是在屬性中設置，每次訪問時都有結構體拷貝。 原因是Unity的Transform 存有的是 local 相關的數據， 如果訪問世界座標下的內容 必須現算！！！！！
localRotation是最快的
四元數比歐拉角更快
本地空間比世界空間更快
.localRotation，比.rotation， .localEulerAngles比.eulerAngles快。
Transform.Rotate（）要好於 localEulerAngles + =
調整偏移等很容易，因爲Euler的角度更直觀，.localEulerAngles += .....但Transform.Rotate（）更快。
當數量很大時，會產生相當大的性能影響。
https://docs.unity3d.com/ScriptReference/Transform.Rotate.html
如果可用，請使用HumanPoseHandler.SetHumanPose（）
如果目標是Humanoid，則HumanPoseHandler的SetHumanPose可能更快。
https://github.com/Bizcast/NoitomHi5InertiaToFingerMuscle
摘要
- 我們儘可能地不處理歐拉角。
- 將值設置爲.eulerAngles / .localEulerAngles 或者訪問成員，性能將極度下降。
- 訪問Quaternion / Vector 3的成員是昂貴的，應始終緩存。
-
- 緩存Quaternion/ Vector3而不是Transform。
四元數很快
如果添加偏移 = Quaternion * Quaternion是最快的
嚴禁訪問Quaternion / Vector3的xyzw成員
- 訪問.rotation的每個成員而不緩存（4次訪問）
-
- ： .rotation = transform.rotation.xyzw + Time.time;
-
-
- 約200fps
-
-
- 使用緩存後 大約320 fps
-
-
- ： .rotation = cachedRotation.xyzw + Time.time;
-
- 訪問.eulerAngles的每個成員而不進行緩存（3次訪問）
-
- 僞： .eulerAngles = transform.eulerAngles.xyz + Time.time;
-
-
- 約110fps
-
-
- 使用緩存後 大約190 fps
-
-
- 僞： .eulerAngles = cachedEulerAngles.xyz + Time.time;
-
2、您知道可以在自己的腳本中使用ParticleSystems MinMaxCurve和MinMaxGradient。 它序列化幷包含編輯器支持！
3、剛剛發佈了OSS項目UnityNuGet https://github.com/xoofx/UnityNuGet ...提供服務，通過Unity Package Manager使用作用域註冊表將@nuget軟件包安裝到@ unity3d項目中。 這真的是一個早期的預覽。
https://github.com/xoofx/UnityNuGet
4、#unitytips 不要忘記100 * 0.5比100/2更快。 可以的話，用乘法代替除法。 （這適用於任何引擎，而不僅僅是Unity。）
https://twitter.com/ffs_nonamesleft/status/1143436080580112384
“注意： 他舉得例子不好都是常量計算， 現代編譯器都會進行常量展開(編譯時直接計算結果了)”
還可以 看看 位運算 `100 >> 1` 可能 是最快的！！！
在值不是常數的情況下，iOS上的乘法速度是除法的兩倍。在Unity編輯器中，它的速度提高了約20％。
5、 快速腳本只是爲了更好地可視化編輯器中的精靈字段。 使用PropertyDrawer將您的精靈顯示爲縮略圖。
將腳本複製到“Assets / Editor”文件夾。
腳本： https://pastebin.com/Y1R7eSA0
建議您在使用drawer 之前添加對hasMultipleDifferentValues的檢查，以防止它覆蓋在檢查器窗口中多選時所選的所有圖像
6、 關於四元數 Quaternion 的結構：
在四元數可視化中找到了一個存儲庫，我將在本文後面使用它：
https://github.com/uvivagabond/Visualization-of-physics-in-Unity
在Scenes 文件夾中打開名爲TestForQuaternions 的場景。
表示旋轉的方法有很多種。藉助旋轉矩陣，四元數和其他表示，可以藉助於歐拉角度來表示旋轉。
在本系列中，我將重點介紹四元數。我主要關注他們在Unity中的實現和操作。
https://www.youtube.com/watch?v=OBTU0v0MeeQ
參數x ，y 和z 負責旋轉軸的方向。
AngleAxis方法（）此方法允許您基於給定（絕對）旋轉軸和圍繞此軸旋轉的角度創建四元數。
我們將四元數的乘法視爲連續的身體旋轉。A * B≠B * A. 四元數從右向左相乘
歐拉角表示圍繞全局座標系的軸的旋轉，即圍繞全局軸z ，x 和y 的旋轉。
- Dot(), operator == 和 !=, FromToRotation(), SetFromToRotation(), LookRotation(), SetLookRotation()
- Lerp(), Slerp(), SlerpUnclamped(), LerpUnclamped(), RotateTowards()
四元數的可視化：
幾乎沒有困難的四元數描述
https://github.com/NickCuso/Tutorials/blob/master/Quaternions.md
來自fspace的四元數描述
https://www.f-sp.com/entry/2017/08/11/194125
Unity Answers（Bunny 83）
https://answers.unity.com/questions/1297214/quaternions-not-exact.html
https://answers.unity.com/questions/1417640/get-local-euler-angles-by-quaternion.html
https://answers.unity.com/questions/1365419/locking-rotation-world-z-axis-quaternions-are-shav.html
數學描述
https://www.vcalc.com/wiki/KurtHeckman/Quaternion+Calculator+Collection
Mateusz Kowalski
https://www.youtube.com/watch?v=ZgOmCYfw6os
其他
https://www.gamasutra.com/view/feature/3278/rotating_objects_using_quaternions.php
https://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles
https://en.wikipedia.org/wiki/Axis%E2%80%93angle_representation
7、 官方博客： 可尋址資產系統
已經宣佈 脫離預覽版了 ~~~~
https://blogs.unity3d.com/2019/07/15/addressable-asset-system/
這個支持分析工具也很到位： 比如提供引用計數 功能。
- Play Mode Simulation: assets load directly from disk without requiring a build process, while still providing the ability to debug asset reference counts through the profiler.
- Fast Incremental Builds: Addressables ships with the newScriptable Build Pipeline that improves the speed and reliability of incremental builds.
- Editor Hosting Services: A built-in facility for serving Addressable content to local, LAN connected devices provides a fast, convenient method for iterating content on device.
8、 Unity3D研究院之使用Android的硬件縮放技術優化執行效率
原理如下 http://android-developers.blogspot.it/2013/09/using-hardware-scaler-for-performance.html
https://forum.unity.com/threads/interesting-article-from-google-on-android-hardware-scaler.202625/
這兩個文章可以對 分辨率有更好的理解！！！
https://www.cinemablend.com/games/Xbox-One-Unlikely-Hit-1080p-With-DX12-Says-Witcher-3-Dev-66567.html
https://www.cinemablend.com/games/DirectX-12-May-Help-Xbox-One-Much-According-Developer-64410.html
https://www.cinemablend.com/games/1080p-Hard-Achieve-Xbox-One-Due-Complex-GPU-Says-Xbox-Director-62893.html
根據開發人員的說法，DirectX 12可能無法幫助Xbox One
Witcher 3 Dev表示Xbox One不太可能通過DX12達到1080p
當人們說“PS4比Xbox One強大50％”時，這就是他們所談論的內容的一部分。PS4的GPU上有更多着色器單元，因此每幀輸出的視覺效果比Xbox One更多。這就是爲什麼遊戲將更頻繁地在PS4上達到1080p
此外，當Xbox One上的遊戲可以達到1080p時，通常它會這樣做而犧牲其他正在渲染到屏幕上的東西。簡而言之，每一塊硬件都具有技術上限，而Xbox One的GPU由於較舊和較低等級的架構而具有如此低的上限，因此難以在遊戲中始終如一地達到1080p。
最終，DirectX 12之前曾被提及爲更好的CPU流水線指令，而不是檢修GPU的運行方式。（還是跟硬件有關唄，這是因爲GPU較弱，ESRAM有限）
這就像嘗試使用軟件優化來使GTX 7800達到2K分辨率。是的，這是可能的，但你必須做出巨大的犧牲才能在屏幕上顯示什麼來達到分辨率。你不能用軟件神奇地升級硬件; 優化不能解決這個問題。
Xbox 360的1040x600分辨率與Xbox One的1408x792輸出相差500,736像素。戰地4在Xbox One上的720p相比PS4的900p輸出相差518,400像素。
Unity 4.x 的代碼中確實有使用：
// $TODO Make this less complicated ;)
// This code is unnecessarily complicated, just to cover the fact that it can be called both from
// native code (through scripts Screen.SetResolution) and from Java (GLThread onSurfaceChanged).
protected void setScreenSize(final int w, final int h, final boolean low_profile)
{
final SurfaceView view = mGlView;
Rect rect = view.getHolder().getSurfaceFrame();
if (Log.LOG_INFO)
Log.Log(Log.INFO, String.format ("setScreenSize: %dx%d (%dx%d / %dx%d)",
w, h, rect.width (), rect.height (),
view.getWidth (), view.getHeight ()));
// If w/h matches the view, or if w/h is 0/0, we use the layout size (and disable any fixed-size surface holder)
final boolean reset = view.getWidth() == w && view.getHeight() == h || w == 0 && h == 0;
// If w/h is -1/-1, we keep whatever was set before (no change to screen resolution)
final boolean keep = w == -1 && h == -1;
if (!keep)
{
if (reset)
{
if (Log.LOG_INFO) Log.Log(Log.INFO, "setScreenSize: setSizeFromLayout()");
mSurfaceFixedW = 0;
mSurfaceFixedH = 0;
}
else
{
if (Log.LOG_INFO) Log.Log(Log.INFO, "setScreenSize: setFixedSize(" + w + ", " + h + ")");
mSurfaceFixedW = w;
mSurfaceFixedH = h;
}
}
else
{
boolean fixed = (mSurfaceFixedW != 0 || mSurfaceFixedH != 0);
if (fixed)
{
if (Log.LOG_INFO) Log.Log(Log.INFO, "setScreenSize: keeping fixed size " + mSurfaceFixedW + "x" + mSurfaceFixedH);
}
else
{
if (Log.LOG_INFO) Log.Log(Log.INFO, "setScreenSize: keeping layout size " + view.getWidth() + "x" + view.getHeight());
}
}
runOnUiThread(new Runnable () {
public void run () {
if (!keep)
{
if (reset)
view.getHolder().setSizeFromLayout();
else
view.getHolder().setFixedSize(w, h);
view.invalidate();
}
if (HONEYCOMB_SUPPORT)
HONEYCOMB.setSystemUiHidden(UnityPlayer.this, low_profile);
}
});
}
9、基於 Chrome DevTools 的 Lua 5.3 調試器
https://mare.js.org/zh-cn/?tdsourcetag=s_pcqq_aiomsg
10、多線程同步I/O和單線程異步I/O
http://linzhi.github.io/multithread-io-singlethread-io
多線程帶來的好處是在多核CPU的情況下利用更多的核， 單線程事件編程模式的異步I/O與多線程阻塞式I/O相比，異步I/O少了多線程的開銷。對OS來說，創建一個線程的代價比較昂貴，需要給它分配內存、列入調度，同時在線程切換的時候還要執行內存換頁，CPU的緩存被清空，切換回來的時候還要重新從內存中讀取信息，破壞了數據的局部性。
單線程事件驅動的異步I/O有個缺點就是異步程序不是很好理解，編寫異步程序比較困難。
Python進階：聊聊IO密集型任務、計算密集型任務，以及多線程、多進程
https://zhuanlan.zhihu.com/p/24283040
不管文章中的結論， CPU密集型任務分爲 IO(網絡/磁盤讀寫)密集型任務， 計算密集型任務
常見的IO請求有網絡IO，磁盤IO。
也有一種說法： https://blog.csdn.net/o83290102o5/article/details/78723329
IO密集/CPU密集
Unity的 Job 強調的是針對CPU 多核， 利用多線程加速，針對的就是CPU密集，文章中有提到對IO密集 可能提升。 https://blogs.unity3d.com/cn/2018/10/22/what-is-a-job-system/?_ga=2.203082005.526565089.1561874920-1366382285.1535636176
What problem does it not solve?
A Job System is not designed to be a solution for long running low priority tasks, and it is not designed for operations waiting instead of using CPU resources, like IO. It’s still possible to do these things, but it’s not the primary purpose of the Job System, which means they come with some limitations you need to be aware of.
這裏的問題和答案是想要的：
http://cn.voidcc.com/question/p-uzupaljk-hp.html
執行多次磁盤操作時，多線程是否有幫助，阻礙或沒有任何影響？
到目前爲止，大部分答案都與操作系統調度程序有關。但是，我認爲還有一個更重要的因素會導致您的答案。你正在寫入一個物理磁盤還是多個物理磁盤？
即使您與多個線程並行... IO到單個物理磁盤本質上是一個序列化操作。每個線程都必須阻塞，等待有機會訪問磁盤。在這種情況下，多個線程可能無用......甚至可能導致爭用問題。
但是，如果你正在寫多個流到多個物理磁盤，處理它們同時應該給你的性能的提高。這是管理的磁盤尤其如此，像RAID陣列，SAN設備等
我不認爲這個問題有很多工作要做，因爲它更多的是與磁盤的物理方面（OS調度器s）你的寫作。
https://blueswind8306.iteye.com/blog/1983914
發編程系列-多線程IO vs 單線程IO
結論: 可以看出，當測試文件增多時，在單線程情況下，性能沒有降低。但多線程情況下，性能降低的很明顯，由於IO阻塞導致CPU基本被喫滿。所以在實際編碼過程中，如果遇到文件讀寫操作，最好用一個單獨的線程做，其它線程可以分配給計算/網絡IO等其它地方。而且要注意多個進程之間的文件IO的影響，如果多個進程分別做順序IO，其實全局來看（如果是一塊磁盤），就變成了隨機IO，也會影響系統性能。
11、 關於UGUI 組件的 Inspector擴展困難問題。
https://stackoverflow.com/questions/32754210/can-ui-text-inspector-be-extended-in-unity3d
這個問題的解決方案有兩個關鍵點：
用繼承的方式避開同系統編輯器擴展的衝突
所擴展的編輯器類要繼承ImageEditor類而不是Editor類
一開始就不要使用系統默認組件， 而是繼承他們弄自己的一個類。 個人覺得不是特別美好。
當然了，不使用默認的DLL ，而是使用源代碼方式【Unity又提供了程序集定義文件 可用】，這這樣在處理源代碼等方面就方便多了。
或者升級到Unity2019 UGUI本身作爲 Package 出現了，就是可以查看和編輯源代碼的！！！
好奇一個點就是怎麼查看 動態字體動態生成的 Font Texture . 沒有找到答案，只能設置爲Unicode，然後設置貼圖可讀。但這就不是動態字體了。
看到其他不太有用的鏈接。
從 Font 中生成對應字符的貼圖。 可以直接取，如果不存在就生成。
https://pastebin.com/SZ3S6WyQ
Create a font texture
https://www.lynda.com/Unity-tutorials/Create-font-texture/444940/483622-4.html
在不使用渲染紋理的情況下在Unity3D中運行時添加文本到紋理
http://blog.almostlogical.com/2010/08/20/adding-text-to-texture-at-runtime-in-unity3d-without-using-render-texture/
TextToTexture.cs
http://blog.almostlogical.com/workingExamples/TextToTextureDemo/TextToTexture.cs
12、 FPS 的顯示到底怎麼處理比較合適？
還是一句代碼就可以計算？ 這個變動更頻繁~
還區分Render FPS 和 Game FPS： 看了下這兩個時間基本一致。
概念證明Unity項目可以更精確地控制幀率和GenLock
或者 ：
MiniProfiler.cs
https://github.com/Unity-Technologies/Benchmark/blob/master/Assets/Scripts/FPSTest.cs
好奇Unity Game 視圖中 Stats 面板中的幀率是怎麼計算的？ 時間取Mathf.Max(frameTime, renderTime); 主線程和渲染線程的最大值。
13、 https://answers.unity.com/questions/210953/mobile-bump-performance.html
法線貼圖是每像素效果。對象數量無關緊要; 重要的是使用法線貼圖着色器繪製了多少像素。如果您可以使用對象空間法線貼圖，則無需擔心。如果需要切線空間法線貼圖，那麼在編寫着色器時需要更加小心。假設你提到了一個亮點。每增加一盞燈就需要額外通過，這很容易破壞性能。
---------------------------------------------
五年前的一個討論： https://www.reddit.com/r/Unity3D/comments/29qtbt/is_there_a_performance_impact_for_using_different/
使用不同的紋理貼圖會產生性能影響，例如凹凸貼圖，高光貼圖等與純紋理相對的？
-----------------------------------
是。爲了使它成爲真實的教誨：將每??種不同類型的紋理視爲另一種紋理，其中每種紋理都比下一種更昂貴。漫反射是所有點亮紋理中最便宜的，然後是法線貼圖，然後是鏡面貼圖，依此類推。
所以，基本上：渲染一個凸起的鏡面反射紋理（漫反射，正常和鏡面反射）比僅僅漫反射紋理貴兩倍。
----------------------------
顯然也一定是的。真正的問題是它是否以及如何引人注目。並且總是以“它取決於”來回答，特別是在......其他一切。正在使用的硬件，正在使用的操作系統，GPU驅動程序，設備插入或未插入，每幀執行多少，我們談論了多少個調用等等等。
請注意，紋理需要是：
上傳到VRAM（一次）
然後，對於着色器進行採樣，他們需要“綁定到紋理採樣器”，這是一個很小的CPU和GPU開銷，但它總共加上1000s的drawcalls 30-even-even-60x / second
片段着色器是一個爲每個片段（像素）並行運行的程序，每個程序都從VRAM讀取紋理中略有不同的紋素分數
壓縮起到了作用，更小的紋理上傳速度更快，訪問速度也更快，即使在動態解壓縮的情況下也是如此
我們現在擁有極其強大的硬件......如果你有一點室內設計師的場景，或者展示一個非常詳細的車型或其他東西，不要擔心。但是就像現在這樣強大，它仍然無法擴展到無限數量的紋理，材質和用於實時60FPS渲染的繪圖調用。因此，在某些時候，您可能正在研究關閉顛簸或大規模霧化幾何形狀的顛簸或規格。
最好是在開發過程中使所有內容都處於開/關狀態。不一定是最終產品的最終用戶，而是讓您瞭解隨着項目的發展每個小功能的不同之處。對於個人自定義環境，項目環境等，它始終是獨一無二的。
除了以上內容之外，特別談論某些紋理：
bumpmaps添加更多計算，而不僅僅是將其採樣到着色器。現在，他們通過內插器將計算出的切線幀從頂點發送到片段着色器，以便可以在幾何法線的頂部應用法線貼圖。發送的數據越多，使用的帶寬越多，兩個着色器都會發生更多的計算。我記得第一款使用凹凸貼圖的遊戲，這是一項僅在一個恐龍皮膚上用於特寫鏡頭的特殊功能。如今已經不再那麼重要了，但沒有任何東西是免費的。
鏡面着色器（以及爲什麼你會使用spec-map）比基本的“僅漫反射”Lambert執行稍微更密集的光照計算，Lambert是一個簡單的視圖無關點積。依賴於視圖的內容（如反射或鏡面反射高光）需要在使用它的所有着色器中進行更多計算。在現代硬件和驅動程序上它仍然相當快，但成本是存在的，在某些時候你可能會開始注意它，因爲你增加了你在GPU上投入的東西，特別是在移動設備上。
甚至最簡單的視差映射的高度圖也將依賴於視圖的計算引入着色器
這是所有“特定於用例的成本” ，除了基本的真正紋理 - 甚至是反照片外，每當有更多紋理添加到材質時，都會消耗更高的內存和帶寬。
數學上，一個spec地圖只增加了一個額外的乘法照明方程（specularity_final * map），所以它被認爲是一個非常“自由”。任何與表面形貌混淆的東西都是昂貴的（凹凸）。
對於地圖，將斑點/凹凸/自發光/某些地圖映射到一個RBGA紋理並單獨引用這些通道非常常見，這樣可以節省開銷。
DOTA 2的建模指南非常適合用於實現這一點。
------------------------------
好的 從技術上講，你是對的。如果你在做鏡面反正，規範地圖只會增加平時的質感“開銷”和乘法。
但是人們經常會以特別自發的方式解決這個問題：“嘿，我這裏有一個規格圖，所以我選擇了一個規範着色器”。然後他們添加了與朗伯漫反射相比的鏡面光照的額外（通常是現在完全可接受且合理但是額外的）開銷。;）在那種情況下，他們增加了更多的工作，而不是“再多一次特徵提取和乘法”。在內置BlinnPhong照明模型（即任何內置鏡面着色器）的情況下，它是一個永遠不會自由的pow（）和內置Lambert照明模型的其他幾個指令（即任何內置的非所有不需要的特殊着色器（如漫反射）。鏡面光照需要視圖方向，即在垂直着色器中進行更多計算，將更多數據發送到frag着色器，以及在最終照明功能中執行更多工作。完全值得的，
----------------------------
在性能影響方面，不同類型的紋理之間幾乎沒有區別，它們只是位，通常是每通道8位壓縮RGB佔用一定量的內存和一定量的時間流入其中。而已。在那裏畫了什麼，鏡面地圖，漫反射，一些超奇怪的splat地圖與自定義頻道排列，絕對沒有任何改變。
單詞“性能影響”與使用這些紋理的着色器效果的複雜性有關，而不是紋理本身。他們只能用它們的分辨率來影響它（需要更多的內存，樣本，帶寬，流媒體時間等），但我假設你不是在問這裏的分辨率。如果一個紋理是以一種格式編碼的，比方說，只使用一個通道而不是三個，好，它會更快 - 但僅僅因爲它是要處理的數據的三分之一，而不是因爲它繪製的東西在某種程度上更好對於性能而言，比如說，漫反射貼圖。
GPU對類型之間的差異一無所知。有一些特殊的壓縮類型，如果使用的話，會讓GPU做一些額外的東西，但是當你比較像鏡面和漫反射這樣的地圖時，它們不會彈出，這些地圖通常是普通的DXT，具有相同的平面成本。如果您突然將鏡面反射貼圖作爲輸入提供，則性能差異永遠不會出現在漫反射着色器中。如果您需要採樣兩個地圖而不是一個地圖，或者使用來自它們的樣本執行不同的，更重的計算，它會跳轉，依此類推。
-------------------------------------------------- 順便提一下 看到過的文章：
http://www.procedural-worlds.com/gaia/tutorials/mobile-unity-scene-optimisation-with-gaia/
- Use a maximum of 4 textures on your terrain. Every multiple of 4 textures causes the unity terrain shader to render an additional pass (draw the terrain all over again). So even adding 1 texture over this boundary of 4 will cause another pass.
- 在地形上最多使用4個紋理。4個紋理的每個倍數使統一地形着色器渲染一個額外的通道（再次繪製地形）。因此，即使在4的這個邊界上添加1個紋理也會導致另一個傳遞。
14、 【技術講座】1080322-Unity璀璨奪目篇：獨立製作MMORPG【阿比頓：無盡之島】歷程分享 - 半角鹿遊戲工作室
看一下他們用到的插件： Odin, Status Indicators, Amplify Shader, SyntyStudio , Post Processing Stack , Aura Volumetric Lighting , Text Mesh Pro for UGUI ,
後端框架選擇 ： Photon Server (使用這個) , SmartFoxServer , KBEngine
數據庫的選擇（都有用 ）： MySql - 存儲遊戲內部設定資料
PostgreSQL - 玩家資料存儲，大量IO
Redis - 排行榜 等， 需要即時大量撈數據 但丟失疼痛度低着。
15、 [Unity]關於在2019.2中添加的TryGetComponent
到目前爲止，當獲取“未分配組件的狀態”時，GetComponent通常的方法是暫時獲取它並檢查內容是否爲空。
var component = array[i].GetComponent<SampleComponent>(); if (component != null) component.Value++;
TryGetComponent 將檢查它是否可以獲得返回值的組件。例如，可以如下描述與上述相同的操作。
if( TryGetComponent(out SampleComponent comp)) comp.Value++;
做一下性能測試：
SampleComponent comp;
Profiler.BeginSample("test_TryGetComponent");
for (int i = 0; i < data.capacity; i++)
{
if( TryGetComponent(out comp))
comp.Value++;
}
Profiler.EndSample();
Profiler.BeginSample("test_GetComponent");
for(int i=0; i<data.capacity; i++)
{
var component = array[i].GetComponent<SampleComponent>();
if (component != null)
component.Value++;
}
Profiler.EndSample();
編輯器下：
Build 之後：
沒有組件的情況下 編輯器中測試：
沒有組件的情況下 Build中測試：
也就是說，組件存在的情況下使用GetComponent似乎更快？ 什麼情況？。
http://tsubakit1.hateblo.jp/entry/2019/07/16/233235
16、每次閱讀文檔都會有不一樣的收穫！
https://unity3d.com/fr/learn/tutorials/topics/best-practices/camera?playlist=30089
RenderTexture切換
切換渲染目標時，圖形驅動程序在幀緩衝區上執行加載和存儲操作。例如，如果在兩個連續幀中渲染到視圖的顏色緩衝區和紋理，系統會在共享內存和GPU之間重複傳輸（加載和存儲）紋理內容。
Geometry幾何
必須將場景中GameObjects的幾何複雜度保持在最低限度，否則Unity必須將大量頂點數據推送到圖形卡。200k靜態三角形是低端移動的保守目標。但是，這還取決於您的GameObjects是動畫還是靜態。
在Unity中，通過使用具有高多重計數的遊戲對象，而不是具有低多邊形數量的許多遊戲對象，可以獲得更好的渲染性能。
從幾何體中刪除無法看到的面，並且不渲染玩家從未看到的東西。例如，如果您從未看到櫥櫃的背面靠在牆上，則櫥櫃型號的後側不應有任何面。
儘可能簡化網格。根據目標平臺（特別是在移動設備上），請考慮通過高分辨率紋理添加細節以補償低多邊形幾何，可能的視差映射和曲面細分。請注意並記住要定期進行配置，因爲這會影響性能，並且可能不適合或在目標平臺上可用。
通過儘可能多地將詳細信息烘焙到紋理中來降低像素複雜度（每像素計算）。例如，將鏡面高光烘焙到紋理中以避免必須計算片段着色器中的高光。
https://unity3d.com/fr/learn/tutorials/topics/best-practices/framebuffer
雙重和三重緩衝
如果設備支持雙緩衝或三緩衝，則圖形驅動程序分別需要兩個或三個幀緩衝區。使用多個幀緩衝帶有圖形內存含義，尤其是當應用程序在Native Resolution上運行時，尤其是在高分辨率顯示器上。
顏色緩衝
使用的幀緩衝區數量主要取決於圖形驅動程序，每個幀緩衝區有一個顏色緩衝區。
模板和深度緩衝
該模板緩衝和深度緩衝，如果圖形功能使用它們只能綁定到幀緩衝區。如果您知道應用程序不需要它們，則應禁用它們，因爲幀緩衝區會根據分辨率佔用大量圖形內存，並且需要創建資源。
要禁用深度緩衝區和模板緩衝區，請轉到“ 播放器設置”（菜單：“ 編輯”>“項目設置”>“播放器”）窗口，向下滾動到“ 分辨率和演示文稿”部分，然後選中“ 禁用深度和模板*”複選框。
在移動GPU上，深度緩衝區和模板緩衝區是兩個獨立的緩衝區，深度緩衝區爲24位，模板緩衝區爲8位。它們不會組合在一個緩衝區中，這與桌面平臺不同，在桌面平臺上緩衝區被組合成一個32位緩衝區，深度緩衝區使用24位緩衝區，模板緩衝區使用8位緩衝區。
原始分辨率
現代手機的顯示器分辨率非常高。原始分辨率通常超過1080p。即使對於現代遊戲機，1080p也很難在不降低性能的情況下提供支持。
提示： 控制應用程序的分辨率，甚至可能將其曝光，以便用戶在想要節省電池壽命時降低分辨率。
使用Screen.SetResolution命令可以降低默認分辨率並在不降低質量的情況下恢復性能。
注意：將分辨率設置爲原始分辨率的一半可能並不總是對視覺保真度產生積極影響。
緩衝區大小
計算幀緩衝區大小並比較從本機探查器獲得的結果。例如，全高清屏幕的分辨率爲1920 x 1080，即2073600像素：
將此乘以用於顏色通道分辨率的位數後，得到66355200，這是位所需的內存。
現在將它除以8,1024和1024，得到字節數，千字節數和兆字節數。
下表按分辨率和位/通道提供內存。
運行在三星Galaxy S8上的分辨率爲1440 * 2960的應用程序在使用32位顏色緩衝區，24位深度緩衝區和8位緩衝區進行三重緩衝操作時，將使用97.68MB的圖形內存作爲幀緩衝區。位模板緩衝區。這些數字可幫助您比較內存統計信息，同時使用iOS上的本機分析器（儀器中的IOKit分配）和Android（dumpsys meminfo中的 EGL mtrack分配）分析內存。
光照貼圖
在適當的情況下，您應該使用最基本的着色器。利用便宜的Mobile> Unlit（支持光照貼圖）着色器爲場景添加光照貼圖。
着色器關鍵字
着色器關鍵字是全局的。目前，您只能使用196個關鍵字，因爲Unity本身在內部使用60個。
構建着色器時，可以使用下劃線_來禁用/啓用目的功能，以避免佔用全局關鍵字（例如，使用#pragma multi_compile _SUPER_FEATURE時）。
提示：在multi_compile上使用shader_feature，因爲它通過剝離不需要的關鍵字來節省內存。
着色器變體
着色器通常包含多種變體，這些變體會增加構建大小，而這可能不是必需的。
如果在着色器中使用以下定義，Unity將生成定義了A和C的變體：
#if 1
#pragma multi_compile A B
#else
#pragma multi_compile C D
#endif
Unity在預處理步驟之前運行用於解析變體的#pragmas的代碼。避免在着色器代碼中使用#defines。要了解有關着色器變體的更多信息，請參閱製作多個着色器程序變體的文檔。
提示：如果不需要，請在圖形設置中禁用着色器設置（如線性霧）。這將刪除變體，以便在進行構建時處理來自所有着色器的這些設置。
https://unity3d.com/fr/learn/tutorials/topics/best-practices/textures?playlist=30089
GPU上傳 （GPU Upload）
完成加載後，Unity會將紋理直接上傳到GPU，並且不會等到紋理在攝像機視錐中看到。
當加載線程完成加載場景或資產時，Unity需要喚醒它們。加載的位置和方式取決於Unity版本和用於初始化加載的調用。
加載行爲
如果從AssetBundles，Resources或Scenes加載資產，Unity會從預加載線程（磁盤I / O）轉到圖形線程（GPU上載）。如果您使用Unity 5.5或更高版本，並且啓用了圖形作業，Unity會從預加載作業直接進入GPU。
覺醒行爲
在喚醒所有場景遊戲對象後，Unity直接喚醒主線程上的資產。如果使用AssetBundle.LoadAsset，Resources.Load或SceneManager.LoadScene來加載資產和場景，Unity會阻止主線程並喚醒所有資產。如果您正在使用這些調用的非阻塞版本（例如，AssetBundle.LoadAssetAsync），Unity會使用時間切片來喚醒資產。
記憶行爲
在一次加載多個紋理時，如果上傳速度不夠快或主線程停止，您可以調整紋理緩衝區。但是，更改默認值可能會導致高內存壓力。在Unity指南中的Memory Management的RingBuffer部分中使用時間片喚醒時，您可以閱讀有關紋理緩衝區中內存限制的更多信息。
注意：如果GPU內存過載，GPU會卸載最近最少使用的紋理，並強制CPU在下次進入相機平臺時重新上傳它。
https://docs.unity3d.com/560/Documentation/Manual/AsyncTextureUpload.html
異步紋理上傳
異步紋理上載允許從磁盤異步加載紋理數據，並在Render-thread上啓用時間片上傳到GPU。這減少了主線程中GPU上傳的等待時間。
筆記
對於非讀/寫啓用的紋理，TextureData是resS（流媒體資源）的一部分，現在上傳發生在Render-Thread上。在調用AwakeFromLoad之前，可以保證Texture的可用性，因此在加載順序或渲染上的Textures的可用性方面沒有變化。
對於其他類型的紋理加載，例如啓用讀/寫的紋理，直接使用LoadImage（byte []數據）函數加載的紋理，或從Resources文件夾加載，不使用異步緩衝區加載 - 使用較舊的同步方法。
《優化加載性能：瞭解異步上載管道》中文翻譯： https://mp.weixin.qq.com/s?__biz=MzU5MjQ1NTEwOA==&mid=2247495299&idx=1&sn=8f0a56a98a3c17fb6ccfacbccbda3000&chksm=fe1dda28c96a533e8fdfcf8feb5b41ccd595d66cd31968a5748413dacc95ae9e2f78f4d7802d&scene=21#wechat_redirect
《Texture Mipmap Streaming（）2018.2 》 有很多調試腳本的功能！！！！
https://docs.unity3d.com/Manual//TextureStreaming.html
https://docs.unity3d.com/Manual//TextureStreaming-API.html
首先，沒弄懂 這個東西是否帶來了性能上的提升？
它用少量CPU資源以節省潛在的大量GPU內存。
Texture mipmap Streaming系統使您可以控制實際加載到內存中的mipmap級別。 通常Unity會加載存儲在磁盤上的所有mipmap級別，但是使用此係統，您可以直接控制加載哪些mipmap級別。
通常，這樣的系統通過僅加載渲染場景中當前相機位置所需的mipmap來減少紋理所需的總內存量。 它可以節省少量CPU成本，從而節省大量GPU內存。
在維京村的場景中，系統節省了25-30％的紋理內存，具體取決於相機的位置。
https://docs.unity3d.com/Manual/AsyncTextureUpload.html
這個異步紋理上傳 和 Texture Streaming 有關係麼？？？？
使命召喚手遊有 使用 : Texture Streaming
https://mp.weixin.qq.com/s?src=11×tamp=1563935430&ver=1747&signature=qIm5L3zeFnOXEUDvHZn0BMxfp1TMSsc7e9cPfY4CEwtFIS4wzaMGEchnXLOE*7NPjmxY9rO2WSANiqc*ujdkEanX7o6njUbrLaJutf4clUjAJfg7bSW4OTHHloVpGEsM&new=1
17、 關於RenderTexture :
RenderTexture.format顏色格式可以指定，但內存負載很高，因爲不能使用PVRTC等壓縮系統。因此，請注意不要使用太多的尺寸或數量。您可以檢查
終端是否支持指定的顏色格式SystemInfo.SupportsRenderTextureFormat。
Using Graphics.CopyTexture vs. Texture2D.ReadPixels????
if (SystemInfo.copyTextureSupport == UnityEngine.Rendering.CopyTextureSupport.None)
{
//High GC allocs here
Color[] pixelBuffer = sourceTexture.GetPixels((int)r.x, (int)r.y, width, height);
output.SetPixels(pixelBuffer);
} else { // GC的數量在這裏大大減少
Graphics.CopyTexture(sourceTexture, 0, 0, (int)r.x, (int)r.y, width, height, output, 0, 0, 0, 0);
}
Google 提供了一個插件： Tilt Brush ： https://www.tiltbrush.com/?source=post_page---------------------------
https://medium.com/google-developers/real-time-image-capture-in-unity-458de1364a4c
Unity 2018.1引入了一個新的異步GPU回讀 API，這將使這個過程變得更加容易。（2018.2 版本被轉正的）
允許異步讀回GPU資源。
此類用於將資源數據從GPU複製到CPU而不會出現任何停頓（GPU或CPU），但會增加幾幀延遲。
https://docs.unity3d.com/ScriptReference/Rendering.AsyncGPUReadback.html
https://docs.unity3d.com/ScriptReference/Rendering.AsyncGPUReadbackRequest.html
更關注文章中提到的 性能問題：
要在Unity中捕獲幀緩衝區，您需要兩件事：RenderTexture和Texture2D。然後 複製像素 。
// Setup a camera, texture and render texture
Camera cam = ...;
Texture2D tex = ...;
RenderTexture rt = ...;
// Render to RenderTexture
cam.targetTexture = rt;
cam.Render();
// Read pixels to texture
RenderTexture.active = rt;
tex.ReadPixels(rectReadPicture, 0, 0);
// Read texture to array
Color[] framebuffer = tex.GetPixels();
以下是緩慢的根本原因： （他們的用例是視頻，所以需要在Update中處理）
1、GetPixels（）函數會阻塞以等待ReadPixels（）完成
2、刷新GPU時，ReadPixels（）會阻塞
3、GetPixels（）在每次調用時分配一個新數組，使垃圾收集器崩潰
第一個問題實際上很容易避免。我們將在ReadPixels（）和GetPixels（）之間放置一幀延遲。
更棘手的是ReadPixels（）將觸發GPU刷新。這究竟是什麼意思？
當向GPU發出命令/繪製調用commands/draw calls時，這些命令被批處理到驅動程序中的批量命令緩衝區中。“刷新GPU”意味着等待當前命令緩衝區中的所有剩餘命令執行。CPU和GPU可以並行運行，但在刷新期間，CPU處於空閒狀態，等待GPU也變爲空閒，這就是爲什麼這也稱爲“synchronization point.”“同步點”。爲什麼會發生這種情況呢？
https://docs.microsoft.com/zh-cn/windows/win32/direct3d10/d3d10-graphics-programming-guide-resources-mapping
“GPU / CPU並行性的最壞情況是需要強制一個處理器等待另一個處理器完成的工作結果。”
如文檔所述，GPU拷貝可以流水線化並與CPU並行執行。但是，如果在複製完成之前請求數據，則返回一致值的唯一方法是完成所有掛起的命令，從而強制CPU-GPU同步。
OnPreRender（）似乎很有希望，但正如您在下面的跟蹤中所看到的，這種方法略微提高了性能，但是在開始傳輸之前，CPU仍然阻止了一些工作要完成：
問題： https://forum.unity.com/threads/rendertexture-to-texture2d-too-slow.693850/
RenderTexture只存在於GPU上，這就是爲什麼你需要將數據複製到Texture2D資產的原因，這在GPU和CPU上都存在（儘管兩個版本是分開的，並且它們並不總是匹配！）。ReadPixels要求GPU將數據複製回CPU。這很慢，部分原因是GPU被設計爲從CPU接收數據，而不是將其發回，而且因爲GPU在發出請求時可能正忙。無論哪種方式，在許多情況下，恢復數據可能會非常緩慢。
所以解決方案通常是不使用ReadPixels。如果要將渲染紋理複製到紋理2D中以在場景中的其他內容上使用它，您可以使用在GPU上執行復制的Graphics.CopyTexture（），或者直接使用渲染紋理本身。
如果您希望以某種方式處理圖像，您可能希望使用blit（）和自定義着色器或計算着色器在GPU上完成這項工作。如果數據確實需要在CPU上，比如爲了某些遊戲代碼原因而使用其中的信息，或者爲了獲取屏幕截圖，那麼您希望研究使用AsyncGPUReadback。
問題來了： 如果只是使用RenderTexture, 而不去讀像素等數據呢？ 下面的答案解開了我的疑惑！！！
RenderTexture 只是引用，其中的像素等數據並沒有從GPU獲取，現在把RenderTexture賦值給UGUI的 RawImage 是不會有性能問題的， RawImage在渲染的時候Shader採樣的對象是已經在GPU中存在的，也不會有Upload等操作。
“ 基本的Texture類基本上是一個帶有一堆共享屬性的虛擬類。除了明顯的共享屬性集之外，主要的共同點是它們作爲一種將CPU端與實際GPU端資產相關聯的方式。將紋理指定給材質時，它只是附加的參考編號。當CPU告訴GPU渲染一個對象時，它會“使用這個着色器ID渲染此網格ID，並使用這些設置和紋理ID”。
每個Texture子類都在其上實現了一些獨特的功能。其中大多數，如Texture2D和TextureCube等，都有一個可選的CPU端數據存儲，用於暫時從磁盤加載紋理資源時暫時使用，然後在上傳到GPU後清除，或者保留在CPU端閱讀和操縱。如果修改CPU上的Texture2D，用於渲染的GPU側圖像將不會顯示這些更改，直到您調用Apply（），將數據從CPU複製到GPU。或者，如果您使用CopyTexture（）將一個紋理複製到另一個紋理，如果您正在複製的紋理在CPU上不存在（如已清除其CPU側數據或渲染紋理的紋理），則只有GPU數據已更改，CPU端數據不會顯示副本的結果。
RenderTexture永遠不會有數據的CPU端版本。它假設它始終完全存在於GPU上。渲染紋理具有GPU可以渲染的區別。特別是可以綁定爲渲染目標的東西，片段着色器的輸出可以寫入。普通紋理不能這樣做。但是當在材質上設置爲紋理屬性時，兩者都可以在着色器中讀取，並且着色器不知道存在任何差異。
*一些舊的移動硬件有一些渲染紋理格式可供渲染，但不能讀取，或至少不能很好地讀取。但這不再是一個問題了。
”
性能優化點： https://docs.unity3d.com/ScriptReference/RenderTexture.GetTemporary.html
分配臨時渲染紋理。
當您需要快速RenderTexture進行一些臨時計算時，此功能已經過優化。一旦完成，就使用ReleaseTemporary釋放它，因此如果需要，另一個調用可以開始重用它。
內部Unity保留了一組臨時渲染紋理，因此對GetTemporary的調用通常只返回已創建的紋理（如果大小和格式匹配）。這些臨時渲染紋理在不用於幾幀時實際上會被破壞。
如果你正在進行一系列後期處理“blits”，那麼最好爲每個blit獲取和釋放一個臨時渲染紋理，而不是預先獲得一個或兩個渲染紋理並重用它們。這對於移動（基於磁貼的）和多GPU系統來說非常有用：GetTemporary將在內部執行DiscardContents調用，這有助於避免對先前渲染紋理內容進行昂貴的恢復操作。
您不能依賴從GetTemporary函數獲得的RenderTexture的任何特定內容。它可能是垃圾，或者可能會被清除爲某種顏色，具體取決於平臺。
18、 一組測試數據，低端手機（畫質，分辨率，後處理等都最高）
，主要測試在不犧牲顯示上畫質的情況下測試頂點，三角面等渲染數據對性能影響，減模減面合批處理到底什麼樣的數據比較合適????。 （可以通過只改變 Camera的 Far Clipping Planes的值，這樣場景中的動畫模型都在，只是攝像機內看到內容多少變化。前提所有場景元素的消耗認爲都是等級的！)
30幀：
SetPass Calls: 47 Draw Calls: 74 Total Batches: 68 Tris: 8.2k Verts: 10.2k
(Dynamic Batching) Batched Draw Calls: 6 Batches: 1 Tris: 0 Verts: 0
(Static Batching) Batched Draw Calls: 2 Batches: 1 Tris: 2.0k Verts: 5.1k
Used Textures: 0 - 0 B
RenderTextures: 21 - 11.9 MB
RenderTexture Switches: 22
Screen: 64x64 - 48.0 KB
VRAM usage: 11.9 MB to 11.9 MB (of 0 B)
VBO Total: 0 - 0 B
VB Uploads: 27 - 48.0 KB
IB Uploads: 27 - 1.0 KB
Shadow Casters: 0
22幀：
SetPass Calls: 53 Draw Calls: 80 Total Batches: 76 Tris: 14.3k Verts: 19.5k
(Dynamic Batching) Batched Draw Calls: 5 Batches: 1 Tris: 0 Verts: 0
(Static Batching) Batched Draw Calls: 0 Batches: 0 Tris: 0 Verts: 0
Used Textures: 0 - 0 B
RenderTextures: 21 - 11.9 MB
RenderTexture Switches: 22
Screen: 64x64 - 48.0 KB
VRAM usage: 11.9 MB to 11.9 MB (of 0 B)
VBO Total: 0 - 0 B
VB Uploads: 26 - 33.0 KB
IB Uploads: 26 - 1.0 KB
Shadow Casters: 0
14幀：
SetPass Calls: 111 Draw Calls: 233 Total Batches: 155 Tris: 92.2k Verts: 105.5k
(Dynamic Batching) Batched Draw Calls: 182 Batches: 13 Tris: 4.1k Verts: 13.3k
(Static Batching) Batched Draw Calls: 115 Batches: 31 Tris: 29.7k Verts: 42.0k
Used Textures: 0 - 0 B
RenderTextures: 22 - 13.9 MB
RenderTexture Switches: 24
Screen: 64x64 - 48.0 KB
VRAM usage: 13.9 MB to 13.9 MB (of 0 B)
VBO Total: 0 - 0 B
VB Uploads: 53 - 1.1 MB
IB Uploads: 36 - 29.0 KB
Shadow Casters: 2
10幀：
SetPass Calls: 152 Draw Calls: 661 Total Batches: 210 Tris: 267.3k Verts: 380.9k
(Dynamic Batching) Batched Draw Calls: 564 Batches: 21 Tris: 18.4k Verts: 51.2k
(Static Batching) Batched Draw Calls: 694 Batches: 63 Tris: 155.6k Verts: 250.9k
Used Textures: 0 - 0 B
RenderTextures: 22 - 13.9 MB
RenderTexture Switches: 24
Screen: 64x64 - 48.0 KB
VRAM usage: 13.9 MB to 13.9 MB (of 0 B)
VBO Total: 0 - 0 B
VB Uploads: 64 - 2.6 MB
IB Uploads: 40 - 109.0 KB
Shadow Casters: 2
9幀：
SetPass Calls: 208 Draw Calls: 894 Total Batches: 265 Tris: 360.4k Verts: 544.8k
(Dynamic Batching) Batched Draw Calls: 1511 Batches: 42 Tris: 48.1k Verts: 142.3k
(Static Batching) Batched Draw Calls: 861 Batches: 85 Tris: 231.4k Verts: 313.3k
Used Textures: 0 - 0 B
RenderTextures: 22 - 13.9 MB
RenderTexture Switches: 24
Screen: 64x64 - 48.0 KB
VRAM usage: 13.9 MB to 13.9 MB (of 0 B)
VBO Total: 0 - 0 B
VB Uploads: 52 - 3.5 MB
IB Uploads: 42 - 280.0 KB
Shadow Casters: 2
19、 重新思考16位顏色
UI 圖片有些是漸變色， 如果使用不是RGBA32 , 就會出現類似下圖中 444 的不和諧的過度。
Unity支持兩種類型的16位顏色。
ARGB4444，分別對紅色，綠色，藍色和alpha應用4位（16步），紅色爲5位（32步），綠色爲6位（64步），對於沒有alpha的藍色爲5位的RGB 565。它在下面縮寫並稱爲“4444”和“565”。
這取決於alpha通道需要多少位，所以這次我們只考慮RGB圖像質量而不考慮alpha通道。
如果8位RGB有256級，可用顏色的數量將爲1677萬。如果這變爲565存儲方式，它將降至65,000種顏色（梯度還不是特別明顯）。 右端是4444存儲方式，只有4096種顏色，顯然梯度更明顯。
人類視覺存在不均勻性。
例如，就紅色，綠色和藍色而言，人類視覺對綠色敏感並且對藍色不敏感。在上一篇文章中提到的RGB565壓縮格式中，雖然有32級紅色和藍色，但是爲綠色準備了64級。它考慮到人的視覺特徵。
這裏面還涉及到 “類視覺特徵的問題” 人類視覺總是有一個強調對比度的過濾器。“淺色旁邊的顏色稍暗的顏色顯得更暗”，“淺色旁邊的淺色顏色看起來更亮”等。 https://baike.baidu.com/item/%E9%A9%AC%E8%B5%AB%E5%B8%A6
解決這個問題可以使用： 抖動： https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering
爲了在減少顏色數量時難以注意到圖像質量的劣化，抑制該側面抑制是有效的。如果大區域彼此相鄰，則可以容易地看到側面抑制的效果，但是如果顏色像噪聲一樣散開，則強調的線條將變得分開並變得不太可見。
作者提供了導入後處理腳本！！！！！ 但是感覺變得模糊了~~~
索引顏色紋理的記憶 - 懷舊的調色板 - （有點涉及到 LUT ?）
宣雨凇的文章分享 和這個內容類似：
《Unity3D研究院編輯器之批處理圖片添加抖動（三十三）》
20、 UGUI 的富文本標籤 會增加 頂點這個問題在之前的分享中提到過， 但是會不會有性能影響？沒有測試過！！！！
今天看到文章有人測試了。
UnityEngine.UI的性能調查從“富文本不增加頂點紋理？”開始。
Unity的版本是2017.4.8f1。
首先通過創建很多Text 文本 ， 然後開啓和不開啓說明 Outline組件的影響(超多的定點數對性能的影響)。這個不用介紹了
作者使用 官方的 “Outline” 組件來比較負載。 其中多了一個組件 DegenerateQuadRemover ，就是在進行Outline處理之前把富文本的頂點數據移除掉。
只有Text 2-4
Text 富文本 44-88
Text 富文本 + 過濾 2-6 我測試這個過濾跟Outline沒關係呀~~~~~~
Text 富文本+Outline 220-660
Text 富文本+Outline + 頂點過濾 10 + 30
在啓用Outline時它已成爲1個字符變成 6個頂點。
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.UI;
public class DegenerateQuadRemover : BaseMeshEffect
{
private static List<UIVertex> _verticesCache; // 反覆使用
static DegenerateQuadRemover()
{
_verticesCache = new List<UIVertex>();
}
public override void ModifyMesh(VertexHelper vh)
{
vh.GetUIVertexStream(_verticesCache);
// TOOD: 在這做點什麼
Process(_verticesCache);
vh.Clear();
vh.AddUIVertexTriangleStream(_verticesCache);
}
/// <summary>
/// 循環一次處理一個字符，如果有一個區域則複製到一個新數組，如果它是一個區域0，它將通過。
/// 但是，要嚴格計算區域，你必須查看所有六個頂點並且它太慢，所以這裏我們只看到每個字符有兩個頂點。
/// 富文本標籤的頂點對於第一個和第二個頂點具有相同的座標，因此此x和y之間的差異的平方爲0。
/// 位置是Vector3，但您不必查看z。它完全取決於當前版本中Text的頂點生成行爲，因此如果Unity版本發生更改，它可能會卡住。
/// </summary>
/// <param name="vertices"></param>
public static void Process(List<UIVertex> vertices)
{
int letterCount = vertices.Count / 6;
Debug.Assert((letterCount * 6) == vertices.Count); // 如果不能被6整除的頂點數量
int srcVertexIndex = 0;
int dstVertexIndex = 0;
for (int letterIndex = 0; letterIndex < letterCount; letterIndex++)
{
vertices[dstVertexIndex + 0] = vertices[srcVertexIndex + 0];
vertices[dstVertexIndex + 1] = vertices[srcVertexIndex + 1];
vertices[dstVertexIndex + 2] = vertices[srcVertexIndex + 2];
vertices[dstVertexIndex + 3] = vertices[srcVertexIndex + 3];
vertices[dstVertexIndex + 4] = vertices[srcVertexIndex + 4];
vertices[dstVertexIndex + 5] = vertices[srcVertexIndex + 5];
var p0 = vertices[dstVertexIndex + 0].position;
var p1 = vertices[dstVertexIndex + 1].position;
var dx = p1.x - p0.x;
var dy = p1.y - p0.y;
if (((dx * dx) + (dy * dy)) > 0f) // 不是富文本標籤
{
dstVertexIndex += 6;
}
srcVertexIndex += 6;
}
vertices.RemoveRange(dstVertexIndex, vertices.Count - dstVertexIndex);
Debug.Assert(vertices.Count == dstVertexIndex);
}
}
左邊沒有頂點移除。有84000個頂點，圖表完全是紫色的。右邊是頂點移除，有15,000個頂點。該圖顯着改善。
然而，雖然它已經下降，但它超過30毫秒。它在使用富文本之前大概是20毫秒，因此富文本可能很重。事實意味着標籤字符的字體紋理相關處理完全在運行，而且它會是浪費的。能夠根據一個文本中的部分生成顏色和大小不同的字符串很方便，但如果格式是固定的，則最好分成多個文本。例如，
<color=#ffffff>Level:</color><color=#ff88cc>25</color>
在這種情況下，如果您將數字從“Level:”和“25” 分開， 直接設置Text組件的屬性，就可以移除富文本的標記。
注：我在Unity 2019.3 版本中測試發現富文本標記已經沒有這個問題了！！！！
21、 當您想要使對象變暗或去飽和時
，能夠直接更改HSV（色調，飽和度，亮度）非常有用。您需要使用Color.RGBToHSV和Color.HSVToRGB來更改Unity腳本中的HSV。
https://techblog.kayac.com/unity_advent_calendar_2018_15
至於Shader中使用 ， 直接使用標籤就可以了， 之前文章中提到過的！！
或者 有人自己在Shader中實現轉換函數： 暴露對應的參數：
22、[Unity]一個動態繪製框的介紹
https://techblog.kayac.com/unity_advent_calendar_2018_06
在屏幕右側繪製一個大白框，但最初這個框架是使用Image繪製的，當在Unity的場景窗口中將顯示切換到Overdraw時，它如下所示。
下面是改進之後的效果：
仔細觀察， 圖像中的白框影響的範圍已經變得特別小， 不要問 爲什麼不把白框做在要框住的圖片內？ 因爲動畫：
注： 記得Unity 現在已經支持 Sprite 不僅僅是 正方形框的取頂點了， 可以設置Mesh 模式， 就不會有這個問題。
23、您是否厭倦了在Unity中浪費寶貴的時間在 build platform switches ？
Turbo Switch PRO簡單，比內置開關快100倍！
https://twitter.com/crosstales/status/1155728956068388864
https://assetstore.unity.com/packages/tools/utilities/turbo-switch-pro-60040
24、 Unity AssetBundle高效加密案例分享
https://blog.uwa4d.com/archives/USparkle_AssetBundle.html
public static AssetBundle LoadFromFile(string path, uint crc, along offset);
Parameters
利用Offset 來達到加密的。
Unity3D研究院之加密Assetbundle不佔內存（一百零五）
宣雨凇是通過 Unity2017.2提供了一個新的API AssetBundle.LoadFromStream
25、 日本一個遊戲學院， TECH x GAME COLLEGE
定期分享遊戲開發技術； 比如遊戲服務器的分享有：
- 如何製作 一個由gumi的CTO教授的正確的遊戲網絡服務器（如何製作正確的遊戲網絡服務器＃1/2）
- 爲什麼共享數據的完整性很重要？遊戲中服務器端設計的基礎知識（如何製作正確的遊戲網絡服務器＃2/2）
“RDBMS + NoSQL” 關係型數據庫管理系統 + 非關係型數據庫
遊戲數據存儲設計技巧之一是“保護共享數據的完整性”。
利用Laravel 實現遊戲服務器在100ms內調整通信時間的 裝置
（用Laravel＃1/2調整遊戲服務器）
爲什麼Laravel×水平分散很難？ 引入橫向分佈的機制和實施
（用Laravel＃2/2調整遊戲服務器）
域驅動設計，要做多遠？可以採取哪些措施來克服開發現場的“問題”
（遊戲開發中的領域驅動設計和無服務器架構＃1/2）
無服務器，接下來會發生什麼？DDD和無服務器專家稱技術的未來
（遊戲開發中的領域驅動設計和無服務器架構＃2/2）
（用於高效遊戲開發的RDB簡介＃1/2）
哪個更快，RDBMS還是NoSQL？在遊戲開發中充分利用RDB
（用於高效遊戲開發的RDB簡介＃2/2）
服務器通用基礎架構爲遊戲開發帶來了什麼 從技術選擇的原因到引入的角度
（如何創建一個通用的服務器基礎來提高遊戲質量＃1/2）
你爲什麼選擇Kotlin？不斷髮展的遊戲製作，直到創建一個通用的服務器平臺
（如何創建一個通用的服務器基礎來提高遊戲質量＃2/2）
（在世界上使用Google雲端平臺）
Mastodon和Netflix所見的容器的未來 - 容器能否成爲服務開發的主流？
TECH x GAME COLLEGE 2018.10.15
櫻花互聯網研究中心主任Ken Sugakita到目前爲止談論集裝箱
TECH x GAME COLLEGE 2018.10.12
TECH x GAME COLLEGE 2018.9.27
TECH x GAME COLLEGE 2018.9.26
TECH x GAME COLLEGE 2018.9.10
TECH x GAME COLLEGE 2018.9.7
26、 使用Unity 2019.1進行移動遊戲和XR開發
https://www.qualcomm.com/news/onq/2019/07/18/mobile-game-and-xr-development-unity-20191
- 面向數據的技術堆棧
- 對腳本化渲染管道的更新
- 建議API支持
Unity 2019.1現在具有對Vulkan的本機渲染插件支持。Vulkan是新一代3D圖形和計算API，可爲PC和移動平臺上的現代GPU提供高效，跨平臺的訪問。Vulkan與舊版移動渲染API（如OpenGL ES 3.x）的主要優勢在於速度。Vulkan旨在利用多個CPU核心，允許應用程序並行構建多個線程中的命令列表。這允許應用程序利用設備上的CPU內核來幫助提高性能。
在Unity 2019.1中爲Vulkan添加本機渲染插件是一個好消息，因爲Vulkan在Qualcomm Adreno 5xx和6xx系列GPU上受支持。Snapdragon開發人員可以使用Adreno GPU SDK進行支持Vulkan的渲染操作。開發人員可以使用Unity的默認Auto Graphics API，它從版本2019.1開始啓用Vulkan。這意味着如果構建目標/底層硬件支持Vulkan，那麼將選擇Vulkan作爲渲染API; OpenGL將用於所有其他情況。在Unity 2019.1之前，OpenGL是默認的渲染API，必須手動啓用Vulkan支持。
有關Adreno上的Vulkan的更多概述，請查看使用Vulkan on Mobile開發3D圖形。
在移動設備上使用Vulkan開發3D圖形
https://developer.qualcomm.com/blog/developing-3d-graphics-vulkan-mobile
由於Qualcomm®Snapdragon™移動平臺（Snapdragon 820及以上版本）上的Adreno™5xx和6xx系列GPU支持Vulkan
文章中提到很多優點。 我覺得最大的缺點就是設備支持範圍小， 很多老機型，低端機肯定都不支持， 不過肯定是將來的趨勢~~
結論
Vulkan提供的好處對於希望爲移動平臺開發或移植遊戲和/或VR解決方案的圖形程序員來說是令人興奮的。當與我們的平臺搭配Adreno 5xx和6xx GPU配合使用時，Vulkan爲移動設備上的高性能圖形提供了強大的API。有關更多信息，我們建議您查看以下三個鏈接：
- 我們的Adreno SDK for Vulkan可在此處獲取。
- 我們在YouTube上有一個廣泛的多部分系列，用於在Adreno上使用Vulkan進行開發。你可以在這裏找到第1部分。
- 還有對福爾康一個很好的入門教程在這裏。
27、 看到一個截圖， 發現Unity沒有這個選項啊：
https://indienova.com/tag/unite-shanghai-2019/
Unite 2019 Shanghai：一步解決 Unity 遊戲新安全風險
現在支持 Windows/Android 平臺遊戲的加密，包括 Mono/IL2CPP 模式。
28、關於Unity遊戲的7個 GUI 優化提示
Unity 有許多優化問題以及 GUI 實現的最佳實踐, 下面是其中的一些問題!
https://medium.com/@ahhaoah/unity-ui-optimization-procedures-4d0f6ca2d827
很多是老生常談的內容：
1、 canvas 的更新代價， 嘗試劃分Canvas。 動靜分離
2、Raycast Target屬性 問題， （注，這個在2019.2版本中默認是不勾選的了）
3、Camera.main 根據World Space Canvas，Unity將每幀7-10次訪問Camera.main，每個Graphic Raycaster。每次訪問時，Camera.main也會調用Object.FindObjectWithTag！
4、Pooling UI Objects 池化是避免不斷創建和刪除對象的有用方法。 但是。 池化UI對象涉及重新生成和禁用，但這會導致層次結構被弄髒兩次，並且也會污染新的層次結構。 所以： 首先禁用該對象，然後將其重新指定父級 放到池中。 從池中獲取對象時，請先重新使用它，更新數據，重新指定父級等。 然後在啓用它。
5、Hiding a Canvas 就是， 避免Disable 對象。 或者更好的處理是 更改Canvas對象的Layer最好了， 也不會弄髒Canvas中的數據。 可以達到隱藏整體的效果。
6、 Texture Atlases ，共享相同材質的每個對象（效果粒子，紋理）都在同一個DrawCall中，並將立即發送到GPU。
7、Stacking UI 堆疊
任何啓用的GUI元素都會導致draw call，無論其位置如何。 屏幕外並啓用的UI對象會增加繪製調用的數量。將UI圖像/文本堆疊在一起會導致更多的透支overdraw，並會減慢速度。
禁用屏幕外的遊戲對象和UI元素，或將屏幕外UI遊戲對象的父級更改爲非UI遊戲對象。 （屏幕外的對象並不會被裁剪調，依然在合拼在DrawCall ， 頂點和三角面沒有減少）
其他Unity UI性能提示
1、限制Text組件中“Best Fit”和“Rich Text”的使用。 （Rich Text 佔用頂點和三角面的問題在2019版本中已經修復了）
2、不要使用dynamic，如果可能請使用 bitmap/static 字體。 這個是爲什麼？ 英文可能沒有內存的壓力吧， 但是中文肯定不行~
3、限制Text遊戲對象上Outline / Shadow組件的使用。相反，在位圖字體bitmap font中烘焙效果。（應該也是針對英文）
4、如果可能的話，堅持使用'simple'的精靈。避免使用大型“tiled”精靈。
5、展平transform hierarchy。嵌套越多，正確定位子項所需的變換計算就越多。
6、取消選中“Canvas”上設置中的“Pixel Perfect”。Big performance hitter.
7、Screen Space Overlay UI 比Screen Space Camera略快。在Overlay中，UI立即繪製在屏幕頂部，避免了Camera空間必須經過的所有剔除和排序。
8、首選 enabling/disabling畫布本身而不是整個遊戲對象。避免整個層次結構上的OnEnable / OnDisable回調，這可能很昂貴。
9、在從池中借用對象之前啓用它時，首先更新池對象屬性。這樣可以避免對對象層次結構造成不必要的污染
10、使用包含許多Item的ScrollRects，將Canvas（沒有勾選Pixel Perfect）附加到ScrollRects，以便滾動item不會弄髒外部Canvas中的元素
References
- College, U. (2017, Septemeber 16). Unity3D Object Pooling — How to use them & why you should. Retrieved from YouTube: https://www.youtube.com/watch?v=7UswSdevSpw
- Unity. (2019, January). Some of the best optimization tips for Unity UI. Retrieved from Unity: https://unity3d.com/how-to/unity-ui-optimization-tips
- Unity. (n.d.). Unity UI Performance tips — Sharing my findings. Retrieved from Unity: https://forum.unity.com/threads/unity-ui-performance-tips-sharing-my-findings.524916/
29、
Unity UI Best Practices ： https://medium.com/@dariarodionovano/unity-ui-best-practices-40964a7a9aba
1.明智地命名UI元素
就像場景中的對象或層次結構中的文件一樣，UI元素應該通過元素類型的指示符合理命名。
2、一份普通分辨率清單是你最好的朋友
3、保持Rect Transform中的值清潔， 嘗試將數字四捨五入以避免小數。
4、將Scale保持在1
默認情況下，UI元素的Scale應始終爲1，除非動畫稍微更改或應用特定用例。
5、不需要時不要使用紋理
對於可以使用白色矩形構建的UI元素，不要使用任何紋理，而是使用帶有空源的Image組件。 （注意，空的Image會破壞合批）
30、 自動測試Unity應用程序，不加選擇地點擊
https://techblog.kayac.com/?page=1564527600
具體運行效果查看：
https://hiryma.github.io/AutoTapTest/index.html
討論遊戲開發中耐力測試的支持工具。從技術上講，它只是“我會讓EventSystem有點脫離代碼並自己點擊它”，但我認爲將它視爲質量保證的廣泛問題的一部分比僅僅認爲它是一個技術問題更有成效。
怎麼用？ https://github.com/hiryma/UnitySamples/tree/master/AutoTapTest/Assets/Kayac/Debug
將 DefaultDebugTapper 組件 附加到某個GameObject 上。
- 排除的對象設置
- 我想定製在哪裏Tap
例如，
我想在技能選擇模式中優先擊中技能卡
我很少想在戰鬥中按下退出按鈕
按下緩存清除按鈕很困難
由於拖動是主輸入系統，如果遊戲是隨機的，則遊戲不會進展
31、
方便在遊戲內查看 問題的 可視化顯示擴展：
- 三年前的 【Unity】uGUI でゲーム內に Hierarchy と Inspector を表示できる「RuntimeEditor」紹介 http://baba-s.hatenablog.com/entry/2017/12/25/090100
- 【Unity】橫向きかつクリックやタップ可能なゲームで使用できるカスタマイズ可能なデバッグメニュー「UniDebugMenu」を GitHub に公開しました
http://baba-s.hatenablog.com/entry/2019/03/19/090000 運行時執行修改參數或者命令
- [Unity]我們在GitHub上發佈了“UniDebugPanel”，可以在遊戲中顯示可自定義的按鈕進行調試。
http://baba-s.hatenablog.com/entry/2018/08/07/090000 如果通過宏定義控制包中是否開啓這個功能。
- [Unity]“UnityRuntimeInspector”簡介，其中Hierarchy和Inspector可以在遊戲中使用uGUI顯示
http://baba-s.hatenablog.com/entry/2017/12/26/091500
https://github.com/yasirkula/UnityRuntimeInspector
- [Unity]我們發佈了探測器UI“UniSimpleProfiler”，它可以檢查GitHub上FPS，GC發生和內存使用的發生次數。
比較簡單的統計數據顯示
- [Unity]推出“Mini Profiler Pro”，它可以在遊戲畫面上顯示FPS和內存使用情況（圖5.40美元，免費版）
http://baba-s.hatenablog.com/entry/2018/01/11/230400 有兩個曲線統計
- 幀率和 內存
https://github.com/microsoft/VisualProfiler-Unity
- 我製作了Raycaster並使調試UI獨立於UGUI https://techblog.kayac.com/debugging-ui-using-raycaster-self-maded
[Unity]調試UI，可以使用一個DrawCall而不會污染場景 https://techblog.kayac.com/unity_advent_calendar_2018_01
32、 Shader Tips：
1） Using Unity ShaderLab's built-in Time for animating shaders, but want it to not be affected by timeScale? Use global Shader vars! Also super handy for passing in custom fog values or changing color schemes. Can pretty much pass in anything!
使用Unity ShaderLab的內置時間來設置着色器的動畫，但是希望它不受timeScale的影響？ 使用全局着色器變量！ 傳遞自定義霧值或更改顏色方案也非常方便。 幾乎可以傳遞任何東西！
https://docs.unity3d.com/ScriptReference/Shader.html 設置各種類型的 Global 參數。
2）Want to map objects to a 3D coord grid, but don't want/can't use multidimensional/jagged arrays due to memory? Try Dictionary, but use this IEquatable struct instead of Vector3 keys for fast int hashcode & no boxing
想要將對象映射到3D coord grid，但是由於內存不希望/不能使用多維/鋸齒狀數組？ 嘗試使用Dictionary，但是使用這個IEquatable結構而不是Vector3鍵來快速進行int hashcode並且沒有裝箱
https://pastebin.com/HfgUfNDa public struct Vector3Int : IEquatable<Vector3Int> {
枚舉作爲key 會產生GC 我知道， 但是struct 也會產生就忘了， 今天看到這個提示纔想起來。
《IL2CPP優化：避免裝箱》https://blogs.unity3d.com/cn/2016/08/11/il2cpp-optimizations-avoid-boxing/ 這個文章評論中，提示IL2cpp也沒有解決。
《優化使用struct和enum作爲Unity C＃中的鍵的字典》https://ejonghyuck.github.io/blog/2016-12-12/dictionary-struct-enum-key/ 當你聲明一個結構Equals()，GetHashCode()它並沒有實現方法。
調用包含詞典的方法時，對象object.Equals將通過比較語法運行。最簡單的方法是聲明並繼承System.Collections.Generic命名空間IEqualityComparer<T>中存在的接口。創建新的Dictionary實例時，將實例放在構造函數中。
// Struct.
public struct SomeStruct
{
public int a, b;
}
class SomeComparer : IEqualityComparer<SomeStruct>
{
bool IEqualityComparer<SomeStruct>.Equals (SomeStruct x, SomeStruct y)
{
return x.a == y.a && x.b == y.b;
}
bool IEqualityComparer<SomeStruct>.GetHashCode (SomeStruct obj)
{
return obj.a ^ obj.b;
}
}
// Usage.
Dictionary<SomeStruct, int> dic = new Dictionary<SomeStruct, int>(new SomeComparer());
// Enum.
public enum SomeEnum
{
StateA = 1,
StateB = 2
}
class SomeComparer : IEqualityComparer<SomeEnum>
{
bool IEqualityComparer<SomeEnum>.Equals (SomeEnum x, SomeEnum y)
{
return (int)x == (int)y;
}
bool IEqualityComparer<SomeEnum>.GetHashCode (SomeEnum obj)
{
return ((int)obj).GetHashCode();
}
}
// Usage.
Dictionary<SomeEnum, int> dic = new Dictionary<SomeEnum, int>(new SomeComparer());
注意： 這個問題在.Net 4.x版本中已經不存在了
3）Want to create a distortion material that warps the view, but don't feel like painting normal maps? Try this shader instead, which distorts using mesh normals and blends edges using an inverse rim/fresnel calculation. Sphere mesh as example
想要創建一個扭曲視圖的扭曲材質，但是不想繪製法線貼圖？ 請嘗試使用此着色器，使用網格法線扭曲並使用反向邊緣/菲涅爾inverse rim/fresnel計算混合邊緣。 以球體網格Sphere mesh爲例
Mesh Distortion着色器： https://pastebin.com/DiHD2SdC
4） Want to create a hologram effect with scanlines? Try combining fresnel/rim with alpha, plus a 2D screenspace panning scanline texture. Works best with smooth normals 想用掃描線創建全息圖效果？ 嘗試將菲涅耳/邊緣與alpha相結合，再加上2D屏幕空間平移掃描線紋理。 最平滑的法線效果最佳 https://twitter.com/phi6/status/1001220419351916545
5）As part of #RecompileGame's unique aesthetic, we have created a glitchy "fog-of-war" effect to gradually reveal the terrain as the player explores it. Here's a write-up on how we implemented this using a combination of shaders & VFX
作爲#RecompileGame獨特美學的一部分，我們創造了一個小故障的“戰爭迷霧”效果，以便在玩家探索時逐漸展現出地形。 我們結合使用自定義着色器，VFX和Unity的Culling Group API來實現所需的效果。
https://phigames.co.uk/rcfog.html
6） 回到親子關係！ 回到事物的搖擺。 這是一篇新的文章，分析了我們如何在#RecompileGame中實現了毛刺撞擊着陸衝擊波效果。 使用着色器，VFX，動畫曲線和音頻提示創建
Back from paternity! Getting back into the swing of things. Here's a new write-up breaking down how we achieved the glitchy crash landing shockwave effects in #RecompileGame. Created using shaders, VFX, animation curves & audio cues
https://phigames.co.uk/rcshockwave.html
7） 新的一年，一個新的Shader寫作！
我用＃RecompileGame全手動相機解決遮擋問題的一些技巧： -
- 藍色噪聲抖動可平滑淡出剪裁的幾何體
- Render使用ZTest遮擋玩家
A new year, a new Shader writeup!
Some tricks I used to solve occlusion problems with #RecompileGame's fully manual camera :-
-Blue noise dithering to smoothly fade out clipped geometry
-Render occluded player using ZTest
https://phigames.co.uk/rcoccluded.html
Updated the article to provide further clarification on the occluded shader's rendering order. Specifically, to use a queue which is one less than what the character is normally rendered at, so that we don't run into self-occlusion issues.更新了文章，以進一步說明遮擋着色器的渲染順序。 具體來說，要使用比正常渲染字符少一個的隊列，這樣我們就不會遇到自遮擋問題。
8）Reading some interesting things on VFX today, so I decided to capture some freeze frames from #RecompileGame. I'm using custom shaders to control our bloom ramp, alpha cutouts & distortion to give @Skepsisology maximum control to make our VFX pop (THREAD)
今天在VFX上閱讀一些有趣的東西，所以我決定從#RecompileGame中捕獲一些凍結幀。 我正在使用自定義着色器來控制我們的綻放漸變，alpha切除和失真
最大限度地控制我們的VFX彈出（THREAD）
All our VFX systems use a custom shader, where the output emission (and thus bloom) is derived from particle color value. We define in the material a minimum and maximum emission, with exponential decay - this way we don't have to stick to bloom threshold on the post process
我們所有的VFX系統都使用自定義着色器，其中輸出發射（以及因此bloom）來自粒子顏色值。 我們在材料中定義最小和最大發射，指數衰減 - 這樣我們就不必在後期處理上堅持綻放閾值
The custom shader also does NOT support any transparency. Instead we take the alpha value from the particle color and apply an alpha cutout from a noise cloud texture instead. Result: Stylized Zelda style fire and smoke
自定義着色器也不支持任何透明度。 相反，我們從粒子顏色中獲取alpha值，並從噪聲雲紋理中應用alpha切除。 結果：風格化的塞爾達風格火與煙
Finally we also use a mesh distortion shader to add rippling distortion effects to our dashes, crashes, explosions and more. It's subtle but effective
最後，我們還使用網格失真着色器爲我們的破折號，崩潰，爆炸等添加波紋失真效果。 這是微妙但有效的。 用我粗暴的編碼着色器實際創建藝術作品:)
Yeah I hope you keep this bullet time/360 pause (can't remember if it was already in the demo), I love that feature in games and it's a great way to admire your beautiful particle effects! Beetle Adventure Racing comes to mind
是的，我希望你保持這個子彈時間/ 360暫停（不記得它是否已經在演示中），我喜歡遊戲中的這個功能，這是欣賞你美麗的粒子效果的好方法！想到甲殼蟲冒險賽車
We use a default threshold value so that everything else (eg terrain etc...) looks good, but we need more control for our particles as Unity's VFX system doesn't allow HDR (brightness > 1) in the Start Color/Color Over Lifetime pickers
我們使用默認閾值，以便其他所有內容（例如地形等......）看起來不錯，但我們需要對粒子進行更多控制，因爲Unity的VFX系統不允許在開始顏色/顏色中使用HDR（亮度> 1） 終身揀貨員
9）、Our faux volumetric shader for #RecompileGame transforms simple meshes into fancy atmospheric lighting. Inverse fresnel on smooth normals helps soften the edges, and the variable falloff prevents clipping. Link to shader:
我們用於#RecompileGame的人造體積着色器將簡單的網格轉換爲花哨的大氣照明。 平滑法線上的反菲涅爾有助於軟化邊緣，可變衰減可防止削波。 鏈接到着色器：https://pastebin.com/AjjUrn7m
Alright! So, all 3d meshes have normals, that is, direction perpendicular to the surface. Imagine sticking a pencil into the centre of an orange. That pencil is the normal to the surface of the orange at that point. Thread cont...
好的！ 因此，所有三維網格都有法線，即垂直於曲面的方向。 想象一下，將鉛筆插入橙色的中心。 那支鉛筆是那個時候橙色表面的法線。 線程控制...
Smooth normals means normals across the surface of the mesh are smoothed out. Imagine a lowpoly sphere. With non-smoothed normals, you'd be able to see the faceted surfaces, it would look like Kryten's head. With smoothing it would look like a real sphere, even though its lowpoly
平滑法線表示平滑網格表面的法線平滑。 想象一下低聚球。 使用非平滑法線，您將能夠看到刻面的表面，它看起來像Kryten的頭部。 通過平滑，它看起來像一個真正的球體，即使它是低聚物
So we have a mesh with smooth normals, for a volumetric light, we could use a cone. Now, fresnel. aka rim lighting. With regular fresnel, normals pointing away from camera are brighter than normals pointing towards you. So you get more light on the rim of the object. Like this
所以我們有一個光滑法線的網格，對於體積光，我們可以使用錐形。 現在，菲涅耳。 又名邊緣照明。 使用常規菲涅耳，指向遠離相機的法線比指向您的法線更明亮。 因此，您可以在物體的邊緣獲得更多光線。 像這樣
10）、Oh how I love volumetric lighting! Here's a brief thread on how I made this cool scanning laser sweep thing for Recompile
哦，我喜歡體積照明！ 以下是關於我如何爲重新編譯製作這種酷掃描激光掃描的簡短線程
First I use this library as a base. You can use this to add volumetrics to any Unity spotlight. Making sure to enable shadows so the light doesn't clip through level geometry
首先，我使用這個庫作爲基礎。 您可以使用此功能將體積添加到任何Unity聚光燈。 確保啓用陰影，以便光線不會剪切水平幾何體
https://github.com/SlightlyMad/VolumetricLights/
Then I add noise (to simulate fog/mist) and this simple light cookie to get the narrow sweeping beam with bright edges, instead of your usual conical spotlight shape
然後我添加噪音（模擬霧/霧）和這個簡單的光餅乾，以獲得具有明亮邊緣的窄掃描光束，而不是通常的錐形聚光燈形狀
Then I layer several of these lights (2 or 3) and animate the spotlight angle to get the sweeping movement
然後我將這些燈中的幾個（2或3）分層並設置聚光燈角度以獲得掃描運動
Finally I make one of those lights flicker to give it a faux strobe effect! So easy, and so much fun!最後，我讓其中一個燈閃爍，給它一個人造頻閃效果！ 這麼簡單，好玩！