tyflow是基於particle flow的概念,所以基本上是一個事件傳到另一個事件的event-based particle system; 相較於thinkingParticles則是rule-based的。這兩種系統各有各的優缺點。
tyflow是基於particle flow的概念,所以基本上是一個事件傳到另一個事件的event-based particle system; 相較於thinkingParticles則是rule-based的。這兩種系統各有各的優缺點。
又是跟上一篇有關的內容。如果玻璃被掉到地上,要產生寫實的碎裂,在與地板接觸的位置應該有比較高密度的碎片。因此能根據接觸點來切割幾何體便很重要。利用Birth Objects先把Box導入到tyflow中,tyflow預設便會計算地板碰撞。當PhysX Collision觸發到下一個Voronoi Fracture時,其Voronoi point mode切換成Point Cloud。
這篇是前一篇的補充。如果要在撞擊點產生Point Force,我們必須要利用At PhysX Contact Points這個參數。Spawn operator中,Spawn mode選擇At PhysX Contact Points,這樣Point Force產生的位置才會在正好在子彈撞擊處。由上圖可看到Point Force的Gizmo顯示其範圍。
繼續談玻璃碎裂特效。tyflow有一個operator很方便 - Point Force點力場。就是根據粒子產生力場,很實用 (不知道為何thinkingParticles沒有類似的功能?!)。在撞擊的位置產生Spawn一顆粒子,然後產生Point Force。在Point Force中要指定受影響的玻璃碎片群組 - Simulation groups - 2。 產生子彈撞擊的瞬間衝擊力。
前一篇Glass Shattering with tyFlow玻璃碎裂特效part2,玻璃碎裂的中心是用一個sphere幾何體來控制,能不能改成用程序性的產生,槍指哪裡就在哪裡產生碎裂點呢? 答案就是tyflow的raycast operator。
因為官方網站上沒有相關資料,因此做瞭這個簡單統計,看看Phoenix FD的快取檔案中儲存品質(Storage Quality)與最終模擬產生的快取檔案的關係。
Storage Quality |
File Size (Mb) |
減少至原本的% |
14 |
245 |
- |
13 |
211 |
86.1 |
12 |
178 |
72.6 |
11 |
146 |
59.5 |
10 |
116 |
47.3 |
Phoenix FD預設的Storage Quality為14,我模擬了煙的效果共16 frames產生的AUR總快取大小為245Mb。當Storage Quality設置為13,檔案大小降至211Mb。大約為原本的86%。當品質降至10,檔案大小甚至可降至原本的一半以下。
渲染出來的品質整體來說幾乎沒有差別,只有在很細微的地方有差異。可以用jpg壓縮的狀況來比擬。