【厚積薄發(fā)】VG技術(shù)下，美術(shù)在資源制作時的規(guī)范

這是第441篇UWA技術(shù)知識分享的推送，精選了UWA社區(qū)的熱門話題，涵蓋了UWA問答、社區(qū)帖子等技術(shù)知識點，助力大家更全面地掌握和學(xué)習(xí)。

UWA社區(qū)主頁：community.uwa4d.com

本期 精選了 UWA DAY 2025 部分議題的相關(guān)問答分享給大家。更多關(guān)于大會議題的提問可轉(zhuǎn)至UWA問答繼續(xù)交流。

https://answer.uwa4d.com/question/686b88da3d306f3e9d594f0b

大世界場景工業(yè)化：

程序化生成x模塊化資產(chǎn)x渲染優(yōu)化工作流

Q：VG技術(shù)下，美術(shù)在資源制作時，對于場景、機甲等模型面片數(shù)的控制會是什么樣的規(guī)范呢？有多大的自由度？

A： 在接入VG后，我們的美術(shù)資源面數(shù)規(guī)范給了150%的上調(diào)空間，項目中的Shader復(fù)雜度過高，如果使用簡單Shader，面數(shù)的上調(diào)空間應(yīng)該有200%。 實際應(yīng)用上美術(shù)資源并沒有做太多的突破，相對比較保守，對于一些較高面數(shù)的模型，比如大型山體、機甲的容忍度變得更高；對于面數(shù)較高的機甲、人形角色還是有一定的控制。

目前場景大型模型的三角形面數(shù)標(biāo)準(zhǔn)為15000，中型模型按類別3000或5000，大型山石標(biāo)準(zhǔn)為30000，中型崖壁標(biāo)準(zhǔn)10000，樹6000，灌木3000。 機甲由多個部件組成，一整套機甲+武裝的標(biāo)準(zhǔn)是不超過20萬。 人形角色的臉部12000，身體60000，頭發(fā)20000。

感謝何文雅老師提供了回答

大世界場景工業(yè)化：程序化生成x模塊化資產(chǎn)x渲染優(yōu)化工作流

》課程鏈接直達(dá)：

https://edu.uwa4d.com/course-intro/1/634

UE-DS的長跑挑戰(zhàn) -

長生命周期大世界的性能治理探索之路

Q1：FindFloor函數(shù)放到多線程里，是不是一個線程用于模擬有阻擋的情況下角色移動后的最終位置？一個線程直接使用無阻擋情況的位移？如果遇到真的無阻擋，F(xiàn)indFloor在其他線程的結(jié)果就是一致，如果不一致，即使用抬高，位移下落的FindFloor結(jié)果? 不知這樣理解對不對？

A：這里直接在TickComp里使用當(dāng)前速度預(yù)測前方抬高后終點，然后創(chuàng)建Tick任務(wù)分發(fā)給AnyThread運行然后回調(diào)回來之后再讓MoveComp在同一個TickGroup里執(zhí)行真正的移動即可。移動抬高那步只是處理斜坡或者可跨越地板的操作，水平速度是不變的，所以即使被抬高向前水平向終點是確定的。只有一種情況對終點預(yù)測失敗就是完全被擋住抬了可跨越高度也無法向前，被停在位移中途，因為AI會用Nav尋路所以概率不高。如果要更精準(zhǔn)可以直接在異步任務(wù)里抬高做一次Sweep檢測看看停在那里確定精確位置。

Q2：GameThread里的MovementTick會開啟兩個（或者多個）Findfloor，findfloor是否可以理解成檢索最近的可著落點？如果是我理解的“TickComp里使用當(dāng)前速度預(yù)測前方抬高后終點”，那么tickcomp里已經(jīng)有findfloor了，為啥還有多線程去find?

A：直接用速度算水平坐標(biāo)地面在什么位置，但是FindFloor里是物理查詢，需要查那個位置的平面和法線和具體的Z軸坐標(biāo)的。是把FindFloor從引擎提前，把物理查詢多線程化。

感謝趙珂老師提供了回答

《UE-DS的長跑挑戰(zhàn) - 長生命周期大世界的性能治理探索之路》

課程鏈接直達(dá)：

https://edu.uwa4d.com/course-intro/1/636

《歸環(huán)》項目研發(fā)效率提升之路

