由於我們家的RD說給他的美術素材全部都要是2的次方尺寸
想請問這樣是正常的嗎？
就是128x128 256x256 512x512 1024x1024這種的以此類推
覺得很奇怪，所以上來請益一下
就算不管甚麼東西，舉凡角色立繪、頭像、背景等東西
背景就是720*1280這種尺寸了，也要生給他2的次方尺寸
美術素材本來就會有尺寸大小不可能全是2次方的尺寸的情況
可是程式說不這樣做的話他編譯出來美術素材會變得超級大
甚麼NGUI的也不打算去買，說甚麼怕NGUI一更新就掛掉所以不打算靠外掛
全部靠著UNITY內建硬上，用texurepacker打包給他也不要
一個說甚麼放進去還要自己旋轉對位很麻煩
一個說還要額外裝東西的方法不是好方法
TP都打包給你們了應該頂多給對位圖就好了吧= = ............
所以只好想請問有作遊戲的同行一下，你們放背景還是角色立繪那種的
都是怎麼做的呢？
真的也會這樣子做嗎？
謝謝
角色沒有很大隻，可是卻都應要把角色的尺寸寬高邊界都拉到2次方....

感覺沒錯啊，除非是屬於Sprite packer，不然pot方便壓縮

為了效能，npot無法最佳化

應該是為了方便壓縮吧，內建pot長寬比會爆炸

我當初都跟美術講說小一點 然後先放進手機看XD

uGUI不需要power of 2

立繪頭像背景 建議是用繪圖軟體批次處理成power of 2有些東西不適合打包成atlas 又需要PVRTC壓縮 又不想被和unity sprite奮戰長寬比的時侯...你提的解法 NGUI->建議不要用 TexturePacker->不適合用在立繪和背景上用Unity importer直接rescale成pot -> sprite長寬比要手動重調在流程上最簡單的方法→用繪圖軟體批次處理成pot

不買nGUI是沒什麼問題，沒特殊需求的話uGUI很夠用了但我記得Unity會自動把Sprite包成Atlas除非你的圖本來就是做成圖集的形式，否則不用特地遵守2power的格式 前提是你家工程師是在用uGUI如果是用onGUI的神人的話我就不知道了 XD

TexturePacker 完全可以切好直接變成單張單張的 Unity Sprite，是不想學吧XD而且拼圖才有意義，你一張圖餵進記憶體的確是分配2的次方的空間，例如128휱29的圖，就是會佔用128휲56推文被吃掉了，晚點再補，不過先說你們工程師的觀念有問題，完全誤解了記憶體配置的運作

會比較方便 但引擎都有內建功能才對 directx也沒這問題蠻莫名奇妙的 有需要大量轉的話寫程式自己轉

POT = Power Of Two

昨天忘了補了，總之舉例 128*129 的圖，在記憶體裡就要配置 128*256 的空間，但明明就只多了 1px，卻要多出將近一倍的無用空間

新開案子用UGUI比較好，NGUI會慢慢被淘汰

這對於記憶體配置來說是極大的浪費，但你硬要把圖留空到 128*256，意義在哪？拼圖的好處就是夠跟記憶體要最小的空間，可以塞進最多的圖所以像剛剛上面的例子，浪費的空間就可以靠著填補其他小圖把他補起來舉例，如果你今天有兩張圖，一張是 128*129，一張是65*65，如果不拼圖，在記憶體裡面就會耗掉128*256 +128*128但如果拼圖，因為 65*65 可以塞到 128*129 被配置到的128*256記憶體空間剩下的空白處，所以把兩張圖拚成128*256的圖給遊戲使用，這樣就只會佔128*256的空間。2的倍數是這樣運作，你留空卻不作為完全沒意義

我建議你們多磨合、抱著謙虛的心一起探討問題點。最好兩個人就坐隔壁，很快會了解unity是友情殺手簡單事情變動能配合就配合，圖改個大小對你來說很快但如果他不太熟悉，你不配合他改，可能花他更多時間修正反正資源過大軟體跑不動，問題是他扛，他遲早要學更多。類似的事情還很多很多，例如法線方向，模型中心各種搞反之，如果某個變動你要花很多時間，換你要求他盡量配合

就算是DirectX也有這問題吧 記得天瓏書店裡面有一本原文書也是這樣寫 主要是放大縮小處理後細節可不可以完美呈現的問題吧...

power-of-two 主要是可壓縮，放大縮小是看 mipmap

早期支援 NPOT 的硬體剛出來的時候，速度會比 POT 慢一些不知道這塊是不是真的由硬體做還是 driver 自己處理掉