HairStrandPlugin的迭代總結

來源： 52vr | 責任編輯：傳說的落葉 | 發(fā)布時間： 2019-06-13 08:17 | 瀏覽量：

這篇文章介紹了HairStrandPlugin在迭代過程中遇到的一些問題以及思考。

背景

HairStrandPlugin的1.0版本推出到現(xiàn)在也已經(jīng)過去快一個月了，在這段期間我也一直在不停調試這個插件以及模擬代碼，在此記錄一下迭代過程中碰到的一些問題以及對應的思考。

代碼層次的迭代

長度約束（Distance Constraint）邏輯迭代

問題描述

在參考TressFX的論文和代碼過程中，我個人收獲很大，但是開源的TressFX似乎還是藏起了一些黑科技。誠然，在系統(tǒng)偏向穩(wěn)定的情況下，TressFX的效果非常好，而且針對于中短發(fā)的約束收斂也做的很不錯，此外還使用GPU進行多線程模擬，大大提升了運算效率。

但是略有蛋疼的是——在不太穩(wěn)定的系統(tǒng)下，TressFX針對于長度的收斂還是不夠的，在TressFXSimulation.hlsl中能夠找到如下代碼：

[代碼]：

					
									01
								
									void ApplyDistanceConstraint(inout float4 pos0, inout float4 pos1, float targetDistance, float stiffness = 1.0)
							
									02
								
									{
							
									03
								
									    float3 delta = pos1.xyz - pos0.xyz;
							
									04
								
									    float distance = max(length(delta), 1e-7);
							
									05
								
									    float stretching = 1 - targetDistance / distance;
							
									06
								
									    delta = stretching * delta;
							
									07
								
									    float2 multiplier = ConstraintMultiplier(pos0, pos1);
							
									08
								
									09
								
									    pos0.xyz += multiplier[0] * delta * stiffness;
							
									10
								
									    pos1.xyz -= multiplier[1] * delta * stiffness;
							
									11
								
									}

這意味著在頭發(fā)高速運動的過程中（例如角色急速沖刺、墜下山崖等），發(fā)絲依然有可能被拉長，以下的截圖來自原生的TressFX的可執(zhí)行文件。

可以看到當模型進行位移時，頭發(fā)還是出現(xiàn)了拉扯的情況。這還僅僅是小位移，聯(lián)想到古墓麗影中勞拉運動速度比這高的情況還是比較多的，因此大概可以推測還有黑科技沒有批露出來。

誠然這種狀況可以通過調節(jié)例如迭代次數(shù)、Substeptime來進行改善，但畢竟僅僅是改善而已，無法徹底解決。而且單一的調整上面的數(shù)值還會影響整個發(fā)絲的質感，工作量還是比較大。

插件在《隱龍傳：影蹤》的實裝過程也遇到了這個問題。由于《隱》是一個動作游戲，角色的運動速度有時會很高（例如主角在空中的重下劈速度達到了100m/s），因此在最初的實裝中頭發(fā)不可避免地被拉長了。

解決方案

最終的解決方案是在進行發(fā)絲設計時先離線計算出各個粒子與發(fā)根粒子的穩(wěn)定距離，然后在模擬的過程中檢測距離的大小關系。如果距離過大了，則強制將粒子推至穩(wěn)定距離的位置。

這樣的方案能夠是Iteration數(shù)量大大減少，目前來看針對于每根發(fā)絲來說只需要進行一次Iteration即可。而且發(fā)絲的表現(xiàn)效果也更加穩(wěn)定，當主角在山崖間快速跳躍的時候發(fā)絲也并不會被拉長。

上圖是初次實裝后的效果，可以看到長度被約束到了一個穩(wěn)定值（鋸齒狀的震顫來源于阻尼沒有調整好，大家無視即可……）。

LOD的實現(xiàn)

由于發(fā)絲的模型是依照樣條曲線來進行動態(tài)構建的，因此導致發(fā)絲的網(wǎng)格會比較密，這樣一來對GPU的消耗就有可能比較大（雖然我知道這個插件主要是CPU殺手……）。

因此花了一些精力用于動態(tài)LOD的構建了，難度不大也沒什么好說的，距離越遠則網(wǎng)格越稀疏而已……

發(fā)絲插值

工具鏈問題

發(fā)絲插值是一個很蛋疼的事，而這個蛋疼不是來源自技術而是來源自工具鏈。

由于《隱》的開發(fā)團隊人數(shù)比較少，因此很多時候都只能使用現(xiàn)有的工具來進行開發(fā)。由于模型師的習慣，針對于發(fā)型的設計是使用Maya的Shave插件，然后直接導出曲線數(shù)據(jù)，再在UE4中進行導入操作。

但是這樣一來，發(fā)絲與發(fā)絲之間的拓撲結構就被破壞了。導出之后的曲線數(shù)據(jù)不帶有“哪三根曲線是在同一個三角面上”的信息，因此原本想好的三角面插值就難以實現(xiàn)了。

這個問題嘛……實際上不隸屬與這個插件，難度也不大，但是由于涉及到工具鏈改變所帶來的成本因此暫時就這樣擱下了。目前的發(fā)絲插值是針對發(fā)絲插值總數(shù)進行隨機的兩兩發(fā)絲配對，然后在渲染的時候在這兩根發(fā)絲之間進行插值即可。

插值發(fā)絲的碰撞結算

這個問題目前也還沒解決。發(fā)絲的插值的出現(xiàn)的目的主要是用于解決模擬發(fā)束太少而導致發(fā)絲稀疏的問題，換句話說，可能針對于類似于馬尾之類的簡單發(fā)型，只需要四五根發(fā)絲進行模擬結算，然后在這些發(fā)絲之間進行插值即可，這樣能夠大大節(jié)省CPU運算時間。

但是這樣的潛在問題在于如果這幾根發(fā)絲之間有一些進行了碰撞結算而其他的沒有進行碰撞結算該怎么辦？如果直接進行插值的話勢必會導致有一些發(fā)絲直接進入了碰撞體內(nèi)，但是如果針對于插值發(fā)絲再進行碰撞結算則一來計算量將增大不少，二來只有碰撞結算而無長度約束將導致發(fā)絲的極度詭異的狀況。

目前來看，插件提供的插值功能只適用與單側馬尾這一類走向統(tǒng)一，發(fā)束簡單的發(fā)型。如果日后能夠解決三角面插值的問題的話，這個問題也將得到一定程度的解決。

線條網(wǎng)格（Line Primitive）

不同于三角網(wǎng)格，Line Primitive是用于線條的繪制。隨著現(xiàn)在機器性能的提升，大量的Line Primitive也不再是幻想了。

在這個迭代后，開發(fā)者可以選擇是否使用LinePrimitive進行模擬，并且也可以工作正常。但是可以預見的問題是：除非插值發(fā)絲的問題得到解決，否則使用LinePrimitive勢必帶來極高的CPU運算量。

或者……如果與TressFX一樣，將模擬邏輯寫到GPU上，應該也能解決這個問題。

質點系統(tǒng)

這個東西其實很簡單也不需要多說——越靠近發(fā)根的粒子質量越大，越遠離發(fā)根的粒子質量越小。這樣一來在進行物理模擬的時候將更加真實。

下一步的計劃

GPU！GPU！GPU！

工具鏈！工具鏈！工具鏈！

GrowMesh的對應邏輯。