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