把同一套 AI 生成建筑復(fù)制到 Unity 或 Unreal 后有時(shí)第一棟光照正常第二棟卻像貼上了別處的陰影靜態(tài)墻面沒(méi)有問(wèn)題可移動(dòng)門(mén)窗一進(jìn)陰影就發(fā)黑場(chǎng)景首次加載正常重新進(jìn)入分區(qū)后又出現(xiàn)亮度錯(cuò)位。遇到這些現(xiàn)象先不要反復(fù)改材質(zhì)或提高 Lightmap 分辨率。更有效的做法是按“實(shí)例映射—UV2 與尺度—優(yōu)化重組—?jiǎng)討B(tài)物體采樣—分區(qū)重載”逐層排查。同一套建筑復(fù)制四次為什么只有一棟正常先做一次最簡(jiǎn)單的對(duì)照換成不依賴(lài)貼圖細(xì)節(jié)的中性材質(zhì)并固定相機(jī)、燈光和曝光。如果錯(cuò)誤陰影仍在優(yōu)先檢查 Lightmap 索引、圖集頁(yè)和偏移數(shù)據(jù)。如果只有可移動(dòng)的門(mén)、招牌或升降平臺(tái)發(fā)黑重點(diǎn)檢查光照探針、體積光照和采樣錨點(diǎn)。如果未優(yōu)化時(shí)正常開(kāi)啟靜態(tài)合批、GPU 實(shí)例化、HLOD 或流式加載后才異常就要追蹤對(duì)象重組和資源綁定時(shí)序。本文使用一個(gè)固定案例同一棟模塊化建筑復(fù)制為 4 個(gè)實(shí)例。building_01、building_02參與靜態(tài)光照烘焙building_03進(jìn)入實(shí)例化渲染路徑building_04帶有可移動(dòng)門(mén)窗并由遠(yuǎn)處分區(qū)加載。網(wǎng)格和材質(zhì)相同只能說(shuō)明它們可以復(fù)用一部分資產(chǎn)數(shù)據(jù)不代表 4 個(gè)場(chǎng)景實(shí)例應(yīng)讀取同一塊烘焙結(jié)果。Draw Call 降低也只是性能指標(biāo)不能證明光照映射仍然正確。圖注模塊復(fù)用可以提高場(chǎng)景搭建效率但每個(gè)實(shí)例的烘焙映射、圖集占用和動(dòng)態(tài)光照采樣仍需在真實(shí)引擎工程中核對(duì)。第一處共享網(wǎng)格不等于共享烘焙結(jié)果典型現(xiàn)象4 棟建筑共用一份 Mesh 和材質(zhì)烘焙后卻像把陰影復(fù)制粘貼到了不同樓體上。更明顯的情況是門(mén)洞陰影出現(xiàn)在沒(méi)有門(mén)的一側(cè)或者建筑旋轉(zhuǎn)后仍保留原方向的遮擋關(guān)系。為什么會(huì)這樣Mesh 保存的是模型幾何Lightmap 保存的是靜態(tài)光照結(jié)果。Lightmap 通常根據(jù)對(duì)象在烘焙時(shí)的位置、朝向和周?chē)趽跎?。網(wǎng)格可以共享但每個(gè)實(shí)例仍要讀取屬于自己的圖集區(qū)域和烘焙數(shù)據(jù)。在 Unity 工作流中常見(jiàn)檢查項(xiàng)是lightmapIndex與lightmapScaleOffset。后者可以理解為“該實(shí)例在整張光照?qǐng)D集中的位置和大小”。在 Unreal 中字段和數(shù)據(jù)組織方式不同應(yīng)檢查對(duì)應(yīng)網(wǎng)格的 Lightmap UV 通道、分辨率、關(guān)卡靜態(tài)光照構(gòu)建數(shù)據(jù)及實(shí)例化組件配置不要機(jī)械尋找同名字段。怎么檢查建立一張最小對(duì)照表實(shí)例網(wǎng)格圖集/構(gòu)建數(shù)據(jù)索引或映射位置與朝向?qū)嶋H結(jié)果building_01mesh_Aatlas_01mapping_01原點(diǎn)、0°待驗(yàn)證building_02mesh_Aatlas_01mapping_02右側(cè)、90°待驗(yàn)證building_03mesh_A按實(shí)例化方案記錄獨(dú)立核對(duì)后排、0°待驗(yàn)證building_04mesh_A分區(qū)加載數(shù)據(jù)獨(dú)立核對(duì)遠(yuǎn)處分區(qū)待驗(yàn)證逐棟隱藏其他實(shí)例只保留當(dāng)前建筑和調(diào)試顯示確認(rèn)它實(shí)際讀取的圖集區(qū)域。隨后重新打開(kāi)場(chǎng)景、重新構(gòu)建并再次加載分區(qū)檢查映射是否仍然指向正確實(shí)例。通過(guò)標(biāo)準(zhǔn)不是“重新烘焙一次后暫時(shí)正?！倍?4 棟建筑在多次加載后陰影仍分別符合自己的位置、朝向和遮擋關(guān)系。第二處UV2沒(méi)有重疊實(shí)例尺度仍可能不一致典型現(xiàn)象模塊保持原尺寸時(shí)正常放大后墻角開(kāi)始發(fā)黑使用非均勻縮放后接縫一側(cè)清晰、一側(cè)模糊相鄰樓體的陰影銳度也明顯不同。為什么會(huì)這樣UV2 通常用于存放烘焙光照坐標(biāo)。它沒(méi)有重疊只能證明單個(gè)網(wǎng)格內(nèi)部的光照 UV 沒(méi)有互相覆蓋不能保證不同實(shí)例獲得了相同的世界空間采樣精度。對(duì)象縮放、Lightmap 分辨率或 Scale、圖集打包結(jié)果都會(huì)影響每米世界空間能夠分到多少光照紋素。一個(gè)模塊被放大后如果烘焙占用沒(méi)有相應(yīng)調(diào)整原本足夠的圖集區(qū)域就可能變得過(guò)小。怎么檢查先復(fù)制一份測(cè)試場(chǎng)景再應(yīng)用對(duì)象縮放保持燈光、材質(zhì)和烘焙質(zhì)量不變。記錄 4 個(gè)實(shí)例的世界尺寸與縮放值Lightmap UV 通道Lightmap 分辨率或 Scale所在圖集頁(yè)每米光照紋素密度接縫兩側(cè)的實(shí)際清晰度。相同世界尺寸的模塊應(yīng)獲得接近的光照紋素密度。若項(xiàng)目確實(shí)需要多種尺寸應(yīng)為它們制定明確的烘焙檔位而不是給發(fā)黑實(shí)例單獨(dú)調(diào)亮材質(zhì)。材質(zhì)補(bǔ)償只能改變表面觀感不能修復(fù)圖集采樣不足。第三處?kù)o態(tài)合批、GPU實(shí)例化和HLOD改變了對(duì)象組織典型現(xiàn)象未優(yōu)化的場(chǎng)景光照正常啟用靜態(tài)合批后部分墻面讀取錯(cuò)誤陰影鏡頭拉遠(yuǎn)觸發(fā) HLOD 時(shí)整棟樓突然變亮關(guān)閉相應(yīng)優(yōu)化后問(wèn)題消失。先分清三種機(jī)制靜態(tài)合批可能重新組織靜態(tài)網(wǎng)格以減少提交開(kāi)銷(xiāo)。GPU 實(shí)例化強(qiáng)調(diào)用共享幾何和材質(zhì)數(shù)據(jù)繪制多個(gè)實(shí)例但每實(shí)例能夠攜帶什么數(shù)據(jù)取決于具體渲染路徑和著色器實(shí)現(xiàn)。HLOD會(huì)在遠(yuǎn)距離用簡(jiǎn)化后的代理資產(chǎn)替換一組原對(duì)象。三者解決的問(wèn)題不同也不會(huì)自動(dòng)保證子網(wǎng)格、材質(zhì)參數(shù)、Lightmap UV 和烘焙綁定完全不變。尤其不要默認(rèn) Unity 與 Unreal 對(duì)實(shí)例化靜態(tài)光照的支持方式相同應(yīng)分別按目標(biāo)引擎和渲染管線驗(yàn)證。怎么檢查依次生成四組對(duì)照版本不啟用上述優(yōu)化只啟用靜態(tài)合批只測(cè)試目標(biāo)實(shí)例化路徑只啟用 HLOD并緩慢跨越切換距離。每組記錄子網(wǎng)格數(shù)量、材質(zhì)槽、光照映射、批處理方式、HLOD 級(jí)別和首次異常位置。若某類(lèi)對(duì)象無(wú)法安全地同時(shí)參與靜態(tài)烘焙和實(shí)例化應(yīng)把靜態(tài)建筑、動(dòng)態(tài)附件與遠(yuǎn)景代理分開(kāi)管理而不是為了降低 Draw Call 強(qiáng)行塞進(jìn)同一條路徑。第四處可移動(dòng)門(mén)窗沒(méi)有采到合適的間接光典型現(xiàn)象墻體亮度穩(wěn)定可移動(dòng)門(mén)進(jìn)入室內(nèi)后突然變黑門(mén)框正常門(mén)板卻偏藍(lán)招牌轉(zhuǎn)過(guò)一個(gè)角度后亮度跳變像是換了一套材質(zhì)。為什么會(huì)這樣靜態(tài)墻面可以讀取烘焙 Lightmap可移動(dòng)物體則通常需要通過(guò)光照探針、體積光照或目標(biāo)引擎提供的動(dòng)態(tài)間接光方案取得環(huán)境照明。一個(gè)門(mén)可能由門(mén)框、門(mén)板、把手和玻璃等多個(gè) Renderer 或組件組成。如果它們使用不同的采樣位置或者默認(rèn)錨點(diǎn)落在墻后、地下或門(mén)洞外各部分就可能讀取到不同的環(huán)境光。Unity 中可重點(diǎn)檢查 Light Probe 與 Probe AnchorUnreal 中則應(yīng)查看 Volumetric Lightmap 等動(dòng)態(tài)物體間接光數(shù)據(jù)及對(duì)象的移動(dòng)性設(shè)置。兩者原理相近但配置入口不能混寫(xiě)。怎么檢查顯示場(chǎng)景中的探針或體積采樣分布讓門(mén)沿固定路線經(jīng)過(guò)室外、門(mén)洞和室內(nèi)。記錄亮度第一次跳變的位置并核對(duì)該區(qū)域是否存在有效采樣數(shù)據(jù)相鄰采樣點(diǎn)的亮度差是否過(guò)大門(mén)框、門(mén)板和裝飾件是否使用一致、合理的采樣參考組件的靜態(tài)或可移動(dòng)屬性是否設(shè)置正確。合格結(jié)果應(yīng)是移動(dòng)過(guò)程中的亮度變化連續(xù)同一部件的不同區(qū)域沒(méi)有無(wú)法解釋的色溫差。沒(méi)有采樣覆蓋時(shí)應(yīng)明確記錄為“未配置”或“待驗(yàn)證”不要提高自發(fā)光來(lái)掩蓋問(wèn)題。第五處分區(qū)重載后仍在引用舊光照數(shù)據(jù)典型現(xiàn)象第一次進(jìn)入城市時(shí)畫(huà)面正常。離開(kāi)并重新進(jìn)入同一分區(qū)后建筑突然變暗、陰影錯(cuò)位或者先全黑一段時(shí)間再恢復(fù)。為什么會(huì)這樣流式加載過(guò)程中網(wǎng)格、材質(zhì)、Lightmap、探針數(shù)據(jù)和場(chǎng)景實(shí)例不一定同時(shí)就緒。舊實(shí)例沒(méi)有注銷(xiāo)、新實(shí)例繼承舊映射或者渲染器先于光照數(shù)據(jù)開(kāi)啟都會(huì)造成短暫或持續(xù)的異常。“等待 0.5 秒再顯示”不是可靠修復(fù)。不同設(shè)備、質(zhì)量檔位和緩存狀態(tài)下資源加載時(shí)間并不相同。怎么檢查為每次加載記錄以下?tīng)顟B(tài)zone_id instance_id mesh_ready lightmap_ready probe_ready mapping_bound render_enabled建議按“建立實(shí)例—加載光照資源—綁定映射—確認(rèn)動(dòng)態(tài)采樣就緒—開(kāi)啟渲染”的順序驗(yàn)證。往返加載同一分區(qū)至少 3 次檢查舊實(shí)例、舊索引和監(jiān)聽(tīng)器數(shù)量是否持續(xù)增加。首次進(jìn)入、重復(fù)加載和正式構(gòu)建的結(jié)果應(yīng)保持一致。只有當(dāng)前實(shí)例所需的光照資源和映射都準(zhǔn)備完成才允許顯示對(duì)應(yīng) Renderer 或組件。用12秒最小場(chǎng)景定位問(wèn)題完整城市包含太多變量可以先把測(cè)試壓縮成 12 秒04 秒關(guān)閉批處理和 HLOD依次顯示 4 棟建筑的 Lightmap 圖集、索引或?qū)?yīng)構(gòu)建數(shù)據(jù)。48 秒只啟用目標(biāo)優(yōu)化方式緩慢移動(dòng)相機(jī)觀察批處理或 HLOD 切換前后的變化。812 秒讓可移動(dòng)門(mén)穿過(guò)門(mén)洞同時(shí)卸載并重新加載一個(gè)分區(qū)。每輪至少保存以下字段build_version engine_and_render_pipeline instance_id mesh_id lightmap_or_build_data scale_offset_or_instance_mapping probe_anchor_or_dynamic_light_sample batch_mode streaming_state final_result檢查結(jié)果統(tǒng)一標(biāo)記為“已通過(guò)、未通過(guò)、待驗(yàn)證”。不要只保存最終正常截圖還要保留第一次發(fā)生錯(cuò)誤時(shí)的實(shí)例編號(hào)、畫(huà)面和加載狀態(tài)。資產(chǎn)層能修改什么哪些問(wèn)題必須回到引擎驗(yàn)證如果問(wèn)題指向 UV2、對(duì)象縮放、子網(wǎng)格或材質(zhì)槽可以回到資產(chǎn)層整理。使用模型編輯處理局部結(jié)構(gòu)能夠減少后續(xù)導(dǎo)入和拆分成本。但資產(chǎn)編輯不能替代引擎中的 Lightmap 烘焙、實(shí)例映射、動(dòng)態(tài)光照采樣和流式加載測(cè)試。AI 生成 3D 模型可以加快建筑外觀與模塊草稿的準(zhǔn)備不會(huì)自動(dòng)保證最終工程中的 UV、材質(zhì)、靜態(tài)光照和運(yùn)行時(shí)配置全部正確。發(fā)布前檢查清單共享網(wǎng)格的每個(gè)場(chǎng)景實(shí)例都有可追蹤的烘焙映射。UV2 無(wú)重疊、無(wú)越界實(shí)例縮放和光照紋素密度符合項(xiàng)目標(biāo)準(zhǔn)。未優(yōu)化、靜態(tài)合批、實(shí)例化和 HLOD 已分別做單變量對(duì)照。動(dòng)態(tài)門(mén)窗的移動(dòng)性、探針或體積光照采樣設(shè)置正確。分區(qū)卸載后舊實(shí)例和舊光照引用已清理。分區(qū)重新加載至少測(cè)試 3 次沒(méi)有短暫全黑或映射串位。編輯器與正式構(gòu)建使用同一測(cè)試路線并記錄引擎版本和渲染管線。所有未取得運(yùn)行證據(jù)的結(jié)論均標(biāo)記為“待驗(yàn)證”。先查映射再查采樣模塊化建筑復(fù)制后的光照異常建議固定按照“實(shí)例映射—UV2 與尺度—優(yōu)化重組—?jiǎng)討B(tài)采樣—分區(qū)重載”的順序排查。不要把所有問(wèn)題都?xì)w因于材質(zhì)也不要把一次重新烘焙后的正常畫(huà)面當(dāng)作最終結(jié)論。真正可交付的結(jié)果應(yīng)該在重新打開(kāi)場(chǎng)景、重新構(gòu)建和多次流式加載后仍然一致。你的模塊化建筑更常出現(xiàn)陰影復(fù)制、動(dòng)態(tài)部件發(fā)黑還是分區(qū)重載后整棟光照錯(cuò)位