Q：項目開發(fā)過程中，哪些點會因為PC和移動端過大的差異而需要設(shè)計不同的流程、框架或者方案？哪些是值得在項目初期就需要提前考慮好的？

A：核心原則：能夠統(tǒng)一設(shè)計的盡量統(tǒng)一設(shè)計，這樣便于資源的生產(chǎn)和代碼的維護(hù)。 可能存在差異的點：

1. 因為品質(zhì)需求不同而需要單獨制作的美術(shù)資源，比如場景物件可能會有不同的lod層級，不同的層級可能會在不同平臺使用；

2. 渲染管線，PC和移動平臺的渲染管線不同，需要定制優(yōu)化；

3. 貼圖壓縮格式，這個即便是移動平臺i OS和安卓本身都不同；

4. 資產(chǎn)性能規(guī)范；

5. input差異，PC是鍵鼠、移動端是觸屏，主機平臺是手柄，這里要做好抽象和設(shè)計；

6. 各種后處理效果。 其他可能還有一些瑣碎的細(xì)節(jié)。

在這些所有區(qū)別中，首先要確定的是效果以移動端為主還是PC為主，然后制定對應(yīng)的資產(chǎn)規(guī)范，移動端為主就可能會犧牲一些PC效果，PC為主會需要犧牲一些移動端下沉適配機型。然后基于目標(biāo)制定美術(shù)制作規(guī)范和引擎渲染的管線以及各種Feature，很多Feature在PC上和移動端要做不同的適配，實現(xiàn)方案可能都有不同。然后輸入最好做好設(shè)計，技術(shù)做好抽象，交互同學(xué)做好統(tǒng)一的規(guī)范。

前期注意的主要是這些吧，其他的影響反而是小的，遇到了自然就知道怎么處理，修改成本也不算高。

感謝賈偉昊老師提供了回答

《歸環(huán)》項目研發(fā)效率提升之路

課程鏈接直達(dá)：

https://edu.uwa4d.com/course-intro/1/635

Unity引擎資源管理經(jīng)驗 -

如何使用YooAsset進(jìn)行高效的資源管理

Q：把AB打包策略自動化是否可行，比如配置一些基本的限制之后，由算法來決定打包粒度，劃分資源到不同的AB里。其中的難點可能會有哪些？

A：課程里有講到導(dǎo)致構(gòu)建文件發(fā)生變化的8條因素，這里面有一條因素需要注意下，就是AB文件里記錄了其依賴的Bundle名稱列表，哪怕是依賴關(guān)系沒變，但是依賴的bunlde名稱發(fā)生變化也會導(dǎo)致文件MD5發(fā)生變化。 另外自動化打包策略的穩(wěn)定性也是關(guān)鍵，這需要大量的項目實踐，然后不斷調(diào)整算法直到穩(wěn)定。

感謝何冠峰老師提供了回答

《Unity引擎資源管理經(jīng)驗 - 如何使用YooAsset進(jìn)行高效的資源管理》

課程鏈接直達(dá)：

https://edu.uwa4d.com/course-intro/1/622

虛幻引擎5構(gòu)建開放世界下的

優(yōu)化、挑戰(zhàn)以及開發(fā)方向

Q：請問虛幻引擎下一個開放世界項目主要會關(guān)注哪些方向？

針對以上問題，有經(jīng)驗的朋友歡迎轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/686b88da3d306f3e9d594f0b

虛幻引擎5構(gòu)建開放世界下的優(yōu)化、挑戰(zhàn)以及開發(fā)方向

課程鏈接直達(dá)：

https://edu.uwa4d.com/course-intro/1/638

封面圖來源于網(wǎng)絡(luò)

今天的分享就到這里。生有涯而知無涯，在漫漫的開發(fā)周期中，我們遇到的問題只是冰山一角，UWA社區(qū)愿伴你同行，一起探索分享。歡迎更多的開發(fā)者加入UWA社區(qū)。

UWA官網(wǎng)：www.uwa4d.com

UWA社區(qū)：community.uwa4d.com

UWA學(xué)堂：edu.uwa4d.com

點擊下方名片關(guān)注我們，將我設(shè)為星標(biāo)，及時接收小編每日推送哦，性能優(yōu)化不迷路～

近期精彩回顧

【厚積薄發(fā)】

【厚積薄發(fā)】

【萬象更新】

【萬象更新】