[請益] 關於Unity放進美術素材

看板GameDesign作者 (黃豆)時間7年前 (2016/12/15 11:01), 7年前編輯推噓15(15推 0噓 42→)
留言57則, 14人參與, 最新討論串1/3 (看更多)
由於我們家的RD說給他的美術素材全部都要是2的次方尺寸 想請問這樣是正常的嗎？ 就是128x128 256x256 512x512 1024x1024這種的以此類推 覺得很奇怪，所以上來請益一下 就算不管甚麼東西，舉凡角色立繪、頭像、背景等東西 背景就是720*1280這種尺寸了，也要生給他2的次方尺寸 美術素材本來就會有尺寸大小不可能全是2次方的尺寸的情況 可是程式說不這樣做的話他編譯出來美術素材會變得超級大 甚麼NGUI的也不打算去買，說甚麼怕NGUI一更新就掛掉所以不打算靠外掛 全部靠著UNITY內建硬上，用texurepacker打包給他也不要 一個說甚麼放進去還要自己旋轉對位很麻煩 一個說還要額外裝東西的方法不是好方法 TP都打包給你們了應該頂多給對位圖就好了吧= = ............ 所以只好想請問有作遊戲的同行一下，你們放背景還是角色立繪那種的 都是怎麼做的呢？ 真的也會這樣子做嗎？ 謝謝 角色沒有很大隻，可是卻都應要把角色的尺寸寬高邊界都拉到2次方.... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.250.154.157 ※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1481770860.A.132.html
推
12/15 11:03, , 1F
會比較方便 但引擎都有內建功能才對 directx也沒這問題
12/15 11:03, 1F
→
12/15 11:05, , 2F
蠻莫名奇妙的 有需要大量轉的話寫程式自己轉
12/15 11:05, 2F
我也是不太懂@@一般來說是用TP打包給RD比較方便吧？ 就算是單張單張給，RD應該也是要一個個拉進場景去對位置吧我想？
推
12/15 12:08, , 3F
TexturePacker 完全可以切好直接變成單張單張的 Uni
12/15 12:08, 3F
→
12/15 12:08, , 4F
ty Sprite，是不想學吧XD
12/15 12:08, 4F
請問這是一次放一張就切出來嗎？@@那很多張不就很多工不就很累?XD
推
12/15 12:18, , 5F
而且拼圖才有意義，你一張圖餵進記憶體的確是分配2
12/15 12:18, 5F
→
12/15 12:18, , 6F
的次方的空間，例如128휱29的圖，就是會佔用128휲56
12/15 12:18, 6F
推
12/15 12:19, , 7F
推文被吃掉了，晚點再補，不過先說你們工程師的觀
12/15 12:19, 7F
→
12/15 12:19, , 8F
念有問題，完全誤解了記憶體配置的運作
12/15 12:19, 8F
我也是覺得UI類應該是比較適用TP@@
推
12/15 13:34, , 9F
不買nGUI是沒什麼問題，沒特殊需求的話uGUI很夠用了
12/15 13:34, 9F
→
12/15 13:37, , 10F
但我記得Unity會自動把Sprite包成Atlas
12/15 13:37, 10F
RD也不熟UNITY 兩位都不是CLIENT端的@@ 上次我給的3D的球還拉錯 說我沒弄好，我為了讓對方看到一樣的東西我還特地用匯出的 結果對方看到的還是跟在我電腦上的不一樣，後來才知道對方是拉錯東西的樣子
推
12/15 13:40, , 11F
除非你的圖本來就是做成圖集的形式，否則不用特地遵守2
12/15 13:40, 11F
→
12/15 13:41, , 12F
power的格式 前提是你家工程師是在用uGUI
12/15 13:41, 12F
→
12/15 13:41, , 13F
如果是用onGUI的神人的話我就不知道了 XD
12/15 13:41, 13F
RD說打包給AN吃是還好，打包給iOS吃就強迫要2次方甚麼的@@
推
12/15 13:51, , 14F
uGUI不需要power of 2
12/15 13:51, 14F
所以可能是他UNITY內所有的UI素材都沒設定好成為UI類型嗎？@@
推
12/15 17:12, , 15F
立繪頭像背景 建議是用繪圖軟體批次處理成power of 2
12/15 17:12, 15F
→
12/15 17:13, , 16F
有些東西不適合打包成atlas 又需要PVRTC壓縮 又不想被
12/15 17:13, 16F
→
12/15 17:14, , 17F
和unity sprite奮戰長寬比的時侯...
12/15 17:14, 17F
推
12/15 17:16, , 18F
你提的解法 NGUI->建議不要用 TexturePacker->不適合用
12/15 17:16, 18F
→
12/15 17:16, , 19F
在立繪和背景上
12/15 17:16, 19F
→
12/15 17:17, , 20F
用Unity importer直接rescale成pot -> sprite長寬比要手
12/15 17:17, 20F
→
12/15 17:17, , 21F
動重調
12/15 17:17, 21F
→
12/15 17:18, , 22F
在流程上最簡單的方法→用繪圖軟體批次處理成pot
12/15 17:18, 22F
請問這邊Unity importer是甚麼意思呢？ POT是甚麼意思呢？@@ 如果可以的話 希望能請益step by step的步驟或是教學 對不起@@不好意思這塊不是很懂 很希望知道大家是如何處理這些非2次方的素材@@
→
12/15 17:27, , 23F
我當初都跟美術講說小一點 然後先放進手機看XD
12/15 17:27, 23F
→
12/15 22:02, , 24F
應該是為了方便壓縮吧，內建pot長寬比會爆炸
12/15 22:02, 24F
→
12/16 00:51, , 25F
為了效能，npot無法最佳化
12/16 00:51, 25F
→
12/16 00:54, , 26F
感覺沒錯啊，除非是屬於Sprite packer，不然pot方便壓
12/16 00:54, 26F
→
12/16 00:54, , 27F
縮
12/16 00:54, 27F
請問我打開了Sprite packer可是裡面卻空空如也，是不是只支援PRO版本呢？ ※ 編輯: Lincm (60.250.154.157), 12/16/2016 11:00:51
推
12/16 12:04, , 28F
POT = Power Of Two
12/16 12:04, 28F
推
12/16 12:27, , 29F
昨天忘了補了，總之舉例 128*129 的圖，在記憶體裡
12/16 12:27, 29F
→
12/16 12:28, , 30F
就要配置 128*256 的空間，但明明就只多了 1px，卻
12/16 12:28, 30F
→
12/16 12:28, , 31F
要多出將近一倍的無用空間
12/16 12:28, 31F
→
12/16 12:29, , 32F
新開案子用UGUI比較好，NGUI會慢慢被淘汰
12/16 12:29, 32F
→
12/16 12:29, , 33F
這對於記憶體配置來說是極大的浪費，但你硬要把圖
12/16 12:29, 33F
→
12/16 12:29, , 34F
留空到 128*256，意義在哪？拼圖的好處就是夠跟記憶
12/16 12:29, 34F
→
12/16 12:30, , 35F
體要最小的空間，可以塞進最多的圖
12/16 12:30, 35F
→
12/16 12:30, , 36F
所以像剛剛上面的例子，浪費的空間就可以靠著填補
12/16 12:30, 36F
→
12/16 12:30, , 37F
其他小圖把他補起來
12/16 12:30, 37F
推
12/16 12:32, , 38F
舉例，如果你今天有兩張圖，一張是 128*129，一張是
12/16 12:32, 38F
→
12/16 12:33, , 39F
65*65，如果不拼圖，在記憶體裡面就會耗掉128*256 +
12/16 12:33, 39F
→
12/16 12:33, , 40F
128*128
12/16 12:33, 40F
→
12/16 12:33, , 41F
但如果拼圖，因為 65*65 可以塞到 128*129 被配置到
12/16 12:33, 41F
→
12/16 12:34, , 42F
的128*256記憶體空間剩下的空白處，所以把兩張圖拚
12/16 12:34, 42F
→
12/16 12:34, , 43F
成128*256的圖給遊戲使用，這樣就只會佔128*256的空
12/16 12:34, 43F
→
12/16 12:35, , 44F
間。2的倍數是這樣運作，你留空卻不作為完全沒意義
12/16 12:35, 44F
感謝解說，那這樣看來其實最好的方式我想應該還是用TP將UI圖打包給對方 請對方拉到場景上吧？ 這樣應該就算怪尺寸的話 用TP拚個1024*1024的 讓他去使用應該也是可以的？
→
12/16 19:51, , 45F
我建議你們多磨合、抱著謙虛的心一起探討問題點。
12/16 19:51, 45F
→
12/16 19:52, , 46F
最好兩個人就坐隔壁，很快會了解unity是友情殺手
12/16 19:52, 46F
→
12/16 19:54, , 47F
簡單事情變動能配合就配合，圖改個大小對你來說很快
12/16 19:54, 47F
→
12/16 19:54, , 48F
但如果他不太熟悉，你不配合他改，可能花他更多時間修正
12/16 19:54, 48F
→
12/16 19:55, , 49F
反正資源過大軟體跑不動，問題是他扛，他遲早要學更多。
12/16 19:55, 49F
→
12/16 19:56, , 50F
類似的事情還很多很多，例如法線方向，模型中心各種搞
12/16 19:56, 50F
→
12/16 19:56, , 51F
反之，如果某個變動你要花很多時間，換你要求他盡量配合
12/16 19:56, 51F
嗯嗯，因為同事不是寫client的...所以也正在學習 只是有些按鈕是114*118 他要我出成128*128給他 我想說應該正確的方式是給他拚好的大圖才對吧@@
推
12/17 01:28, , 52F
就算是DirectX也有這問題吧 記得天瓏書店裡面有一本原
12/17 01:28, 52F
→
12/17 01:29, , 53F
文書也是這樣寫 主要是放大縮小處理後細節可不可以完美
12/17 01:29, 53F
→
12/17 01:29, , 54F
呈現的問題吧...
12/17 01:29, 54F
推
12/17 02:52, , 55F
power-of-two 主要是可壓縮，放大縮小是看 mipmap
12/17 02:52, 55F
推
12/20 01:54, , 56F
早期支援 NPOT 的硬體剛出來的時候，速度會比 POT 慢一些
12/20 01:54, 56F
→
12/20 01:55, , 57F
不知道這塊是不是真的由硬體做還是 driver 自己處理掉
12/20 01:55, 57F
程式我就真的不熟了，我想應該也是每個人寫法不一樣....... ※ 編輯: Lincm (60.250.154.157), 12/20/2016 12:02:44
‣ 更多 Lincm 的文章
文章代碼(AID): #1OKWTi4o (GameDesign)
‣ 更多 Lincm 的文章
文章代碼(AID): #1OKWTi4o (GameDesign)