第一篇：Unity之工作總結(jié)
圖片格式
----------1 DrawCall
-----------2
? 圖片格式：
NGUI生成的圖集的圖片格式是PNG格式，但是無(wú)論是什么格式的圖片 Unity都會(huì)自己生成一套格式，并且打包的時(shí)候不會(huì)用文件夾下面的格式，而是Unity自己格式。
如果你用的UITexture 你可以對(duì)每一張圖來(lái)修改格式，比如顏色數(shù)比較少的圖片可以使用16bit，如果沒有透明，可以使用pvr或者etc 這樣圖片會(huì)小很多。如果是UISprite 只要有透明的 就必須使用RGBA32 要不然UI會(huì)很難看。
除去 UITextuer和Atlas的圖片之外（因?yàn)橛型该鳎?，其余的貼圖必須是2的冪次方。因?yàn)橹挥?的冪次方圖片，并且沒有透明通道的才會(huì)被壓縮。Ios會(huì)被壓縮成pvr格式，Andriod會(huì)壓縮成etc格式。壓縮之后會(huì)小很多。
人物貼圖 場(chǎng)景題圖 特效貼圖 一定要是2的冪次方。
貼圖透明通道分離，壓縮格式設(shè)為ETC/PVRTC 最初我們使用了DXT5作為貼圖壓縮格式，希望能減小貼圖的內(nèi)存占用，但很快發(fā)現(xiàn)移動(dòng)平臺(tái)的顯卡是不支持硬件解壓DXT5的。因此對(duì)于一張1024x1024大小的RGBA32貼圖，雖然DXT5可將它從4MB壓縮到1MB，但系統(tǒng)將它送進(jìn)顯卡之前，會(huì)先用CPU在內(nèi)存里將它解壓成4MB的RGBA32格式（軟件解壓），然后再將這4MB送進(jìn)顯存。于是在這段時(shí)間里，這張貼圖就占用了5MB內(nèi)存和4MB顯存；而移動(dòng)平臺(tái)往往沒有獨(dú)立顯存，需要從內(nèi)存里摳一塊作為顯存，于是原以為只占1MB內(nèi)存的貼圖實(shí)際卻占了9MB！
所有不支持硬件壓縮格式都有相同的問題。解決方案：
現(xiàn)在Andriod硬件最廣泛支持的時(shí)Etc ,IOS上支持的時(shí)PVRTC。但這兩種格式都是不帶透明（Alpha）通道的，因此我們需要將每張?jiān)假N圖的透明通道分離出來(lái)，寫進(jìn)另一張貼圖的紅色通道里，這兩張?zhí)貓D都采用Etc/Pvrtc壓縮。渲染的時(shí)候 將兩張貼圖都送進(jìn)顯存。同時(shí) 我們修改了NGUI的shader 在渲染時(shí)第二張貼圖的紅色通道寫入到第一張貼圖的透明通道里恢復(fù)原來(lái)的顏色：
1.2.3.4.5.6.} fixed4 frag(v2f i): COLOR {
fixed4 col;
col.rgb = tex2D(_MainTex, i.texcoord).rgb;col.a = tex2D(_AlphaTex, i.texcoord).r;return col * i.color;
這樣，一張4MB的1024x1024大小的RGBA32原始貼圖，會(huì)被分離并壓縮成兩張0.5MB的ETC/PVRTC貼圖（我們用的是ETC/PVRTC 4 bits）。它們渲染時(shí)的內(nèi)存占用則是2x0.5+2x0.5=2MB。
? DrawCall 當(dāng)兩個(gè)renderQueue相鄰的DrawCall使用了相同的貼圖、材質(zhì)和shader實(shí)例時(shí)，這兩個(gè)DrawCall就可以合并。但需要注意的是DrawCall合并不見得會(huì)提高性能，有時(shí)反而會(huì)降低性能
如果是UIGeometry為了渲染繪制準(zhǔn)備數(shù)據(jù)，那么UIDrawCall其實(shí)是定義了渲染繪制需要的基本組件。這里拿煮菜做個(gè)比喻幫助理 解：UIGeometry好比為煮菜準(zhǔn)備食材，UIDrawCall好比是煮菜的工具（鍋，爐子等），UIPanel就是大廚了決定著什么時(shí)候該煮 菜，UIWidget（UILabel，UISprite和UITexture）是這道菜怎么樣的最終呈現(xiàn)。
UIWidget分別用UpdateGeometry和WriteToBuffers對(duì)UIGeometry的ApplyTransform和 WriteToBuffers進(jìn)行封裝調(diào)用，ApplyTransform是根據(jù)UIPanel的坐標(biāo)調(diào)整Vertices的坐 標(biāo)，WriteToBuffers將UIGeometry的Vertices，UVs和Colors添加進(jìn)UIPanel的Vertices，UVs和 Colors的BetterList中。
這里還有一個(gè)細(xì)節(jié)就是：UIGeometry中的Vertices，UVs和Colors的BetterList的buffer什么時(shí)候得到，因?yàn)檫@些都 是UIWidget或其子類的信息，所以在UIWidget的子類UILabel，UISprite和UITexture中OnFill函數(shù)生成 UIGeometry的BetterList的buffer。
UIWidget這個(gè)腳本中的兩個(gè)函數(shù)：WriteToBuffers，OnFill，UpdateGeometry。
WriteToBuffers和OnFill這兩個(gè)函數(shù)都是將Vertices，UVs和Colors等add進(jìn)參數(shù)的List中去，查看 WriteToBuffers的調(diào)用出發(fā)現(xiàn)其參數(shù)是UIPanel的Vertices，UVs和Colors，而OnFill的參數(shù)是 UIGeometry的Vertices，UVs和Colors。
WriteToBuffers只是對(duì)UIGeometry的封裝調(diào)用，也就是說(shuō)將UIGeometry的Vertices，UVs和Colors等信息add進(jìn)UIPanel的對(duì)應(yīng)List中。
UIGeometry的腳本，一直有一個(gè)疑問：UIGeometry的Vertices，UVs和Colors的List沒有看到add方法的執(zhí)行，只有在WriteToBuffers被add。直到看到了OnFill才恍然大悟，雖然UIWidget的OnFill是虛函數(shù)，沒有具體實(shí)現(xiàn)，看了下 UISprite重寫的OnFill函數(shù)，就是把Vertices，UVs和Colors 添加到UIGeometry的Vertices，UVs和Colors中。所有UI組件的Vertices，UVs和Colors都匯集到UIPanel的Vertices，UVs和Colors去了，然后 UIPanel指定給UIDrawCall渲染就行了
UIWidget的一些實(shí)現(xiàn)細(xì)節(jié)，MakePixelPerfect():對(duì)gameObject的localPosition和locaScale進(jìn)行微調(diào)和糾正。SetDirty():調(diào)用UIPanel的SetDirty()對(duì)組件的變更進(jìn)行重建（rebuilt)。Uiwidge UIGeometry& UIDrawCall 的關(guān)系：
UIWidget 中有兩個(gè)變量UiDrawCall mDrawcall 和UIGeometry mGeo 的verts uvs cols 的BetterList,然后UiWidget 的UpdateGeometry函數(shù)對(duì)UIGeometry 的ApplyTransform()和WriteToBuffer()調(diào)用進(jìn)行更新.每一個(gè)UIwidget都有一個(gè)UIGeometry 但是不都有一個(gè)UIDrawCall,而是通過(guò)Batch合并達(dá)到減少DrawCall的數(shù)量，UiDrawCall是有UiPanel生成的。
DrawCall的數(shù)量?jī)?yōu)化
根據(jù)上述描述可以得出一個(gè)結(jié)論：使用相同material的連續(xù)的Uiwidget(UILable UiSprite)公用一個(gè)UIDrawcall。通過(guò)這個(gè)結(jié)論我們可以得到一個(gè)解決DrawCall過(guò)多的問題，UIPanel生成DrawCall時(shí)是Fill()方法。Fill 方法對(duì)UiWidget.list進(jìn)行檢測(cè)把使用相同Material的連續(xù)的Uiwidget合并生成一個(gè)DrawCall ,UIWidget.List 的排序是根據(jù)UiWidget的Depth進(jìn)行的。所以解決方案有兩種：
1.修改UiWidget(UiLable UIwidget)的Depth,限定UIwidget.List的排序 2.重寫Uiwidget的CompareFunc()方法。（重寫UIWidget的CompareFunc也是可以的，按照Material的name優(yōu)先排序，只有當(dāng)material一樣是才考慮depth進(jìn)行排序：）
3.無(wú)重疊時(shí)自動(dòng)重排。繪制順序按照Hierarchy
采用第二種方式減少DrawCall: Material leftMat = left.material;Material rightMat = right.material;if(leftMat == rightMat){ if(left.mDepth < right.mDepth)return-1;else if(left.mDepth > right.mDepth)return 1;else return 0;} if(leftMat!=null & rightMat!= null)return string.Compare(leftMat.name,rightMat.name);if(leftMat!= null)return-1;if(rightMat!= null)return 1;
return(leftMat.GetInstanceID()< rightMat.GetInstanceID())?-1 : 1;
夾層問題：
因?yàn)镸aterial使用的Shader使用了透明，這樣就不能做深度測(cè)試，也就是Mesh的“深度”是不影響的，這樣最終的顯示就跟Shader的 renderQueue有關(guān)了，即renderQueue越大，顯示的越靠前面（重疊的圖層，renderQueue越大，越靠前）。當(dāng)然現(xiàn)在只有增加一 個(gè)DrawCall（如多使用一個(gè)UIPanel或用另外一個(gè)Material)來(lái)做到Material的夾層效果。
特效層級(jí)：
粒子系統(tǒng)的渲染順序列默認(rèn)為3000 而NGUI的渲染順序默認(rèn)是從3000開始，當(dāng)有嵌套的Panel或者Deoth更高的panel時(shí)，NGUI的渲染順序會(huì)高于3000
解決方案：
1.修改Ngui中的panel腳本中的默認(rèn)RenderQueue 調(diào)整到3000以下，這樣就不會(huì)擋住粒子特效。當(dāng)窗口顯示在特效上面時(shí)把窗口的RenderQueue調(diào)整到3000以上，就解決了。
2.使用另外一個(gè)攝像機(jī)顯示特效，但是Ui窗口切換時(shí)不太好控制
3.修改例子特效的shader中的RenderQueue的值（需要考慮特效中的層級(jí)關(guān)系）一級(jí)界面 二級(jí)界面..浮動(dòng)窗口
1.不同圖集
項(xiàng)目中做到復(fù)雜一些的界面，經(jīng)常會(huì)用到多個(gè)圖集，以技能界面為例，項(xiàng)目中常用的圖片放到共用圖集中，這是一個(gè)圖集，技能界面本身獨(dú)有的元素，比如跟技能職業(yè)相關(guān)的背景，算作第二個(gè)圖集，還有一些技能圖標(biāo)，圖標(biāo)單獨(dú)歸類到一個(gè)圖集中，再一個(gè)就是字體的圖集?；疽粋€(gè)界面如此分法，最多需要4個(gè)圖集。NGUI的圖集之間的 處理，默認(rèn)是靠調(diào)整控件的Z值來(lái)區(qū)分的，但是這里他可以調(diào)整同一個(gè)圖集每個(gè)一個(gè)控件的Z值，其實(shí)不是很好。經(jīng)常會(huì)出現(xiàn)圖層相互遮擋的情況，尤其對(duì)于控件比較多的界面，一段時(shí)間回過(guò)來(lái)再修改界面的時(shí)候，整個(gè)要崩潰。
解決方案：在UIPanel中，為每一個(gè)Material添加一個(gè)layer的變量，當(dāng)同一圖層靠depth來(lái)決定前后關(guān)系，不同圖層靠 layer來(lái)決定前后關(guān)系，在繪制UIDrawCall的時(shí)候，根據(jù)layer對(duì)跟節(jié)點(diǎn)做一定偏移。這樣就能從Z值中解放出來(lái)。如果大家也有碰到圖層的問題，可以參考這樣的做法，以此種方法來(lái)處理圖層關(guān)系，簡(jiǎn)單，做過(guò)項(xiàng)目的圈套UI，還未有不能解決的情況。
? UI自適應(yīng)
Scaling Style 的作用是制定UiRoot的縮放類型，如果是PixelPerfect ,Minimum Height 和Maximum Height 才起作用，scaling style 選擇的是
Pixelperfect 要對(duì)Minimum Height和Maximum Height進(jìn)行設(shè)置。(如果是PixelPerfect縮放類型，當(dāng)屏幕的分辨率大于Maximum Height，則以Maximum Height 為基礎(chǔ)縮放，反之，如果屏幕分辨率小于Minimum Height 則以Minimum Height為基礎(chǔ)進(jìn)行縮放。例如，如果屏幕高度為1000，而設(shè)置的Maximum Height值為800，則UI界面整體放大為原來(lái)的1000/800=1.25倍。)FixedSize : 跟Manual Height有關(guān)
FixedSizeOnMobiles :跟Manual Height有關(guān)
只是針對(duì)IOS和Android上的判斷，也就是說(shuō)只有IOS和Android平臺(tái)下FixedSizeOnMobiles才起作用.FixedSize或FixedSizeOnMobiles，則縮放只以Manual Height為參考，屏幕分辨率的高度值不同于此設(shè)置值時(shí)，則根據(jù)其比例（即Screen Height / Manual Height）對(duì)整棵UI樹的進(jìn)行“等比”縮放（寬度的縮放比也是此比例值）。
注釋：如果設(shè)置FixedSize,UIWidget.height（以UiRoot默認(rèn)值進(jìn)行高度縮放）是不會(huì)改變的，不管實(shí)際屏幕分辨率的像素是多少，Anchor Stretch的背景圖片高度始終是manualHeight.UIRoot下的UIWidget的height參數(shù)一直都是實(shí)際的值
UIRoot 是基于高度進(jìn)行縮放的如何做以寬度適配。
UIRoot是基于高度放縮的，即放縮的比例是以高度為參考的，所以UIRoot有一個(gè)manualHeight的參數(shù)。那么對(duì)于橫版游戲顯然不行，要是 能實(shí)現(xiàn)基于寬度放縮。所以可以通過(guò)設(shè)置一個(gè)“manualWidth”的參數(shù)來(lái)做。比如我們項(xiàng)目中使用的是 1024 作為UI的寬屏尺寸，通過(guò)換算設(shè)置manualHeight的值：
int height = Mathf.Max(2, Screen.height);manualHeight = Screen.height * 1024 / Screen.width;//基于寬度的屏幕分辨率自適應(yīng)
注釋：UIRoot其實(shí)就做了一件事情：根據(jù)Screen.height和UIRoot.activeHeight的比例來(lái)調(diào)整UIRoot的 loaclScal，從而保證UIWidget（UISprite，UILabel）可以按照其本身的大小進(jìn)行設(shè)置，而不用經(jīng)過(guò)復(fù)雜的換算過(guò)程。
? 資源分離打包與加載
資源分離打包與加載是最有效的減小安裝包體積與運(yùn)行時(shí)內(nèi)存占用的手段。一般打包粒度越細(xì)，這兩個(gè)指標(biāo)就越小。但打包粒度也并不是越細(xì)就越好。如果運(yùn)行時(shí)要同時(shí)加載大量小bundle，那么加載速度將會(huì)非常慢——時(shí)間都浪費(fèi)在協(xié)程之間的調(diào)度和多批次的小I/O上了。此需要有策略地控制打包粒度。一般只分離字體和貼圖這種體積較大的公用資源。
? 關(guān)閉貼圖的讀寫選項(xiàng)
Unity中導(dǎo)入的每張貼圖都有一個(gè)啟用可讀可寫（Read/Write Enable）的開關(guān)，對(duì)應(yīng)的參數(shù)是TextureImporter.isReadable。選中貼圖后可在Import Setting選項(xiàng)卡中看到這個(gè)開關(guān)。只有打開這個(gè)開關(guān)才可以對(duì)貼圖使用Textuer2D.GetPixel，讀取或改寫貼圖資源的像素，但這就需要系統(tǒng)在內(nèi)存中保留一份貼圖的拷貝，以供Cpu訪問，但是一般游戲運(yùn)行過(guò)程中不會(huì)有這樣的需求，因此我們對(duì)所有貼圖都關(guān)閉這個(gè)開關(guān)，只在中做貼圖導(dǎo)入后處理（比如對(duì)原始提貼圖分離透明通道）時(shí)需要打開這個(gè)選項(xiàng)。這樣，上文提到的1024x1024大小的貼圖，其運(yùn)行時(shí)的2MB內(nèi)存占用又可以少一半，減小到1MB。Texture圖片空間和內(nèi)存占用分析
紋理大小影響：
可以將其他（非二的冪-“NPOT”）紋理大小用于 Unity非二的冪紋理大小通常占用的內(nèi)存稍多一點(diǎn)，由 GPU 進(jìn)行讀取的速度可能較慢，因此考慮到性能，最好盡可能使用二的冪大小。如果平臺(tái)或 GPU 不支持 NPOT 紋理大小，則 Unity 會(huì)縮放紋理并將其填補(bǔ)為下一個(gè)二的冪大小，這甚至?xí)褂酶鄡?nèi)存并使加載更慢
Iphone：
空項(xiàng)目
空間占用量42.3M
ipa包10M 10張1200*520 無(wú)壓縮Texture 單張圖占用量2.8M
空間占用兩70.2M ipa包 22.9M 10張1200*520壓縮成1024*1024 PVRTC4 單圖占用量0.5M 空間占用量47.3M ipa包 13.2M 10張1024*1024 無(wú)壓縮Texture
單圖占用量4M
空間占用量82.M
ipa包14.6M 10張1024*1024壓縮為PVRTVC4格式
單張圖占用量0.5M 空間占用量 47.3M ipa包 11.6M
綜上所述：
1.2的N次方大小的圖片會(huì)得到引擎更大的支持，包括壓縮比率，內(nèi)存消耗 打包壓縮大小，而且支持的力度非常大。
2.減小圖片的占用大小和內(nèi)存方式有：圖片大小變化（Maxsize）,色彩位數(shù)變化（16位色 32位色），壓縮PVRC格式
3.U3D對(duì)于圖片的格式是自己生成的，而并不是你給它什么它用什么格式。一張1024*1024圖在無(wú)壓縮的格式下，他會(huì)被U3D無(wú)壓縮文件像是存放，也就是說(shuō)U3D 里的Texture Perview 里顯示的占用大小**M 不只是內(nèi)存占用的大小，還是空間占用大小。
Unity 圖片壓縮格式介紹：
U3D 的內(nèi)部機(jī)制為自動(dòng)生成圖片類型來(lái)替代我們的圖片在圖片的壓縮方式需要進(jìn)行謹(jǐn)慎的選擇。幾種比較主要的壓縮格式：
RGBA32 BIT/AutomaticTurecolor(256*256 256k)
格式為無(wú)壓縮最保真格式，最消耗內(nèi)存和空間的格式。RGBA16 BIT/
格式為無(wú)壓縮16位格式，比32位節(jié)省一半的空間和內(nèi)存，與Automatic16 相同。RGBA Compressed PVRTC 4bits格式為PVRTC 圖片格式，它相當(dāng)于把圖片更改了壓縮方式新生成了一個(gè)圖片來(lái)替換原來(lái)的圖片格式
貼圖格式：
3D游戲中貼圖的的分類：
UI貼圖
ui是按照 1280*853比例出的圖
3D場(chǎng)景貼圖 主要是因?yàn)槎嘀夭蓸拥木壒省?D游戲一般來(lái)說(shuō)都是受攝像機(jī)遠(yuǎn)近大小改變而采取不同的采樣大小，如果不設(shè)置多重采樣的話，在遠(yuǎn)處有非常多的白色噪點(diǎn)。
2D游戲
所有都不需要勾選多重采樣，具有3D性質(zhì)的貼圖，我們都需要勾選上GENERATE MIP MAPS，這樣會(huì)使貼圖大小增加25%這樣。
正方貼圖與非正方貼圖也要區(qū)分: 非正方貼圖只有16位的壓縮（相當(dāng)于真彩色減半），所以最好游戲中都是正方的貼圖。正方貼圖： IOS：
普通不透明： RGB PVRTC 4 BITS
普通透明： RGBA PVRTC 4 BITS(256*256 32kb)Androis:
普通不透明： RGB ETC 4 BITS(256*256 32kb)
普通透明：因?yàn)闆]有通用的兼容模式，所以一般情況是用RGBA 16 BITS 或是針對(duì)不同的GPU選擇 DXT5/ATC8 BITS/ETC2 8BITS。如果技術(shù)支持，可以采用 RGB ETC 4 BITS 加一張Alpha 8的貼圖來(lái)實(shí)現(xiàn)透明效果。
非正方形：
一般采用16位壓縮，16位色會(huì)帶來(lái)顏色損失，如果本來(lái)美術(shù)就按16位色畫的話，就不會(huì)帶來(lái)?yè)p失。日本的很多2D游戲都是采用那個(gè)16位來(lái)畫的。少漸變 和艷色。
不透明貼圖： RGB 16 BIT（256*256 128KB）
透明貼圖： RGBA 16 BIT（256*256 128KB）
高清不壓縮貼圖：
RGBA 32 BIT(256*256 256kb)
對(duì)于不重要的貼圖，模糊度低的貼圖，建議不僅要采取像素壓縮，還要直接壓縮其大小。如光照貼圖壓到512或256。如背景原本1024的圖直接壓到256。玩家不注意到就可以了。
注意：
U3D所有圖片的壓縮格式都會(huì)以另一種方式存儲(chǔ)，不會(huì)以你給的方式存儲(chǔ)，只有你指定了某種格式，他才會(huì)轉(zhuǎn)換成你要的格式。而且在Andriod 里的并不一定有效，因?yàn)锳ndriod的機(jī)型多，GPU的渲染方式也不一樣，RGBA16 適應(yīng)于所有機(jī)型
? GameObject數(shù)量
場(chǎng)景中GameObject的數(shù)量也是衡量性能的重要指標(biāo)，頻繁的創(chuàng)建 和銷毀GameObjec 是非常耗時(shí)，場(chǎng)景中存在的GameObject會(huì)占用內(nèi)存，如果GameObject上掛有物體的話，每個(gè)GameOject的腳本都需要實(shí)力化。
? 整理圖集
整理圖集的主要目的是節(jié)省運(yùn)行時(shí)內(nèi)存（雖然有時(shí)也能起到合并DrawCall的作用）。從這個(gè)角度講，顯示一個(gè)界面時(shí)送進(jìn)顯存的圖集尺寸之和是越小越好。一般有如下方法可以幫助我們做到這點(diǎn)： 1)在界面設(shè)計(jì)上，盡量讓美術(shù)控件設(shè)計(jì)成九宮格拉伸，即UiSprite的類型是Sliced.這樣美術(shù)素材可以切出一張很小的圖片在unity中做拉伸。當(dāng)然一個(gè)九宮格也就意味著其定點(diǎn)數(shù)量會(huì)從4個(gè)增加到16個(gè)（如果九宮格的中心格子采用Tiled做平鋪類型的話，定點(diǎn)數(shù)會(huì)更多），構(gòu)建DrawCall的開銷會(huì)更大。但一般只要DrawCall安排合理就不會(huì)出問題 2)同樣在界面設(shè)計(jì)上 盡量設(shè)計(jì)成對(duì)稱的形式，這樣在切圖的時(shí)候美術(shù)切圖的時(shí)候就可以只切一部分，我們?cè)赨ntiy中將完整的圖案拼出來(lái)，比如一個(gè)圓形圖案我們可以只切四分之一，不過(guò)與上述第一點(diǎn)類似這樣會(huì)增加定點(diǎn)個(gè)數(shù)，同時(shí)也會(huì)增加場(chǎng)景中GameObject的個(gè)數(shù)，因?yàn)镚ameObject的數(shù)量增多時(shí)會(huì)占用跟多的內(nèi)存，所以只對(duì)尺寸較大的圖案采用這種方法。3)4)確保不要讓不必要的貼圖素材駐留內(nèi)存，更不要在渲染時(shí)將無(wú)關(guān)的貼圖素材送進(jìn)顯存。為此需要將圖集按照界面分開，按模塊劃分圖集，一個(gè)界面中的UISprite也不要使用別的界面的圖集。數(shù)量龐大 且數(shù)量不固定的物品不要使用圖集 要采用UITexture 減少圖集中的空白地方。完全透明的像素和不透明的像素所占用的空間是一樣的，因此在像素量不變的情況下，要盡量減少圖集中的空白。比如有時(shí)一張1024x1024的圖集中，素材所占的面積還沒超過(guò)一半，這時(shí)可以考慮將這張圖集切成兩張512x512的圖集。（可能有人會(huì)問為什么不能做成一張1024x512的圖集，這是因?yàn)閕OS平臺(tái)似乎要求送進(jìn)顯存的貼圖一定是方形。）當(dāng)然，兩張不同圖集的DrawCall是無(wú)法合并的，但這并不是什么問題。5)
? 根據(jù)各個(gè)UI控件的設(shè)計(jì)安放Panle,隔開DrawCall 在合并DrawCall時(shí)需要注意，如果將會(huì)移動(dòng)變化的UI控件和一個(gè)靜止不變的UI控件的DrawCall合在一起，當(dāng)其中一個(gè)UI控件（UiWeight）的位置 大小 或顏色等屬性發(fā)生變化時(shí)，UIPanle就需要重建這個(gè)Panle上的所有DrawCall。有時(shí)重建一個(gè)DrawCall會(huì)消耗不少的CPU，它需要計(jì)算這個(gè)DrawCall上的所有頂點(diǎn)信息，包括頂點(diǎn)位置 UV和顏色等，如果很多的控件都集中在同一個(gè)DrawCall上，那么其中一個(gè)控件上有一點(diǎn)點(diǎn)變化，這個(gè)DrawCall上的所有的頂點(diǎn)就都需要遍歷一遍。而如果我們的UI又大量的采用九宮格拉伸，使控件的頂點(diǎn)數(shù)量就會(huì)變得更多。因此重建一個(gè)DrawCall 的開銷會(huì)更大。
因此需要將UI控件分組，將一段時(shí)間內(nèi)會(huì)發(fā)生變化的控件----比如怪物頭頂?shù)难獥l和傷害跳字放在同一個(gè)Panle上，并且這些Panle上只有這些控件，其余基本不變的控件放在別的控件Panle上，這樣兩類控件就隔開到不同的DrawCall在不同的Panle中，當(dāng)一個(gè)控件發(fā)生變化而導(dǎo)致DrawCall重建時(shí)，就不需要遍歷那些沒有變化的控件。因?yàn)樵诿佬g(shù)設(shè)計(jì)上，一段時(shí)間內(nèi)在變化的控件總是少數(shù)，所以優(yōu)化效果十分明顯，節(jié)省的CPU占用率能達(dá)到25%。
?
優(yōu)化錨點(diǎn)內(nèi)部邏輯，使其只在必要時(shí)更新
在上一點(diǎn)優(yōu)化了Panel的DrawCall重建效率之后，我們發(fā)現(xiàn)NGUI錨點(diǎn)自身的更新邏輯也會(huì)消耗不少CPU開銷。即使是在控件靜止不動(dòng)的情況下，控件的錨點(diǎn)也會(huì)每幀更新（見UIWidget.OnUpdate函數(shù)），而且它的更新是遞歸式的，使CPU占用率更高。因此我們修改了NGUI的內(nèi)部代碼，使錨點(diǎn)只在必要時(shí)更新。一般只在控件初始化和屏幕大小發(fā)生變化時(shí)更新即可。不過(guò)這個(gè)優(yōu)化的代價(jià)是控件的頂點(diǎn)位置發(fā)生變化的時(shí)候（比如控件在運(yùn)動(dòng)，或控件大小改變等），上層邏輯需要自己負(fù)責(zé)更新錨點(diǎn)。
?
降低貼圖分辨率
這一招說(shuō)白了其實(shí)就是減小貼圖素材的尺寸。比如對(duì)一張?jiān)谠嬂锍叽缡?00x80的貼圖，我們將它導(dǎo)入U(xiǎn)nity后會(huì)把它縮小到50x40，即縮小兩倍。游戲?qū)嶋H使用的是縮小后的貼圖。不過(guò)這一招是必然會(huì)顯著降低美術(shù)品質(zhì)的，美術(shù)立馬會(huì)發(fā)現(xiàn)畫面變得更模糊，因此一般不到程序撐不住的時(shí)候不會(huì)采用。
? 界面的延遲加載和定時(shí)卸載
如果一些界面的重要性較低，并且不常被使用，可以等到界面需要打開顯示的時(shí)候才從bundle加載資源，并且在關(guān)閉時(shí)將自己卸載出內(nèi)存，或者等過(guò)一段時(shí)間再卸載。不過(guò)這個(gè)方法有兩個(gè)代價(jià)：一是會(huì)影響體驗(yàn)，玩家要求打開界面時(shí)，界面的顯示會(huì)有延遲；二是更容易出bug，上層寫邏輯時(shí)要考慮異步情況，當(dāng)程序員要訪問一個(gè)界面時(shí)，這個(gè)界面未必會(huì)在內(nèi)存里。因此目前為止我們?nèi)晕磳?shí)施該方案。目前只是進(jìn)入一個(gè)新場(chǎng)景時(shí)，卸載上一個(gè)場(chǎng)景用到但新場(chǎng)景不會(huì)用到的界面。
? 避免頻繁調(diào)用GameObject.SetActive 我們游戲的某些邏輯會(huì)在一幀內(nèi)頻繁調(diào)用GameObject.SetActive，顯示或隱藏一些對(duì)象，數(shù)量達(dá)到一百多次之多。這類操作的CPU開銷很大（尤其是NGUI的UIWidget在激活的時(shí)候會(huì)做很多初始化工作），而且會(huì)觸發(fā)大量GC。后來(lái)我們改變了顯示和隱藏對(duì)象的方法——讓對(duì)象一直保持激活狀態(tài)（activeInHierarchy為true），而原來(lái)的SetActive(false)改為將對(duì)象移到屏幕外，SetActive(true)改為將對(duì)象移回屏幕內(nèi)。這樣性能就好多了。
?
NGUI性能消耗點(diǎn)匯總
使用LinkedList
BetterList是一個(gè)數(shù)組 LinkedList
NGUI節(jié)點(diǎn)查找非常耗時(shí)。
?
代碼中非必要的堆分配
1)
我們應(yīng)避免使用foreach循環(huán) ：一般建議是避免使用foreach循環(huán)，盡量使用for或者while循環(huán)，我在Unity論壇遇到很多人提到這個(gè)建議。這背后的原因咋一看似乎是合理的，foreach只是語(yǔ)法封裝，因?yàn)榫幾g器處理代碼的流程大體是下面這樣：
foreach（SomeType s in someList）s.DoSomething（）;轉(zhuǎn)換為：
using（SomeType.Enumerator enumerator = this.someList.GetEnumerator（））{
while（enumerator.MoveNext（））{
SomeType s =（SomeType）enumerator.Current;s.DoSomething（）;} } 每次使用foreach時(shí) 都會(huì)創(chuàng)建一個(gè)enumerator 對(duì)象，一個(gè)System.Collections.IEnumerator的接口實(shí)例。但是創(chuàng)建在堆棧上還是堆上是都可能的 幾乎所有的System.Collections.Genric(list
2)應(yīng)該避免使用閉包和LINQ嗎？
匿名方法和lambda表達(dá)式會(huì)引起內(nèi)存泄露嗎？答案是：這取決于C#編譯器，有兩種區(qū)別很大的方式來(lái)處理
int result = 0;void Update（）{
for（int i = 0;i < 100;i++）{
System.Func
現(xiàn)在我們?cè)谕泄芏x方式上做一些小小的改變：
System.Func
通過(guò)把“p”替換為“i++”，我們已經(jīng)局部定義方法轉(zhuǎn)變成一個(gè)真的閉包（閉包是函數(shù)編程的一大支柱。它把數(shù)據(jù)和函數(shù)聯(lián)系到一起，更準(zhǔn)確的說(shuō)是非局部變量在函數(shù)之外定義。）在myFunc中，p是一個(gè)局部變量但i是一個(gè)非局部變量，屬于Update()方法。C#編譯器現(xiàn)在不得不將myFunc轉(zhuǎn)換成可訪問、甚至是可修改，包含非局部變量的方法。它通過(guò)聲明一個(gè)全新的類表示myFunc創(chuàng)建的引用來(lái)實(shí)現(xiàn)這一功能。For循環(huán)每次執(zhí)行都要分配一個(gè)類的實(shí)例，瞬間產(chǎn)生大量的內(nèi)存泄露（在我的電腦上每幀26KB）閉包概念在C#3.0 的時(shí)候被引入主要原因是LINQ。如果閉包回引起內(nèi)存泄露
3)協(xié)程
通過(guò)StartCoroutine()運(yùn)行一個(gè)協(xié)程，會(huì)隱式分配Unity Coroutine類（系統(tǒng)上占用21字節(jié)）和Enumerator(占用16個(gè)字節(jié))，所以在游戲運(yùn)行時(shí)盡量少用StartCoroutine()
4)字符串
C#和Unity內(nèi)存問題必須會(huì)提到字符串。從內(nèi)存角度，字符串很奇怪，因?yàn)椋麄兪嵌逊峙淝也蛔兊?。?dāng)你連接兩個(gè)字符串時(shí)（無(wú)論是變量還是常量）：運(yùn)行時(shí)不得不分配至少一個(gè)新的字符串對(duì)象存儲(chǔ)新的結(jié)果。String.Concat()有效地通過(guò)調(diào)用FastAllocateString()分配新對(duì)象，但是必定會(huì)產(chǎn)生多余的堆分配（上面例子在我的系統(tǒng)上占用40字節(jié)）。如果你需要在運(yùn)行時(shí)修改或者連接字符串，最好使用 System.Text.StringBuilder
5)裝箱
盡量減少裝箱
6)庫(kù)方法
各種庫(kù)方法也會(huì)隱式分配內(nèi)存。捕捉它們最好的方法是分析。我之前已經(jīng)寫過(guò)的 foreach-循環(huán)，大多數(shù)標(biāo)準(zhǔn)泛型集合不會(huì)導(dǎo)致堆分配。Dictionary
? 查找堆分配的兩種方式 1.使用Unity profiler 2.反編譯自己的代碼
在CIL中查找內(nèi)存分配
CIL代碼的優(yōu)勢(shì)在于堆分配代碼不會(huì)被隱藏。相反，完全可以在反編譯的代碼中找到堆分配的三種指令。
1)
newobj
2)
newarr <元素類型>：在堆上創(chuàng)建一個(gè)數(shù)組。元素類型在參數(shù)中指定。
3)
box <值類型標(biāo)記>：裝箱（傳遞數(shù)據(jù)）專用指令，在第一部分已經(jīng)介紹過(guò)。
? Unity腳本執(zhí)行順序和編譯順序 1)腳本執(zhí)行順序
Unity 在后臺(tái)會(huì)把每個(gè)腳本的 Awake、Start、Update、LateUpdate、FixedUpdate 等等，所有的方法合并到一起。然后按照 代碼的執(zhí)行順序進(jìn)行執(zhí)行。
編譯順序
? 首先從腳本語(yǔ)言類型來(lái)看，Unity3d支持3種腳本語(yǔ)言，都會(huì)被編譯成CLI的DLL 如果項(xiàng)目中包含有C#腳本，那么Unity3d會(huì)產(chǎn)生以Assembly-CSharp為前綴的工程，名字中包含”vs”的是產(chǎn)生給Vistual Studio使用的，不包含”vs”的是產(chǎn)生給MonoDevelop使用的。
? 對(duì)于每一種腳本語(yǔ)言，根據(jù)腳本放置的位置(其實(shí)也部分根據(jù)腳本的作用，比如編輯器擴(kuò)展腳本，就必須放在Editor文件夾下)，Unity會(huì)生成4中后綴的工程。其中的firstpass表示先編譯，Editor表示放在Editor文件夾下的腳本。
Assembly-CSharp-filepass-vs.csproj Assembly-CSharp-Editor-filepass-vs.csproj Assembly-CSharp-vs.csproj Assembly-CSharp-Editor-vs.csproj 根據(jù)官方的解釋，它們的編譯順序如下：
(1)所有在Standard Assets、Pro Standard Assets或者Plugins文件夾中的腳本會(huì)產(chǎn)生一個(gè)Assembly-CSharp-filepass-vs.csproj文件，并且先編譯；
(2)所有在Standard Assets/Editor、Pro Standard Assets/Editor或者Plugins/Editor文件夾中的腳本產(chǎn)生Assembly-CSharp-Editor-filepass-vs.csproj工程文件，接著編譯；
(3)所有在Assets/Editor外面的，并且不在(1),(2)中的腳本文件(一般這些腳本就是我們自己寫的非編輯器擴(kuò)展腳本)會(huì)產(chǎn)生Assembly-CSharp-vs.csproj工程文件，被編譯；
(4)所有在Assets/Editor中的腳本產(chǎn)生一個(gè)Assembly-CSharp-Editor-vs.csproj工程文件，被編譯。
之所以按照這樣建立工程并按此順序編譯，也是因?yàn)镈LL間存在的依賴關(guān)系所決定的。好了，到此為止，我們可以很容易地判斷出上面舉的實(shí)例中，腳本的編譯順序(實(shí)際上，我已經(jīng)把順序?qū)懺诹四_本的文件名中了)一個(gè)Unity3d的工程中，最多可以產(chǎn)生多少個(gè)工程文件呢？
4*3*2=24
4個(gè)文件 3中編譯器 2種平臺(tái) 1 個(gè)工程
? IOS平臺(tái)崩潰的幾種情況。
1．在協(xié)程中要判斷對(duì)象是不是為空(list GameObject)在每次調(diào)用的時(shí)候都學(xué)要調(diào)用（因 為協(xié)程不能保證即使調(diào)用如果對(duì)象已銷毀但是依然使用時(shí)會(huì)卡死）。
2． Delegate的判斷（IOS 盡量使Event）
3． 如果引用靜態(tài)的static Compent的組件會(huì)出現(xiàn)卡死
4． Unity中的OnEnable Start Awake Disable Destory()都回延遲一幀 5． Unity在Ios對(duì)反射的支持不完整。
6． Awake 和Start函數(shù)執(zhí)行時(shí)機(jī), Awake 函數(shù)在這個(gè)腳本在場(chǎng)景中加載時(shí)就會(huì)調(diào)用，需要注意的是，Start函數(shù)也不是一定立即執(zhí)行的，它是在該腳本第一次調(diào)用Update函數(shù)之前調(diào)用的，也就是說(shuō)，如果這個(gè)腳本一開始的狀態(tài)是disable的，那么直到它變成enable狀態(tài)，在Update函數(shù)第一次執(zhí)行前，才會(huì)執(zhí)行Start函數(shù)。
7．Linq TO XML
untiy中配置文件需要注意的點(diǎn)：
pc端不區(qū)分文件大小寫。
Andriod不區(qū)分大小寫
Ios移動(dòng)端區(qū)分文件大小寫。
需要注意文件名稱大小寫。
? 資源優(yōu)化(內(nèi)存優(yōu)化)：
1．代碼中申請(qǐng)的內(nèi)存，一般是New 或者Instantiate操作 Instantiate中也是調(diào)用了New 2．及時(shí)設(shè)置釋放標(biāo)識(shí)符 變量設(shè)置為Null 超出變量作用域 Destory()3．及時(shí)Gc釋放內(nèi)存 需要注意
Gc時(shí)會(huì)造成游戲短時(shí)間的卡頓，影響游戲體驗(yàn) 需要選擇合適的時(shí)間Gc 4．盡可能的重用資源（貼圖 材質(zhì) 網(wǎng)格）
5．一般圖片資源占用的內(nèi)存最大，優(yōu)化效果最明顯（降低貼圖分辨率，在效果和大小之間找一個(gè)平橫點(diǎn)）
6．程序中的內(nèi)存池 對(duì)象池 必要時(shí)主動(dòng)釋放內(nèi)存
7．做AssetBundle資源的關(guān)系以來(lái)打包 動(dòng)態(tài)加載
卸載
8．C#中Struct數(shù)據(jù)在棧上 Class在堆上 局部數(shù)據(jù)盡量用Struct 減少Gc的頻率 9．按C++ 的思想來(lái)管理內(nèi)存，比如使用的內(nèi)存池，對(duì)象池 手工卸載 主動(dòng)Gc 注意在內(nèi)存和幀率之間做好平衡。
10．www 下載時(shí)需要注意變量聲明和要注意申請(qǐng)的內(nèi)存堆上的無(wú)用內(nèi)存
11．? Unity資源（加載/更新）
1.Resources
-打包集成到.asset文件里面及引用的資源as后se一個(gè)文件里面面可讀不可寫無(wú)
-只能用WWW類下載
StreamingAssets文件夾也是一個(gè)只讀的文件夾，但是它和Resources有點(diǎn)區(qū)別，Resources文件夾下的資源會(huì)進(jìn)行一次壓縮，而且也會(huì)加密，不使用點(diǎn)特殊辦法是拿不到原始資源的。但是StreamingAssets文件夾就不一樣了，它下面的所有資源不會(huì)被加密，然后是原封不動(dòng)的打包到發(fā)布包中，這樣很容易就拿到 里面的文件。所以StreamingAssets適合放一些二進(jìn)制文件，而Resources更適合放一些GameObject和Object文件。StreamingAssets 只能用過(guò)www類來(lái)讀取。
最后凡是在Hierarchy視圖對(duì)象引用過(guò)的資源文件也會(huì)被無(wú)條件打包到發(fā)布包中。如果有一部分文件可能沒有在Resources文件 夾下也沒有在StreamingAssets文件夾下，也沒有被Hierarchy視圖游戲?qū)ο笠?，那么這類資源是不會(huì)被打包到發(fā)布包中的。
3.PersistentDataPath無(wú)
-清除手機(jī)緩存文件會(huì)一并清理這里的東西
-隨意弄，可作為本地目錄讓W(xué)WW下載、也可以自己用FileInfo亂整
4.WWW.LoadFromCacheOrDownload
?
Unity常用目錄對(duì)應(yīng)的Android && iOS平臺(tái)地址
IOS:
Application.dataPath : Application/xxxxx/xxx.app/Data Application.streamingAssetsPath : Application/xxxxx/xxx.app/Data/Raw Application.persistentDataPath : Application/xxxxx/Documents Application.temporaryCachePath : Application/xxxxx/Library/Caches
Android:
Application.dataPath : /data/app/xxx.xxx.xxx.apk Application.streamingAssetsPath : jar:file:///data/app/xxx.xxx.xxx.apk/!/assets Application.persistentDataPath : /data/data/xxx.xxx.xxx/files Application.temporaryCachePath : /data/data/xxx.xxx.xxx/cache
? Unity的Android和IOS上相關(guān)的目錄結(jié)構(gòu)
Android:
-assets 游戲內(nèi)容相關(guān)的都在這里了res 圖標(biāo)之類的
-AndroidManifest.xml Android配置文件resources.arsc Java編譯后的二進(jìn)制文件
IOS:
-level0/level1… Scene
-sharedassets0/shaedassets1/… Scene相關(guān)的東西resources.assets Resources里面的東西-Raw StreamingAssets里面的東西
第二篇：Hamlet --- The unity of controverasal
Hamlet
---The combination of contradiction
As the saying goes, one thousand readers, there are one thousand Hamlets.Others may think he is a soldier, a hero or a thinker.However, in my mind, he is an immature teen-age youth who is the combination of contradictions.Firstly, as a prince, he is an idealist.He lives a luxurious life and is educated by humanism.Without knowing the dark aspects of the society, he is favored by his parents and respected by his people.We can see in the play that he believes the true, the good and the beautiful and he is a real perfectionist, which can also explain why he is so shocked by the things happen on him and doesn’t know how to deal with it perfectly.Experiencing the death of his father, the usurping the throne of his uncle and the remarriage of his mother, Hamlet’s dream turns into bubbles.He falls in to hell from the heaven and goes on the trip of revenge.The prince has to have common people’s feeling, sadness, hatred, disappointment, hypocrisy and so on.Secondly, he is definitely a great thinker but also an ordinary people who hesitates to practice his thought.He begins consider himself and his people after he listen to his dead Father King’s words.He even says “To be or not to be, this is a question: was bear the slings and arrows of outrageous fortune, or to take arms against a sea of troubles world, through the clearing their struggle, these two kinds of behavior, which is a more noble.” He falls in to deep thought and condemns himself.His father is murdered and the ghost of his father urges him to take the revenge.He doesn’t do anything.He wonders: how a coward or a indecent woman I am.He not only thinks of his own fate, but also considers everyone’s existence.There is no doubt that he is the great man of mind.“Now I clearly have reason, have the determination and have the strength, have a way of can start to do what I have to do, but I still in touted said: 'it needs to do.'But never expressed in action…” is the evidence for his hesitation.When his enemy is praying and he plans to kill him, he should consider that killing a man who is praying will allows him to go to haven, which makes him lose the chance to kill his uncle and commit the tragedy.Thirdly, he believes the true, the good and the beautiful, but he doesn’t believe his friends and his lover.It is his behavior that makes Ophelia dead.He pretends to be mad and kill her father by accident.Ophelia can’t bear the reality and goes to the place where she dates with her prince madly… His ignorance of others’ care and arrogance kill other four innocent people.Last but not least, he is the combination of the goodness and evil.On the one hand, he is pious to his parents, his girlfriend and his friends in a way.He bears the responsibility to take revenge on his uncle and to save the ordinary people.He tries his best to satisfy everyone but he also hurts many people.He takes his revenge on his uncle by hook or by crook.He kills Rosencrantz and Guildenstern.He is cold when he kills Polonius and heartless to Ophelia.Not merely does he lead to his own tragedy, but also leads to the whole play’s tragedy.All in all, the dejected prince wants to take revenge on his uncle, but he can’t find a proper way and his ability is not equal to his ambition.He is an idealist who has to face the cruel reality.As a great think who believes the true, the good and the beautiful, he hesitates to take the action and doubt everyone around him.He is the saver and also the destroyer.He is a giant and also an ordinary people.He is a noble prince and also an immature teen-age youth.
第三篇：unity烘焙光照貼圖
引言: 光影烘焙，英文叫Lightmapping 或 light baking。Unity自帶了Lightmapping的功能(是Illuminate Labs出的名為Beast的產(chǎn)品)。本系列教程分為4講： 第一講 光影烘焙 第二講 AreaLight 第三講 Light Probes 第四講 腳本控制
其中第三第四講講解的是動(dòng)態(tài)物體與烘焙后場(chǎng)景的融合。
光影烘焙
打開方式 Window – Lightmapping 有幾點(diǎn)需要注意：
1.所要烘焙物體的mesh 必須要有合適的lightmapping uv。如果不確定的話，就在導(dǎo)入模型設(shè)置中勾選 Generate Lightmap UVs 2.任何Mesh Renderer, Skinned Mesh Renderer 或者 Terrain都要標(biāo)注為static(lightmap static)
界面一：Object 點(diǎn)擊Bake Scene即開始烘焙
界面2：Bake 烘焙參數(shù)的設(shè)置 Mode:(1)Dual Lightmap mode:近景烘焙圖(near lightmaps)和遠(yuǎn)景烘焙圖(far lightmaps)都會(huì)被烘焙，只有deferred rendering path支持該模式。
(2)Single Lightmap mode:只有遠(yuǎn)景烘焙圖(far lightmaps)會(huì)被烘焙，(3)Directional Lightmap mode： Use in forward rendering: 一般可以忽略它。針對(duì)Dual lightmaps的設(shè)定,只在Mode選的是Dual時(shí)才會(huì)出現(xiàn)。在forward rendering模式下是否激活dual lightmaps,需要自己寫對(duì)應(yīng)的Shader。Quality：
High low 2個(gè)選項(xiàng)。決定采集射線的數(shù)量，對(duì)比界限，以及反鋸齒等設(shè)置。Bounces：
Global Illumination模擬中 light bounces的數(shù)量。0表示只有直接光照會(huì)被計(jì)算，如果要加入柔軟的，真實(shí)的間接光照的話，則至少填1。Sky Light Color：
模擬從天空從所有方向射來(lái)的光照。對(duì)室外場(chǎng)景很重要。
(注意：RenderSettings里的Ambient Light也參與烘焙，并且會(huì)覆蓋Sky Light。所以使用Sky Light的話，則需要關(guān)閉Ambient Light,把Ambient調(diào)成（0,0,0,0）即可)Sky Light Intensity：Sky Light的強(qiáng)度。0表示關(guān)閉Sky Light.Bounce Boost：加強(qiáng)Bounced light也就是間接光照的效果.Bounce Intensity：間接光照的效果強(qiáng)度。
Final Gather Rays:從所有收集的點(diǎn)發(fā)射的射線的數(shù)量，最高則效果最好。默認(rèn)為1000 Contrast Threshold: 越高表示光照越平滑同時(shí)細(xì)節(jié)越低
Interpolation：顏色計(jì)算方式。0表示線性插值，1表示基于梯度的高級(jí)插值。有時(shí)1會(huì)產(chǎn)生人工光照的失真效果。
Interpolation Points:越多表示光照越平滑同時(shí)細(xì)節(jié)越低。
Ambient Occlusion：環(huán)境閉塞（全局閉塞）在烘焙中的量，和光照無(wú)關(guān)，僅僅基于距離的效果
Lock Atlas：鎖上了，貼圖就不會(huì)變化，沒什么用。Resolution：
通常來(lái)說(shuō) Resolution設(shè)置平均每單位面積對(duì)應(yīng)lightmap的多少色素。該值越高代表單位面積的色素越多即越精細(xì)。反之越低越粗糙。默認(rèn)值為50。如果一個(gè)10x10的plane,resolution是50的話，在lightmap里該plane就占用500x500像素尺寸。
當(dāng)然也可以單調(diào)該數(shù)值。選中物體后，在lightmapping界面中會(huì)有Scale in lightmap的數(shù)值，表示的是該物體的烘焙信息在lightmap占的大小，1表示正常尺寸。0表示該物體沒有l(wèi)ightmap效果，但會(huì)影響其他物體的lightmap運(yùn)算。2表示正常尺寸的兩倍大小。Padding:在lightmap里,不同物體的烘焙圖的間距，單位為圖素(texel)
界面3:Maps 烘焙好后的map在這里顯示。Compressed： 是否壓縮lightmap Array Size（0~254）lightmaps array的尺寸
Lightmaps array:即下方的4張貼圖，空格會(huì)被視為黑圖，指數(shù)即下方的 0,1對(duì)應(yīng)Mesh Renderer及Terrain里的lightmap index。這個(gè)會(huì)自動(dòng)計(jì)算。
按下烘焙后，會(huì)在右下角有進(jìn)度條顯示。然后你就可以去喝喝咖啡泡泡妹子神馬的，放心，它烘焙好了會(huì)有Import asset提示并自動(dòng)切回Unity的。烘焙好之后，會(huì)產(chǎn)生與場(chǎng)景名稱相同的文件夾，一般來(lái)說(shuō)會(huì)有兩張.exr貼圖，LightmapFar-0和LightmapNear-0(僅在Dual模式下有near圖),當(dāng)物體距離攝像機(jī)小于Shadow Distance時(shí)，使用的是 實(shí)時(shí)燈 + LightmapNear-0。當(dāng)大于是使用的是LightmapFar-0，此時(shí)燈光對(duì)物體不起作用。
(注意：Shadow Distance的設(shè)置
(1)如果是編輯器里運(yùn)行：Lightmap display設(shè)置界面里的Shadow Distance,如下方左圖(2)如果實(shí)際運(yùn)行: Quality設(shè)置下的Shadow Distance，如下方右圖
Lightmap Display界面里的其他設(shè)置: Use Lightmaps：是否使用lightmaps,不勾選的話就沒有任何烘焙的效果了。
Show Resolution：當(dāng)勾選Show Resolution時(shí)，會(huì)有下圖所示類似國(guó)際象棋黑白相間的格子，一個(gè)格子對(duì)應(yīng)lightmap里所占用的一個(gè)texel Show Probes:是否顯示light probes,后面會(huì)講到。Show Cells:light probes分割形成的空間的數(shù)量。
當(dāng)物體烘焙好之后，不管是復(fù)制物體還是把物體做成prefab,都會(huì)繼承烘焙的效果。但是如果縮放的話，烘焙好的光容易出現(xiàn)問題。
被烘焙的物體并不要求特定的材質(zhì)或者Shader。只要物體的Shader使用的是Surface Shader,那么就可以被烘焙。
注意：一個(gè)場(chǎng)景只能烘焙一次，如果多次烘焙，效果是最后一次烘焙的效果。
最后推薦ShadowGun里的烘焙配置，如下圖，供大家參考。烘焙時(shí)間很短，效果也很好。極力建議大家搜下ShadowGun的demo來(lái)參考學(xué)習(xí)。里面無(wú)論是場(chǎng)景布局，光影分配，Godrays運(yùn)用，及烘焙等等都是極高的水準(zhǔn)。
第四篇：unity開發(fā)游戲的優(yōu)缺點(diǎn)
Unity做游戲的幾個(gè)優(yōu)勢(shì)：
1、跨平臺(tái)，平臺(tái)相關(guān)的功能Unity都已經(jīng)幫你實(shí)現(xiàn)好了。即便有些Unity沒有實(shí)現(xiàn)，也有插件幫你實(shí)現(xiàn)。
2、基于Unity的酷炫的粒子光效編輯。Unity本身就是一個(gè)功能強(qiáng)大的粒子編輯器。之前我還認(rèn)為cocos2d-x的粒子系統(tǒng)的功能足夠了，但是跟專業(yè)的編輯器比起來(lái)，遠(yuǎn)遠(yuǎn)不夠。粒子系統(tǒng)要跟粒子特效編輯器配合起來(lái)，其功能遠(yuǎn)遠(yuǎn)不是之配置一個(gè)粒子系統(tǒng)的幾個(gè)參數(shù)就可以的。cocos2d-x本身的粒子系統(tǒng)是很雞肋的功能，只能拿來(lái)做一些簡(jiǎn)單的光效，不可能用來(lái)做復(fù)雜的技能特效。
3、由于框架和架構(gòu)的優(yōu)勢(shì)，Unity的游戲可以極大程度避免崩潰和閃退。由于代碼都是c#寫的，并且是組件結(jié)構(gòu)，所以即便出了錯(cuò)誤也只是個(gè)異常而已，而不會(huì)影響到系統(tǒng)流程。
4、強(qiáng)大的性能分析工具，可以輕易的找到內(nèi)存和cpu的瓶頸。支持Android和iOS的真機(jī)運(yùn)行分析。
5、編輯器可以方便的進(jìn)行擴(kuò)展，不需要像傳統(tǒng)游戲公司一樣，有一個(gè)專門寫編輯器的部門。無(wú)論是場(chǎng)景編輯器還是技能編輯器都可以輕松搞定。如果想玩高科技的話，還可以把技能編輯器做成可拖拽的模塊化結(jié)構(gòu)，策劃可以像搭積木一樣來(lái)編輯技能。最重要的是，這些都是所見即所得的。
6、方便的資源管理系統(tǒng)。使用Unity，你不用特意維護(hù)幾份資源（比如原始資源、打包后的資源、iOS版本資源、Android版本資源等等），只要一份資源，然后Unity里面可以設(shè)置它的具體參數(shù)，比如使用紋理壓縮、最大限制在512x512大小等等。Unity發(fā)布游戲的時(shí)候會(huì)自動(dòng)根據(jù)平臺(tái)相關(guān)的導(dǎo)出選項(xiàng)導(dǎo)出正確的資源。
7、豐富的插件。有大量的功能我無(wú)論拿cocos2d-x還是Unity都不知道怎么實(shí)現(xiàn)。比如一些shader特效、物件碎裂的特效、場(chǎng)景破壞和變形的特效等等，這些在Unity插件中都可以找到對(duì)應(yīng)的實(shí)現(xiàn)。而且很多Unity的游戲都可以反編譯，無(wú)形中又可以學(xué)到很多東西。
8、熟悉之后確實(shí)感覺Unity很簡(jiǎn)單。很多功能都是成體系的自然而然的。比如物理、碰撞檢測(cè)、導(dǎo)航尋路、場(chǎng)景管理、場(chǎng)景烘焙。這些無(wú)論拿哪個(gè)出來(lái)都是相當(dāng)有技術(shù)的功能，但是在Unity中幾個(gè)按鈕、幾步操作就可以實(shí)現(xiàn)對(duì)應(yīng)的功能。
至于缺點(diǎn)也有一些：
1、最主要的，無(wú)論是Unity還是插件都是要收費(fèi)的。（破解版，等賺錢了再考慮回饋）
2、由于iOS平臺(tái)的一些限制，Unity很難做動(dòng)態(tài)代碼更新。而cocos2d-x有l(wèi)ua這個(gè)比較成熟的方案。（如果程序穩(wěn)定了，需要頻繁更新代碼的機(jī)會(huì)不多，更多的是更新配置和資源）
3、可能有些人不熟悉Unity，從而選擇了開源的cocos2d-x。適應(yīng)Unity的框架、工作方式需要一定的時(shí)間。（相信我，不會(huì)很長(zhǎng)，要知道一個(gè)8歲的孩子都能拿Unity來(lái)做游戲，并且上架，如果有程序員說(shuō)搞不定Unity，那干脆轉(zhuǎn)行賣燒餅吧）
4、對(duì)應(yīng)上面的第6點(diǎn)，由于Unity中資源對(duì)應(yīng)的配置有很大的重要性，所以一個(gè)Unity功能就是資源+代碼的整合，你很難分出一個(gè)資源包。這樣你的Unity項(xiàng)目可能很大。（使用AssetsBundle打包后可能避免這個(gè)問題，但是項(xiàng)目初期資源變動(dòng)大，經(jīng)常打包很不方便）
5、Unity很多設(shè)計(jì)都是為可視化編輯考慮的，舉個(gè)例子，2D的動(dòng)畫可以方便的拖幾張圖片就可以搞定。但是如果我每張圖片都有一定的偏移，那就麻煩了，需要自己重新實(shí)現(xiàn)幀動(dòng)畫功能，自己加載配置文件來(lái)實(shí)現(xiàn)。（這個(gè)嚴(yán)格說(shuō)來(lái)不是引擎的問題，畢竟引擎不是為了一家游戲公司設(shè)計(jì)的，大眾化的簡(jiǎn)易的操作方式是唯一需要考慮的。但是很多時(shí)候確實(shí)感覺有些不爽）
第五篇：Unity 3D的學(xué)習(xí)報(bào)告
Unity 3D的學(xué)習(xí)報(bào)告
劉卉
數(shù)媒0902班
0305090205 學(xué)習(xí)總結(jié)：
剛開始這門課程的時(shí)候，其實(shí)心里是比較恐懼的，因?yàn)閷?duì)Unity 3D這樣的軟件完全沒有認(rèn)知，對(duì)于這門課程的學(xué)習(xí)也處于比較茫然的狀態(tài)，可以說(shuō)是抱著嘗試的心情開始這門課程的學(xué)習(xí)的。開始使用軟件的時(shí)候，不知道從何下手，于是試著對(duì)照書本操作，漸漸地，我發(fā)現(xiàn)其實(shí)并沒有我想象中那么困難，一般的操作還是能夠在書本上學(xué)到的，可能最終完全掌握會(huì)有難度，但是對(duì)于目前的要求，還是比較易于實(shí)現(xiàn)的。在學(xué)習(xí)并實(shí)踐的過(guò)程中，可能在腳本游戲的代碼編寫上還是出現(xiàn)最多問題的，有的時(shí)候就是照搬書本上的代碼，也會(huì)出錯(cuò)，不僅僅是粗心，也是我對(duì)于代碼并不熟悉導(dǎo)致的，在一遍遍的修改中，我對(duì)代碼的編寫也更加熟練，相比較之前的生疏，現(xiàn)在算是比較得心應(yīng)手了。此外，比較困擾我的就是攝像機(jī)位置的各方面調(diào)整，有的時(shí)候很難調(diào)整到想要的角度，最后只能將就，這點(diǎn)讓我很是糾結(jié)。對(duì)于這種情況，我試著各種方法達(dá)到理想效果，如果說(shuō)我改變不了攝像機(jī)，那我只能改變我設(shè)置的場(chǎng)景、對(duì)象的位置了，雖然這樣的方法比較笨，而且可能會(huì)比較繁瑣，但是最終也幫助我實(shí)現(xiàn)了想要達(dá)到的效果。
也許是為了完成這門課的要求，也許是為了交作業(yè)，我最終還是自己嘗試著學(xué)習(xí)了Unity 3D的操作，可能我所做所學(xué)的都是基礎(chǔ)的知識(shí)，相對(duì)簡(jiǎn)單的，但是我還是學(xué)到了很多，不能說(shuō)了解但也是熟悉了這個(gè)軟件?？赡芪易龅臇|西不是很理想的，希望我能在日后的學(xué)習(xí)實(shí)踐中一點(diǎn)一點(diǎn)的去完善。
學(xué)習(xí)日志：
2012年9月20日
今天在電腦上安裝了Unity3D軟件，安裝的過(guò)程有點(diǎn)糾結(jié)，但最后還是安裝完成了。翻閱《Unity3D游戲開發(fā)》這本書，了解了第一章基礎(chǔ)知識(shí)的內(nèi)容。
2012年9月21日
打開Unity3D軟件，跟著書本試著操作。看書上第二章的內(nèi)容，一步步學(xué)習(xí)：創(chuàng)建工程——?jiǎng)?chuàng)建材質(zhì)——?jiǎng)?chuàng)建游戲?qū)ο蟆x予材質(zhì)——調(diào)節(jié)攝像機(jī)位置，初步創(chuàng)建了“正方體”對(duì)象。
2012年9月24日
又到了周一，繼續(xù)學(xué)習(xí)操作啦。今天學(xué)習(xí)“移動(dòng)試圖”，通過(guò)創(chuàng)建游戲腳本，做了平移、旋轉(zhuǎn)和縮放的調(diào)整，并且編寫代碼，使對(duì)象動(dòng)起來(lái)。使用21號(hào)做的正方體，最終實(shí)現(xiàn)了移動(dòng)和旋轉(zhuǎn)的效果。
2012年9月27日
今天我照著書中第二章第7小節(jié)的內(nèi)容，完成第一個(gè)游戲?qū)嵗?。雖然最終完成了，但實(shí)現(xiàn)的過(guò)程并不順利，光攝像機(jī)位置的調(diào)節(jié)就花了很長(zhǎng)時(shí)間，然后每個(gè)對(duì)象位置的調(diào)整、材質(zhì)的顏色還算順利，最后就是創(chuàng)建腳本游戲的時(shí)候，按照書上的編寫代碼，卻總是出錯(cuò)，最后發(fā)現(xiàn)原來(lái)是這些原因：代碼位置寫錯(cuò)、部分首字母小寫卻被我寫成了大寫、空格多加了。
2012年10月9日
放假歸來(lái)以后，開始書本第三章以后內(nèi)容的學(xué)習(xí)。我按照書本的內(nèi)容先將第三章的每一小節(jié)瀏覽了一遍，了解了大概的內(nèi)容。試著對(duì)照書本完成了一個(gè)GUI控件的腳本實(shí)例，其中包括各個(gè)控件的設(shè)置，代碼的編寫，中間也出現(xiàn)很多錯(cuò)誤，最終在同學(xué)的幫助下，終于運(yùn)行成功。
2012年10月10日
今天繼續(xù)第三章的內(nèi)容，學(xué)習(xí)了游戲界面的布局和貼圖的繪制。試著完成“人物移動(dòng)”的實(shí)例，各種問題逐漸顯露出來(lái)：代碼出錯(cuò)、攝像機(jī)位置擺不好、人物移動(dòng)方式不如我愿，總之是在挫敗中結(jié)束了學(xué)習(xí)。
2012年10月12日
今天又把上次沒完成的“人物移動(dòng)”拿出來(lái)繼續(xù)修改。我回顧了書本第三章的內(nèi)容，重新創(chuàng)建工程，試著完成各項(xiàng)操作。首先我先再次學(xué)習(xí)了添加與關(guān)閉窗口，又開始了貼圖的學(xué)習(xí)和繪制動(dòng)畫。將貼圖以材質(zhì)的形式繪制在游戲?qū)ο笾?，且在Project視圖中需要加載的圖片存儲(chǔ)在根目錄“Resources”中。而動(dòng)畫則是使用程序?qū)?dòng)畫資源存儲(chǔ)在動(dòng)畫數(shù)組中，然后設(shè)定動(dòng)畫的刷新時(shí)間，每次刷新動(dòng)畫時(shí)在原有的顯示區(qū)域繪制下一幀圖片，到了最后一幀則從第一幀重復(fù)開始，依此類推。相比較而已，這部分會(huì)比較有趣的。
2012年10月13日
終于，今天我實(shí)現(xiàn)了“人物移動(dòng)”這個(gè)實(shí)例?？赡苁侵疤募保懊娌糠种R(shí)還沒學(xué)習(xí)，就直接做實(shí)例，通過(guò)昨天的學(xué)習(xí)，再加上今天的努力，前天的難題都不再是難題，很快，我就做好了。
2012年10月18日
偷懶了很多天，今天我開始第四章的學(xué)習(xí)。這次我沒有急著做案例，我認(rèn)真的研究了書本。
2012年10月22日
學(xué)習(xí)了第五章的理論知識(shí)。知道了地形的參數(shù)包括地形的寬度、高度、長(zhǎng)度、分辨率和高度圖等?？傊?，今天學(xué)習(xí)了創(chuàng)建地形，地形參數(shù)，編輯地形和地形貼圖的內(nèi)容。
2012年10月23日
學(xué)習(xí)了書中實(shí)例“攝像機(jī)切換鏡頭”。
2012年10月29日
今天學(xué)習(xí)了第7章的輸入與控制的鍵盤事件。通過(guò)鍵盤的按下事件、抬起事件、任意鍵事件和組合鍵事件等實(shí)現(xiàn)交互這樣的功能。這部分的內(nèi)容可能實(shí)踐更重要，今天先進(jìn)行理論知識(shí)的學(xué)習(xí)，明天試著操作一下。除此之外，還學(xué)習(xí)了鼠標(biāo)事件、自定義按鍵事件、模型與動(dòng)畫和GL圖像庫(kù)的一部分內(nèi)容。鼠標(biāo)事件就是鼠標(biāo)按下事件、抬起事件、長(zhǎng)按事件。自定義按鍵是在輸入管理器中配置，自定義按鍵可以設(shè)置軸向，按鍵軸的數(shù)值默認(rèn)為0。另外，我嘗試模型的載入、設(shè)置3D動(dòng)畫和播放動(dòng)畫等內(nèi)容，可以說(shuō)忙的不亦樂乎。
2012年10月30日
將昨天所學(xué)操作了一下。
2012年11月02日
試著做“運(yùn)動(dòng)員踢足球”小游戲，包括場(chǎng)景的構(gòu)建、人物的構(gòu)建和移動(dòng)、球的移動(dòng)等等。首先我參考書中第五章內(nèi)容創(chuàng)建地形，添加地形元素，添加天空，導(dǎo)入了3D人物模型，以及創(chuàng)建了一個(gè)球形對(duì)象。將人物運(yùn)動(dòng)控制腳本綁定人物模型，球體運(yùn)動(dòng)腳本綁定球。
2012年11月05日
今天將書上8、9、10章沒有閱讀過(guò)的部分看了一遍，了解了一些操作的大概原理，試著學(xué)習(xí)書上的案例操作部分內(nèi)容，完善所學(xué)知識(shí)。
點(diǎn)擊咨詢 