我從去年開始做自己的引擎時就一直死磕一個問題一個普通3D渲染器到底要改多少地方才能讓它變成能在VR眼鏡里穩(wěn)定輸出畫面的渲染器當時我天真地以為無非就是把攝像機從一臺改成兩臺左右眼各渲染一遍而已。結果第一次把畫面推上眼鏡屏幕看到的是畸變到離譜的畫面、延遲到讓人頭暈的拖影我才意識到VR渲染和桌面渲染差的不是一點半點而是整條渲染管線的底層邏輯都要推翻重來。這個系列做到第十七篇正好輪到虛擬與混合現(xiàn)實的渲染算法這塊。我給自己定的內部代號是vr-rd01rd是renderer的縮寫01代表這是第一版純光柵化渲染路徑不依賴任何商業(yè)VR SDK從算法層面把立體渲染、畸變矯正、時間扭曲這些東西一點一點摳明白。這篇博文就把vr-rd01里最核心的內容整理出來聊清楚VR渲染里光柵化管線到底改了什么、為什么改、以及實際跑通的流程和踩坑。適合正在做自研引擎、或者想從渲染底層理解VR工作原理的朋友也適合那些用現(xiàn)成游戲引擎轉VR開發(fā)、但總被各種詭異現(xiàn)象搞到頭疼的人。1. VR光柵化和桌面渲染的分水嶺為什么把攝像機改成兩臺還不夠先放一個最反直覺的結論在一個桌面渲染器里把場景攝像機從一臺變成左右兩臺渲染出兩張圖然后拼在一起推到屏幕上——這個操作只完成了VR渲染大約30%的工作。剩下的70%全花在解決“VR設備為什么會讓你頭暈”這件事上。1.1 幀率、延遲與有效像素三座繞不開的大山桌面游戲普遍做到30幀就能玩動作游戲做到60幀已經很順滑。但VR頭顯里的屏幕刷新率起步就是90Hz現(xiàn)在的設備普遍120Hz甚至144Hz。為什么因為人的前庭系統(tǒng)對頭部轉動極其敏感一旦畫面更新跟不上頭部運動大腦立刻產生強烈的暈動感。VR行業(yè)里有個共識從光子到運動photon-to-motion的延遲必須控制在20毫秒以內超過這個數絕大多數人會在十分鐘內開始不適。這20毫秒里包含什么傳感器讀取姿態(tài)耗時、CPU提交渲染命令耗時、GPU完成一幀繪制耗時、畸變矯正和掃描輸出耗時、最后把畫面真正點亮在屏幕像素上的時間。每個環(huán)節(jié)都要斤斤計較。桌面渲染里你寫個慢一點的后處理特效沒人管你但VR里哪怕多出3毫秒等待都會明晃晃反映在體驗上。還有有效像素這個坑。很多人看VR頭顯參數說單眼分辨率2560x1440覺得還挺清晰。實際上呢人眼通過透鏡看到的是光學放大后的畫面只有畫面中心區(qū)域像素利用率高四周因為透鏡函數扭曲等效像素密度直線下降。行業(yè)里普遍估算VR屏幕上有將近30%的像素是被浪費掉的。桌面渲染優(yōu)化看三角形數量和填充率VR渲染還得多看一項別把寶貴像素浪費在用戶根本看不清的區(qū)域。1.2 渲染循環(huán)的形態(tài)從“一幀一張圖”變成“一幀兩張圖加一次合成”桌面渲染的經典循環(huán)是模擬更新一次攝像機采樣一次畫到后緩沖交換顯示。VR的循環(huán)則長這樣讀取頭顯最新姿態(tài)對“下一次顯示時刻”的姿態(tài)做預測用預測姿態(tài)分別更新左眼和右眼的視圖矩陣左右眼各做一次完整的場景繪制輸出到兩張獨立紋理對兩張紋理做畸變矯正和透鏡匹配合成為一張幀提交給顯示器等待垂直同步。這還只是最樸素的基礎版本真正產品級的引擎還會在步驟4和5之間插入異步時間扭曲ATW這樣的兜底機制。但vr-rd01的第一步就是先把1到5這條主鏈路用純光柵化算法跑通。我隨時在代碼里提醒自己這里每多一次不必要的渲染就是在跟用戶的大腦前庭作對。1.3 混合現(xiàn)實MR其實走的也是這條主干道做VR渲染算法經常會碰到“虛擬與混合現(xiàn)實”被放在一起提。MR設備和VR設備的渲染差異主要在于MR多了一層“環(huán)境感知”和“視頻透視VST”的疊加。也就是說在光柵化渲染主干的最后合成階段MR需要把攝像頭采集的真實環(huán)境畫面先做校正再和你渲染出來的虛擬物體融合。這條路線不是另起爐灶反而更依賴干凈的左右眼合成流程——因為真實世界畫面一歪虛擬物體疊上去就完全穿幫。所以先把vr-rd01的立體渲染做扎實未來要接MR只是多接一路攝像頭紋理的問題。2. 立體視覺的第一塊基石左右眼非對稱透視投影矩陣立體感從哪來從兩眼看到畫面的差異來。人眼瞳孔距離IPD通常在58到68毫秒之間這個差別導致左右眼看到的物體位置有細微偏移大腦就根據這些偏移計算出深度。渲染端要做的事就是精確模擬這個偏移。2.1 而投影矩陣“非對稱”才是關鍵普通3D渲染的透視投影是標準對稱平截頭體視錐中心正好在觀察方向上。你把攝像機往右移半個瞳距就得到右眼視角往左移半個瞳距就得到左眼視角——這樣做出來的立體感其實是錯的。原因是實際頭顯里左右眼并不正對屏幕中心透鏡把屏幕分成左右兩個顯示區(qū)域每只眼睛看的是自己那片區(qū)域而且因為光學設計的原因眼球的光軸和屏幕法線不重合這就導致左眼看到的視錐是向左偏斜的右眼則向右偏斜。所以VR攝像機的投影矩陣必須是非對稱平截頭體。以左眼為例它的近裁剪面是偏的左邊界拉大右邊界縮小形成一個向左開口的截錐體。這才是真正模擬人眼觀察方式的做法。如果偷懶用標準對稱矩陣表現(xiàn)在畫面上的效果是垂直方向沒有立體感水平方向的立體感方向還是錯的看久了必暈。2.2 vr-rd01里怎么計算這個矩陣我實現(xiàn)了一份通用的非對稱透視矩陣構建函數核心是把眼睛相對屏幕中心的位置換算成平截頭體邊界的偏移量。代碼大致是這樣mat4 buildVRProjectionMatrix(float eyeOffset, float nearPlane, float farPlane, float halfFovX, float halfFovY) { // 先算出對稱平截頭體的四個邊界 float left -halfFovX * nearPlane; float right halfFovX * nearPlane; float bottom -halfFovY * nearPlane; float top halfFovY * nearPlane; // 關鍵一步按照眼睛相對透鏡的偏移量把左右邊界整體平移 left eyeOffset; right eyeOffset; float m00 2.0f * nearPlane / (right - left); float m11 2.0f * nearPlane / (top - bottom); float m22 -(farPlane nearPlane) / (farPlane - nearPlane); float m23 -2.0f * farPlane * nearPlane / (farPlane - nearPlane); float m20 (right left) / (right - left); float m21 (top bottom) / (top - bottom); return mat4( m00, 0.0f, m20, 0.0f, 0.0f, m11, m21, 0.0f, 0.0f, 0.0f, m22, m23, 0.0f, 0.0f, -1.0f, 0.0f ); }調用的時候左眼傳eyeOffset -IPD * 0.5f右眼傳eyeOffset IPD * 0.5f。這里的數值單位要和場景坐標保持一致三個單位統(tǒng)一為米最省事。IPD一定要從設備參數或者用戶設置里讀取不能拍腦袋寫一個固定值——我用65毫米測過再換成一個64毫米的用戶細微的立體感差異就會跳出來。2.3 位置渲染之外還有一個深度方向的問題投影矩陣搞定了左右眼的橫向視差但立體的真實感還依賴焦點深度focus plane的設置。實際上VR屏幕是被透鏡固定在某個光學距離上的人眼看遠處物體時焦距發(fā)生變化理論上光柵化渲染管線的透視模型是無窮遠對焦的也就是焦點深度無限大。這和真實人眼完全不同所以即便渲染管線完全正確依然會有“輻輳調節(jié)沖突”導致的視覺疲勞。這個問題的根治現(xiàn)在各廠商都在研究光場渲染但短期內光柵化的做法是把UI和重要交互元素盡量放在一個固定的光學深度上減少眼睛頻繁對焦的負擔。這就屬于“渲染算法跑通之后設計層面還要補課”的案例了。3. 畸變矯正讓光柵化渲染出來的畫面適配透鏡的光學缺陷VR頭顯里屏幕和眼睛之間隔著一組放大透鏡。透鏡讓畫面變大、視野變寬代價是生產出徑向畸變。二維屏幕上本來橫平豎直的網格線經過透鏡成像后會變成桶形或枕形畸變。如果不做處理你看到的世界是彎的稍微轉動頭部就像掉進哈哈鏡。3.1 矯正思路先畫歪再被鏡片拉正畸變矯正的工程思路非常樸素我知道透鏡會把畫面扭曲成什么樣那我就提前把畫面扭曲成反方向。渲染的時候先做桶形預畸變讓圖像邊緣向內收縮經過透鏡放大之后邊緣正好被拉伸回來最終看到的畫面就是平的。桶形畸變和枕形畸變可以用徑向畸變模型描述。前面提到的光柵化流程畫完正常透視圖像后畸變矯正會在合成階段對圖像做一次采樣重映射。對每個輸出像素計算它對應鏡頭中心的方向和距離再根據徑向畸變系數重新采樣輸入圖像。一段GLSL片段著色器就能完成預畸變的核心計算uniform sampler2D eyeTexture; uniform vec2 lensCenter; uniform vec2 screenCenter; uniform float distortionScale; uniform vec4 distortionParams; // 存放k1, k2, k3, k4 vec2 distortUV(vec2 uv) { vec2 centered uv - screenCenter; float r2 dot(centered, centered); float r4 r2 * r2; float r6 r4 * r2 * r2; float scale distortionParams.x distortionParams.y * r2 distortionParams.z * r4 distortionParams.w * r6; return lensCenter (centered * scale) * distortionScale; } void main() { vec2 srcUV distortUV(gl_FragCoord.xy / screenSize); gl_FragColor texture(eyeTexture, srcUV); }注意這里的distortionScale它等同于畸變矯正中的“預放大倍數”。因為畸變矯正會把有效像素往中心壓縮如果不放大邊緣區(qū)域會因為采樣不足出現(xiàn)像素空洞。加上這個縮放后實際渲染分辨率要比屏幕分辨率高出一截。我實測下來典型取值在0.85到1.15之間具體數值取決于頭顯鏡片設計只能靠對著網格標定拍攝一張準確的照片來推算。3.2 預計算形變網格性能立刻提升一個檔次你不可能每幀都對整張屏幕做逐像素多項式計算雖然GPU算這個不慢但再快也比不上“查表”。成熟方案是初始化時離線算好一張網格把每個輸出像素對應的輸入紋理坐標預計算出來存成偏移紋素。渲染時只要一行紋理采樣連浮點運算都省了。這也是為什么我反復強調vr-rd01的階段劃分里畸變矯正必須獨立成層——因為它和場景復雜度完全無關只依賴鏡頭參數完全可以只算一次。另外畸變矯正階段有個經常被忽略的問題左右眼畫面的畸變中心并不是屏幕的幾何中心而是各自透鏡的光學中心。這兩個中心之間通常存在一點偏移。直接用屏幕中分線當矯正中心邊緣銜接處會出重影。我踩過這個坑后來在初始化階段用了設備標定參數里的鏡頭中心坐標問題立刻消失。4. 異步時間扭曲兜住“渲染趕不上轉頭”的那一幀先做個小實驗戴著頭顯快速左右搖頭再看屏幕上的畫面。理論上渲染幀率如果跟上刷新率畫面應該不卡不暈。但實際光照峰值下GPU繪制復雜的場景總有一幀跟不上這時候如果直接重復上一幀畫面用戶轉頭看到的畫面就會比頭部慢了整整一幀眩暈感瞬間送走你。異步時間扭曲Asynchronous Time WarpATW就是為了解決這個場景誕生的。它的核心思想是與其重復舊幀不如把舊幀的圖像根據最新的頭部姿態(tài)“扭曲”一下讓它盡可能貼合用戶當前看到的角度。4.1 時間扭曲的幾何學本質ATW本質上是一層極輕量的后處理。GPU渲染完一幀并完成畸變矯正后如果發(fā)現(xiàn)頭部姿態(tài)變了就利用新姿態(tài)計算一個旋轉矩陣對這個二維圖像做重投影。在數學上它假設場景絕大部分內容是遠場的忽略視差造成的圖像變化只做旋轉補償。這一招厲害的地方在于成本極低一次紋理采樣加一次旋轉旋轉修正普通的移動級GPU也能在1毫秒內完成整幀扭轉。需要注意的是ATW能兜住旋轉兜不住平移。頭部平移會導致近景物體的視差變化這是二維重投影即使旋轉也恢復不了的。所以ATW的正確使用姿勢是“應急”而不是“常態(tài)化”。我見過一些數據產品級VR應用里ATW貢獻了約20%的流暢度體驗但即使有它畫面依然會有邊緣撕裂的偽影。另一條工程上的做法是壓低渲染分辨率來提升主渲染的余量讓ATW只在極端幀率波谷才被觸發(fā)而不是每一幀都重度依賴。4.2 vr-rd01的插入位置和實現(xiàn)思路我在vr-rd01里把ATW放在了畸變矯正之后、提交掃描之前。實現(xiàn)方式用的是網格重投影把上一幀已經完成畸變矯正的圖像綁定到一張全屏三角形網格上用最新的旋轉四元數更新網格頂點的投影坐標再重采樣渲染。這個方案實現(xiàn)成本低效果也穩(wěn)定。建議想深入移植的朋友按三個版本遞進先做“旋轉四元數修正版”它能解決90%的問題再做“網格翹曲版”解決畫面的邊界偽影最后才過渡到“深度感知重投影”這個版本把渲染管線的深度緩沖引入進來用深度offset補償一部分平移視差但開銷大很多在基礎光柵化這個階段先不碰。4.3 還有一個容易被忽略的“預測窗口”頭顯的姿態(tài)數據從傳感器傳到渲染線程是有延遲的可能10到20毫秒。如果你拿到姿態(tài)那一刻直接渲染等畫面真正顯示出來時用戶頭已經轉到別處了。所以渲染循環(huán)里要引入姿態(tài)預測根據傳感器歷史軌跡外推一個“下次顯示時刻”的姿態(tài)。圖上很簡單但工程上要處理時間基準的同步——GPU渲染這一幀用了8毫秒還是12毫秒直接影響姿態(tài)預測要外推多遠。我處理這個問題時給每一幀都打上了時間戳并且記錄了上一幀的真實GPU耗時用滑動平均來預估當前幀耗時。實踐下來能把圖像的“飄感”削掉一大半。5. 從場景到屏幕把vr-rd01第一條可運行管線完整搭起來講完了上面三個原理塊這段就進入純流水賬式的實操。我用OpenGL作為光柵化后端因為它是暴露渲染管線各階段最直接的選擇能讓人看清每一步到底發(fā)生了什么。如果你用的是Vulkan階段一樣只是命令緩沖的提交方式不同。以下步驟是我在vr-rd01里一晚上跑通的完整順序。5.1 初始化階段采集設備參數這一步不能省。我把設備的屏幕分辨率、左右眼屏幕區(qū)域、鏡頭畸變系數k1/k2/k3/k4、光學中心偏移、瞳距IPD全部讀入一個HardwareParams結構體。初始化時用這些參數生成畸變矯正網格建好左右眼各一張渲染紋理。紋理的尺寸建議設置成實際屏幕單眼分辨率的1.2倍以上給畸變矯正的位置偏移留余量。5.2 渲染循環(huán)階段左右眼各跑一遍完整光柵化主循環(huán)代碼如下while (running) { // 1. 預測姿態(tài)并分別構建左右眼視圖矩陣 Quat predictedPose predictPose(headPose, currentFrameTime); mat4 leftView buildViewMatrix(predictedPose, -IPD * 0.5f, 0.0f); mat4 rightView buildViewMatrix(predictedPose, IPD * 0.5f, 0.0f); // 2. 渲染左眼到紋理 glBindFramebuffer(GL_FRAMEBUFFER, eyeFBO[0]); glViewport(0, 0, eyeWidth, eyeHeight); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); setViewProj(leftView, leftProj); drawScene(); // 3. 渲染右眼到紋理 glBindFramebuffer(GL_FRAMEBUFFER, eyeFBO[1]); glViewport(0, 0, eyeWidth, eyeHeight); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); setViewProj(rightView, rightProj); drawScene(); // 4. 畸變矯正合成單幀 compositeAndDistort(); // 5. 提交顯示 submitFrame(displayTexture); }每一幀都綁定兩次FBO、做兩次完整的場景光柵化這意味著場景里所有三角形都要被送去處理兩次頂點著色器跑兩遍圖元裝配做兩遍。有一次我圖省事想在頂點著色器里一次畫兩遍結果可讀性一塌糊涂。后來還是老老實實走兩遍管線畢竟清晰度比一兩毫秒的節(jié)省重要得多。5.3 合成階段如何把左右眼畫面拼到一塊屏幕上VR頭顯屏幕通常是一整塊左右眼畫面各自占據一半區(qū)域。這里的細節(jié)是畸變矯正合成階段的視口范圍要精確匹配屏幕實際顯示的左右眼區(qū)域并且采樣時要使用預計算的形變網格。合成階段用到兩張紋理的多次采樣但沒必要開MSAA對這些后處理目標做多重采樣樣點都浪費在透鏡邊緣了。我最終的做法是場景渲染目標開4x MSAA畸變合成的最終目標保持單樣本。這里順帶回應一下熱詞里那個“vr渲染器切換cpu gpu模式”的問題。渲染器切CPU模式的問題在于CPU軟光柵化在桌面場景或許能跑但絕對無法達到VR要求的幀率和延遲指標。我的建議是在學習階段你可以用CPU軟渲染器驗證投影矩陣數學是否正確輸出兩張靜態(tài)圖貼在屏幕上對比但真要連上頭顯必須走GPU光柵化。CPU到GPU之間的切換不應該發(fā)生在每幀內部而是作為調試策略整體切換。5.4 驗證清單怎么確認每一步是對的這是我覺得最有用的部分。跑通之后別急著戴頭顯先做離線驗證。我把左右眼渲染結果并排導出成PNG然后用圖形工具疊加對比看同一物體的水平位移是否符合相對距離關系。畸變矯正的驗證方法更絕把一張方格紋理掛在一個平面物體上通過畸變矯正渲染出來再用攝像頭拍屏幕上的最終畫面如果網格線是直的說明畸變參數沒寫錯。這套驗證流程花不了十分鐘時間能幫你擋住90%的“戴上去才發(fā)現(xiàn)暈到不行”的返工。6. 五大性能瓶頸與兩個經典“亂碼”問題的實際排查錄跑通只是起點VR渲染真正拉開差距的是性能。這一節(jié)把vr-rd01調試過程中最有代表性的五個瓶頸和一個奇葩問題寫出來每個都帶排查思路不是單純給結論。6.1 像素過載為什么有效像素只剩七成畸變矯正有個副作用為了讓最終看到的畫面不露邊渲染目標的邊緣像素幾乎全被透鏡壓到用戶看不見的區(qū)域去了。因此實際有效像素率常常只有70%左右。你要展示的精細細節(jié)比如遠處物體上的文字如果被壓到邊緣區(qū)域就是純浪費。工程上兩個調整思路一是把畫面上最需要清晰度的區(qū)域約束到中心半徑范圍內二是對邊緣區(qū)域采用LOD更低的模型。這不算夸張的優(yōu)化只要在兩眼的邊緣各砍400個三角形幀時間就能降下來1到2毫秒值得做。6.2 填充率和MSAA的取舍MSAA是抗鋸齒的好東西但在VR里有個特殊現(xiàn)象邊緣像素出現(xiàn)在每只眼睛各自不同的位置所以每只眼睛都要做一次抗鋸齒MSAA的開銷翻倍。我試過4x MSAA畫面確實干凈了但GPU在復雜場景下直接掉到80幀以下。最后我的選擇是場景簡單時用4x復雜時降到2x同時配合TAA實現(xiàn)時間維度上的邊緣平滑。這個方案比單純提升MSAA質量要穩(wěn)得多。6.3 CPU和GPU不對稱導致的框架抖動VR應用的幀時間預算比較緊張90Hz下一整幀的CPUGPU總耗時不能超過11.1毫秒。某些引擎的CPU提交成本很高場景里幾千個物體拆成上萬個繪制調用CPU用掉8毫秒GPU只剩3毫秒。這種狀態(tài)下哪怕GPU余量再大幀率照樣上不去。排查思路是逐個階段打時間戳CPU提交耗時、GPU執(zhí)行耗時、合成耗時。我發(fā)現(xiàn)過CPU耗時過高居然是因為著色器每次繪制前都在重新編譯變體這個坑不在渲染算法里卻在幀時間統(tǒng)計里尤為刺眼。6.4 一個“亂碼”問題的完整排查鏈路熱詞里提到的“godot引擎游戲亂碼”很多人會懷疑是渲染算法問題但我排查下來這類現(xiàn)象在VR相關項目里通常指向以下幾個固定原因按概率排序著色器編譯宏混亂導致輸出通道錯亂比如把深度值當成顏色輸出了屏幕后期效果節(jié)點的輸入綁定錯誤顯示的是未完成的舊紋理文本編碼問題——字體貼圖的圖集UV計算錯誤或者字符庫沒有正確加載呈現(xiàn)代理狀態(tài)殘留上一個Pass沒有恢復混合模式導致下一個Pass輸出異常。排查方法也固定打印每一幀的FBO紋理實際內容先確認輸入紋理對不對再檢查著色器編譯錯誤日志有沒有未定義的宏或者閃爍的分支條件。絕大多數所謂“亂碼”都逃不出這四個框。渲染算法本身出問題的概率其實很低。6.5 “片源適配”為什么也不算渲染算法問題熱詞里還有“vr眼鏡3d電影片源”它其實觸到了另一個工程點市面上常見的立體影片是左右格式SBS或者上下格式而有一部分HMD設備只支持其中一種或者幀打包方式不對。當你把左右片源誤當成上下片源播放兩個畫面交替出現(xiàn)看起來就是“花屏”。這和渲染算法無關純粹是格式映射沒匹配上。但在自己做引擎的時候要留意你合成階段的輸出格式必須和屏幕面板支持的掃描方式一致否則再好的立體渲染也白搭。這些排查經歷總結下來就是一句話VR渲染問題的根因九成在“數據的排布方式”不對而不是“算法本身”不對。所以排查時先查數據從哪來、往哪去再動算法。7. 最后說點我自己一直在用的調試心得vr-rd01這套基礎光柵化渲染路徑前前后后我調了快三周最大的感悟是不要一上來就戴頭顯。戴上頭顯的一瞬間你就失去了所有調試信息——眼睛看到的是合成后的最終畫面但如果畸變系數錯了、投影矩陣歪了、ATW沒生效你只會覺得頭暈或者畫面糊根本定位不了是哪一層出了問題。我的習慣是給渲染器的每個階段都設一個“導出開關”正常渲染、左右眼原始圖、畸變矯正后、ATW翹曲后分別可以導出到文件。調試時把這些圖導出來并排看一眼就能看出是哪層的鍋。特別是左右眼原始圖重疊之后如果物體邊緣有細微錯位那就是投影矩陣的瞳距或者非對稱參數出了問題如果邊緣是彎曲的那是畸變矯正如果感覺畫面整體粘滯那是ATW和預測窗口的問題。這套方法幫我縮短了大量調試時間。另外一個體積小但收益極高的操作在把每一幀提交給顯示之前畫一個十字掃描線到畫面邊緣用來肉眼判斷畫面刷新是否有跳幀。這個在現(xiàn)實設備上很難靠肉眼捕捉到但這個掃描線的位置能告訴你真正顯示到屏幕上的那一幀是哪一幀。有一個階段我的幀率在88Hz左右徘徊從統(tǒng)計數字上完全看不出問題但實際體驗就暈。畫了掃描線之后才發(fā)現(xiàn)有幾次合成器在等垂直同步時把舊幀重復掃描了這時候我再回頭修ATW問題才真正從根上解決。下一步我這個系列會往前推進到光照模型把Phong改成適用于VR亮度的HDR流程同時對比一下桌面渲染的HDR和VR渲染的HDR在色調映射上到底哪里不一樣。等vr-rd02做完我再回來寫一篇對比報告。