1. 項目概述從“黑盒”到“白盒”的物理系統(tǒng)探索如果你在Unity里做過一個簡單的盒子從斜坡上滾下來的效果或者實現(xiàn)過一個復(fù)雜的布娃娃系統(tǒng)那你一定和物理系統(tǒng)打過交道。大多數(shù)時候我們把它當(dāng)作一個“黑盒”設(shè)置剛體Rigidbody、碰撞體Collider調(diào)整幾個參數(shù)然后物理引擎就會自動處理碰撞、重力、關(guān)節(jié)約束這些復(fù)雜的事情。但當(dāng)你遇到一些棘手的問題比如物體莫名穿透、關(guān)節(jié)抖動、或者性能突然下降時僅僅調(diào)整參數(shù)往往無濟(jì)于事。這時深入引擎源碼理解物理系統(tǒng)內(nèi)部的運(yùn)作機(jī)制就成了解決問題的關(guān)鍵。這也是我們繼上一篇基礎(chǔ)架構(gòu)分析后繼續(xù)深入“Unity引擎源碼-物理系統(tǒng)詳解”的原因。這次我們把焦點(diǎn)從宏觀架構(gòu)轉(zhuǎn)向更核心的模擬流程與算法實現(xiàn)。物理系統(tǒng)的核心任務(wù)是在每一幀將場景中所有物理實體的狀態(tài)位置、旋轉(zhuǎn)、速度向前推進(jìn)一小步。這個過程看似簡單實則內(nèi)部包含了碰撞檢測Broad Phase Narrow Phase、碰撞求解Constraint Solver和積分Integration等多個精密環(huán)節(jié)。理解這些環(huán)節(jié)不僅能幫你精準(zhǔn)定位“物體為什么穿墻了”、“關(guān)節(jié)為什么抖個不?！边@類問題更能讓你在開發(fā)賽車游戲、物理解謎或復(fù)雜的角色交互時擁有優(yōu)化性能和穩(wěn)定性的主動權(quán)。無論是使用內(nèi)置的PhysX還是探索基于DOTS的Unity Physics或Havok Physics其底層邏輯是相通的。我們將剝開這層外殼看看Unity是如何將物理世界的法則轉(zhuǎn)化為一行行可執(zhí)行的代碼。2. 物理模擬的核心循環(huán)拆解Unity的物理模擬無論是基于GameObject的傳統(tǒng)系統(tǒng)還是基于ECS的DOTS物理都遵循一個經(jīng)典的“模擬循環(huán)”。這個循環(huán)是物理引擎的心臟驅(qū)動著整個虛擬世界的運(yùn)動。理解這個循環(huán)是理解一切物理現(xiàn)象和調(diào)試問題的基石。2.1 傳統(tǒng)物理系統(tǒng)PhysX的幀內(nèi)流程在傳統(tǒng)的、基于MonoBehaviour的系統(tǒng)中物理模擬獨(dú)立于渲染幀運(yùn)行其頻率由Time.fixedDeltaTime控制。一個完整的FixedUpdate物理幀內(nèi)引擎內(nèi)部大致執(zhí)行以下順序應(yīng)用力與扭矩Apply Forces/Torques在FixedUpdate函數(shù)調(diào)用后物理引擎會收集所有作用于剛體上的力如AddForce、扭矩AddTorque和沖量AddImpulse。這是改變物體運(yùn)動狀態(tài)的輸入階段。寬階段碰撞檢測Broad Phase這是性能優(yōu)化的第一道關(guān)卡。引擎不會愚蠢地讓場景中每一個物體都去和另一個物體檢測碰撞。寬階段的目標(biāo)是快速找出可能發(fā)生碰撞的物體對Pair。Unity PhysX通常使用軸對齊包圍盒AABB層次結(jié)構(gòu)如動態(tài)AABB樹來實現(xiàn)。它會遍歷所有碰撞體用它們的AABB進(jìn)行快速的重疊測試將大量不可能碰撞的組合剔除生成一個“潛在碰撞對”列表。你可以通過Physics類的設(shè)置來調(diào)整寬階段算法例如在復(fù)雜場景中合理的AABB膨脹Physics.defaultContactOffset能平衡精度和性能。窄階段碰撞檢測Narrow Phase對上一步篩選出的每個潛在碰撞對進(jìn)行精確的幾何相交測試。這是計算密集型操作。例如一個BoxCollider和一個MeshCollider的檢測就需要進(jìn)行多邊形層面的精確計算。此階段會計算出碰撞的詳細(xì)信息接觸點(diǎn)Contact Point、接觸法線Contact Normal和穿透深度Penetration Depth。這些數(shù)據(jù)是后續(xù)求解的基礎(chǔ)。求解器準(zhǔn)備Solver Setup將碰撞信息、關(guān)節(jié)約束等全部轉(zhuǎn)化為物理引擎內(nèi)部求解器能處理的數(shù)學(xué)形式——通常是約束方程。例如一個碰撞約束可以理解為“兩個物體在接觸點(diǎn)法線方向上相對速度不能為負(fù)即不能繼續(xù)穿透”。關(guān)節(jié)則更復(fù)雜可能包含位置、旋轉(zhuǎn)、角度限制等多個約束。約束求解Constraint Solver這是物理模擬中最核心、最復(fù)雜的步驟。求解器如PhysX使用的PGS迭代求解器的任務(wù)是解算所有約束方程計算出為了滿足這些約束不穿透、關(guān)節(jié)連接每個剛體所需要的速度或沖量調(diào)整量。這個過程是迭代的迭代次數(shù)Physics.defaultSolverIterations直接影響模擬的穩(wěn)定性和精度。迭代次數(shù)少計算快但可能不穩(wěn)定關(guān)節(jié)松散、堆疊晃動迭代次數(shù)多更穩(wěn)定但更耗時。積分Integration根據(jù)求解器計算出的最終速度已考慮了碰撞和約束的反作用結(jié)合上一幀的位置通過積分公式如半隱式歐拉法更新每個剛體的位置Position和旋轉(zhuǎn)Rotation。同時也會更新一些內(nèi)部狀態(tài)如用于睡眠判斷的速度緩存。觸發(fā)與回調(diào)Triggers Callbacks如果發(fā)生碰撞的物體設(shè)置了isTrigger或者腳本中監(jiān)聽了OnCollisionEnter等消息物理引擎會在此階段組織并派發(fā)這些回調(diào)事件到游戲邏輯層。睡眠管理Sleep Management為了節(jié)省性能幾乎靜止的物體會進(jìn)入“睡眠”狀態(tài)。引擎會檢查剛體的動能如果低于某個閾值Physics.sleepThreshold且一段時間內(nèi)沒有受到外力則讓其“入睡”在后續(xù)幀中跳過該物體的絕大部分物理計算直到它被碰撞或外力喚醒。注意這個順序是邏輯上的實際在PhysX原生代碼中可能交錯或并行。但作為使用者建立這個順序模型對調(diào)試至關(guān)重要。例如在FixedUpdate中修改剛體位置會影響寬/窄階段檢測而在OnCollisionEnter中施加力則要等到下一幀的“應(yīng)用力”階段才會生效。2.2 DOTS物理Unity Physics/Havok Physics的并行化革新基于ECS架構(gòu)的DOTS物理系統(tǒng)核心目標(biāo)是將上述流程并行化、批量化以榨干多核CPU的性能。其模擬循環(huán)在概念上相似但數(shù)據(jù)組織和執(zhí)行方式有本質(zhì)區(qū)別數(shù)據(jù)布局所有物理組件如PhysicsVelocity,PhysicsCollider,PhysicsMass都是IComponentData存儲在緊密排列的Chunk內(nèi)存中。這種布局對CPU緩存極其友好是高性能的基石。作業(yè)系統(tǒng)調(diào)度模擬循環(huán)中的每一個階段如碰撞檢測、求解器、積分都被封裝成一個或多個IJobEntity或IJob。Unity的作業(yè)系統(tǒng)Job System會自動將這些作業(yè)調(diào)度到多個CPU核心上并行執(zhí)行。例如計算所有剛體下一幀速度的積分作業(yè)可以輕松地并行處理成千上萬個實體。碰撞檢測的并行化DOTS物理使用全新的、為并行計算設(shè)計的碰撞檢測算法。寬階段可能使用并行化的Sweep and Prune或并行邊界體積層次結(jié)構(gòu)BVH構(gòu)建。窄階段的幾何測試也被設(shè)計成可并行執(zhí)行。求解器的差異Unity Physics作為“無狀態(tài)”物理其求解器設(shè)計更傾向于避免依賴上一幀的緩存狀態(tài)這使得它在網(wǎng)絡(luò)同步和確定性模擬方面有潛在優(yōu)勢。而Havok Physics for Unity則集成了經(jīng)過工業(yè)驗證的、帶智能緩存的求解器在復(fù)雜堆疊和穩(wěn)定性上表現(xiàn)更佳但其底層核心是閉源的C引擎。同步點(diǎn)盡管作業(yè)可以并行但階段之間存在依賴關(guān)系。比如必須等所有碰撞檢測作業(yè)完成才能開始求解器作業(yè)。ECS通過System的[UpdateBefore/After]屬性或EntityCommandBuffer來管理這些依賴和同步。實操心得從傳統(tǒng)PhysX轉(zhuǎn)向DOTS物理時最大的思維轉(zhuǎn)變是從“面向?qū)ο蟆钡健懊嫦驍?shù)據(jù)”。你不再是通過GetComponentRigidbody來操作單個物體而是通過Entities.ForEach來批量處理所有具備特定物理組件的實體。這種范式對于大規(guī)模、同質(zhì)化的物理對象如成千上萬的子彈、碎片、粒子性能提升是顛覆性的但對于少量、異質(zhì)性強(qiáng)的復(fù)雜交互如一個主角與復(fù)雜環(huán)境的多種交互傳統(tǒng)模式在開發(fā)效率上可能仍有優(yōu)勢。3. 碰撞檢測的深度解析從AABB到接觸流形碰撞檢測是物理系統(tǒng)中最耗時的部分之一也是bug的高發(fā)區(qū)。我們深入看看Unity是如何實現(xiàn)它的。3.1 寬階段Broad Phase的策略與優(yōu)化寬階段的目標(biāo)是快速縮減需要精確檢測的物體對數(shù)量。Unity PhysX主要采用動態(tài)AABB樹Dynamic Bounding Volume Hierarchy Tree。工作原理引擎為場景中每個活動的碰撞體維護(hù)一個軸對齊包圍盒AABB。這些AABB被組織成一棵二叉樹。當(dāng)物體移動時其AABB更新樹的結(jié)構(gòu)也會進(jìn)行局部調(diào)整重插或重構(gòu)。每一幀通過遍歷這棵樹可以高效地找出所有AABB重疊的葉子節(jié)點(diǎn)對。關(guān)鍵參數(shù)影響Physics.defaultContactOffset這個值不僅用于解決浮點(diǎn)誤差在寬階段中它會被用來“膨脹inflate”物體的AABB。更大的值意味著AABB更大能更早地觸發(fā)碰撞檢測避免高速物體穿透但也會導(dǎo)致更多的潛在碰撞對進(jìn)入窄階段增加計算量。這是一個典型的精度與性能的權(quán)衡。Physics.broadphaseType在某些版本或自定義中你可以選擇寬階段算法如Sweep and Prune。對于動態(tài)物體多、運(yùn)動頻繁的場景動態(tài)AABB樹通常綜合性能更好。調(diào)試技巧在Scene視圖開啟Gizmos - Physics下的Colliders顯示你可以看到碰撞體的線框。高速移動的物體如果發(fā)生穿透可以嘗試適當(dāng)增大defaultContactOffset。同時觀察Profiler窗口的Physics.Processing部分如果Broadphase耗時異常高可能是場景中動態(tài)物體過多或AABB設(shè)置不合理。3.2 窄階段Narrow Phase的幾何對決窄階段接收寬階段傳來的物體對進(jìn)行精確的幾何相交測試。不同類型的碰撞體組合測試算法完全不同基礎(chǔ)圖元對圖元如Sphere-Sphere, Box-Box, Capsule-Capsule。這些有直接的數(shù)學(xué)公式速度最快。圖元對凸包Convex Hull凸包碰撞體Convex Hull Collider是性能與精度折中的選擇。檢測算法通常使用分離軸定理Separating Axis Theorem, SAT或Gilbert–Johnson–Keerthi (GJK) 算法配合擴(kuò)張多面體/平移向量EPA算法。GJK用于快速判斷是否相交EPA則在相交時計算穿透深度和方向。網(wǎng)格碰撞體Mesh Collider這是性能殺手。當(dāng)Mesh Collider特別是非凸的參與檢測時引擎通常需要將其三角面片與另一個碰撞體進(jìn)行逐一或分區(qū)測試。務(wù)必勾選Convex選項將其轉(zhuǎn)換為凸包性能會提升數(shù)個數(shù)量級。對于靜態(tài)的環(huán)境網(wǎng)格使用Mesh Collider并標(biāo)記為Static引擎會為其生成優(yōu)化的空間數(shù)據(jù)結(jié)構(gòu)如BVH但動態(tài)物體與之碰撞的成本依然很高。一個關(guān)鍵概念接觸流形Contact Manifold窄階段輸出的不是單個接觸點(diǎn)而是一個接觸流形——即一組通常是1-4個能最好地描述兩個碰撞體接觸區(qū)域的接觸點(diǎn)。例如一個立方體平面放在地上理想的接觸流形是四個角點(diǎn)。使用流形而非單點(diǎn)能使后續(xù)的求解更穩(wěn)定防止物體在接觸邊緣搖擺或旋轉(zhuǎn)。在Unity PhysX中你可以通過Physics.Contact相關(guān)的API部分需通過底層接口來獲取這些信息這對于實現(xiàn)自定義的碰撞效果如根據(jù)接觸點(diǎn)播放音效非常有用。注意事項Mesh Collider的Cooking Options在導(dǎo)入設(shè)置或組件上對性能和穩(wěn)定性有巨大影響。Use Fast Midphase和Cook For Faster Simulation通常應(yīng)該開啟。對于移動平臺要嚴(yán)格控制網(wǎng)格碰撞體的面數(shù)并積極使用凸包近似或?qū)哟位唵闻鲎搀w組合來代替單一復(fù)雜網(wǎng)格碰撞體。4. 約束求解器物理穩(wěn)定的幕后功臣求解器是物理引擎的“大腦”它負(fù)責(zé)解決所有沖突的約束。想象一下有十個盒子堆成一個塔每個盒子都受到重力同時盒子之間又有碰撞約束防止相互穿透。求解器的任務(wù)就是計算出每個盒子在這一幀應(yīng)有的移動讓所有約束都盡可能得到滿足。4.1 迭代求解速度與穩(wěn)定的平衡Unity PhysX默認(rèn)使用順序沖量法Sequential Impulse這是一種投影高斯-賽德爾Projected Gauss-Seidel, PGS迭代求解器。它的工作方式很直觀列出所有約束方程碰撞、關(guān)節(jié)等。遍歷每一個約束獨(dú)立地計算滿足該約束所需的沖量調(diào)整并立即應(yīng)用到相關(guān)物體上。由于物體可能同時參與多個約束一次調(diào)整可能會破壞之前已滿足的約束。因此需要重復(fù)步驟2多次即迭代。經(jīng)過多次迭代后所有約束會趨于一個近似解。關(guān)鍵參數(shù)Physics.defaultSolverIterations全局迭代次數(shù)。增加此值可以提高堆疊穩(wěn)定性、關(guān)節(jié)剛性但代價是CPU時間線性增加。對于簡單的場景4-6次可能就夠了對于復(fù)雜的布娃娃或車輛可能需要10-20次。Physics.defaultSolverVelocityIterations速度約束的迭代次數(shù)主要影響接觸和關(guān)節(jié)的反彈、摩擦力求解。通常比位置迭代次數(shù)設(shè)置得高一些效果更好。實操心得不要盲目增加迭代次數(shù)。首先應(yīng)該優(yōu)化碰撞體確保沒有過于細(xì)長或尺度差異巨大的碰撞體這會導(dǎo)致數(shù)值病態(tài)檢查是否有持續(xù)深度穿透的情況可能是defaultContactOffset太小或物體生成位置重疊。對于特定的、需要高穩(wěn)定性的關(guān)節(jié)如角色鉸鏈可以使用ConfigurableJoint的solverIterationCount屬性進(jìn)行單獨(dú)覆蓋而不是全局提高開銷。4.2 關(guān)節(jié)約束的內(nèi)部實現(xiàn)關(guān)節(jié)Joint是比碰撞約束更復(fù)雜的約束類型。以最靈活的ConfigurableJoint為例在求解器內(nèi)部它會被分解為多個簡單的線性約束和角約束線性限制Linear Limit相當(dāng)于在特定軸上設(shè)置了一個“不可逾越”的位置范圍約束。角度限制Angular Limit限制了繞特定軸旋轉(zhuǎn)的角度。彈簧Spring和阻尼Damper這些是“軟約束”求解器會將其轉(zhuǎn)化為試圖達(dá)到目標(biāo)位置或速度的力而不是硬性限制。在源碼層面每個關(guān)節(jié)類型都會在初始化時向物理場景注冊對應(yīng)的約束器Constraint。在每幀求解階段這些約束器會將其當(dāng)前的物理狀態(tài)如連接的兩物體的位置差、角度差轉(zhuǎn)化為求解器能處理的線性互補(bǔ)問題LCP形式。常見問題排查關(guān)節(jié)抖動或“爆炸”突然產(chǎn)生巨大力量飛出去通常源于數(shù)值誤差累積嘗試稍微增加關(guān)節(jié)的breakForce一個不可能達(dá)到的值或調(diào)整massScale改變連接體的有效質(zhì)量比。約束沖突例如同時鎖定了某個方向的移動和在該方向設(shè)置了彈簧可能導(dǎo)致求解器振蕩。時間步長不穩(wěn)定確保Time.fixedDeltaTime是固定的且Time.maximumAllowedTimestep能防止卡頓幀導(dǎo)致過大的物理步進(jìn)。5. 性能優(yōu)化與調(diào)試實戰(zhàn)指南理解了原理最終要服務(wù)于實踐。以下是一些基于源碼邏輯的實戰(zhàn)優(yōu)化和調(diào)試技巧。5.1 性能剖析與瓶頸定位首先必須善用Unity Profiler打開Profiler窗口切換到Physics或Physics2D子面板。觀察Physics.Processing的總耗時以及其下的子項Broadphase耗時高說明動態(tài)物體太多或AABB更新頻繁。考慮將靜止物體設(shè)為Static或使用Rigidbody的Sleep模式。Narrowphase耗時高說明復(fù)雜碰撞檢測多。檢查是否大量使用了非凸MeshCollider或碰撞體三角面片過多。Solver耗時高說明約束復(fù)雜堆疊多、關(guān)節(jié)多。嘗試優(yōu)化迭代次數(shù)或簡化物理場景。使用Physics DebuggerWindow - Analysis - Physics Debugger 需安裝Package。它可以可視化物理世界的狀態(tài)如顯示碰撞體、接觸點(diǎn)、剛體睡眠狀態(tài)等是定位問題區(qū)域的利器。5.2 針對性的優(yōu)化策略分層碰撞Layer Collision Matrix這是最有效的優(yōu)化手段之一。在Edit - Project Settings - Physics中精心設(shè)計碰撞矩陣。讓不需要相互碰撞的物體層徹底忽略對方如子彈和子彈、遠(yuǎn)處的裝飾物之間能直接減少寬階段和窄階段的工作量。剛體屬性優(yōu)化Interpolate只在視覺抖動時才開啟它會消耗額外內(nèi)存和計算進(jìn)行插值。Collision Detection對于高速物體Continuous或Continuous Dynamic可以防止穿透但性能開銷巨大。Continuous Dynamic只對標(biāo)記為動態(tài)的物體進(jìn)行連續(xù)檢測是較好的折中。盡可能使用Discrete并通過合理設(shè)計游戲規(guī)則如限制速度來避免穿透。將不需要受物理驅(qū)動的物體如跟隨玩家的攝像機(jī)、粒子效果發(fā)射器的Rigidbody設(shè)為Kinematic。碰撞體優(yōu)化用簡單形狀復(fù)合一個復(fù)雜物體用多個Box、Sphere、Capsule組合遠(yuǎn)比一個Mesh Collider高效。簡化網(wǎng)格碰撞體如果必須用Mesh Collider使用簡化后的低模網(wǎng)格。合理使用TriggerTrigger不參與物理求解開銷小于普通碰撞體。對于僅需檢測重疊的區(qū)域使用Trigger。5.3 高級調(diào)試深入引擎內(nèi)部當(dāng)你遇到無法用常規(guī)手段解釋的物理bug時可能需要更深入的洞察可視化接觸與法線可以編寫一個調(diào)試腳本在OnCollisionStay或通過Physics.Contact查詢用Debug.DrawLine或Gizmos.DrawRay繪制出每個接觸點(diǎn)的位置和法線方向。這能幫你判斷碰撞檢測是否準(zhǔn)確法線方向是否符合預(yù)期。模擬確定性測試對于需要網(wǎng)絡(luò)同步或錄像回放的游戲物理的確定性至關(guān)重要。確保所有物理相關(guān)的計算包括隨機(jī)數(shù)都在FixedUpdate中進(jìn)行并使用固定的Time.fixedDeltaTime。可以記錄關(guān)鍵剛體幾幀內(nèi)的位置/旋轉(zhuǎn)數(shù)據(jù)在相同輸入下反復(fù)運(yùn)行檢查輸出是否一致。源碼輔助理解雖然看不到PhysX的完整C源碼但Unity提供了部分封裝層的C#源碼通過Unity源碼訪問或反編譯工具。閱讀Rigidbody、Collider等類的底層接口調(diào)用以及Physics、RaycastHit等結(jié)構(gòu)的定義能幫助你理解參數(shù)是如何傳遞到底層引擎的。對于DOTS物理其C#源碼是開放的直接閱讀Unity.Physics包中的SimulationStep.cs、CollisionQuery.cs等文件是理解其并行化實現(xiàn)的最佳途徑。我個人在實際項目中的一個深刻教訓(xùn)曾有一個賽車游戲車輛在特定彎道偶爾會莫名彈飛。通過Profiler發(fā)現(xiàn)該幀Solver耗時激增。用Physics Debugger可視化后發(fā)現(xiàn)是賽道邊緣的一個復(fù)雜裝飾物Mesh Collider未勾選Convex與車輪的多個膠囊碰撞體產(chǎn)生了大量非預(yù)期的接觸點(diǎn)導(dǎo)致求解器在該處“卡住”并產(chǎn)生巨大沖量。解決方案是將那個裝飾物的碰撞體替換為一個簡單的Box Collider問題立即消失。這個案例讓我明白物理性能問題往往不是均勻分布的而是由場景中少數(shù)幾個“熱點(diǎn)”引起的精準(zhǔn)定位這些熱點(diǎn)是關(guān)鍵。