發表文章

目前顯示的是 1月, 2025的文章

Unity:製作可相交的視差遮蔽貼圖 Shader 續 (Parallax Occlusion Mapping Shader with Pixel Depth Offset)

圖片
前言 在 幾年前的文章 曾有提到嘗試製作可相交的視差遮蔽貼圖(以下都簡稱 POM) Shader,然而當時一直留下一個疑問,就是計算深度偏移的量一直不是很正確。 本文新的實現方法,與幾年前的看起來相似,但是有穩定的深度位移 多年後終於有能力重新整理過一次,看了 Unity 的原始碼才發現當年已經離問題的所在很接近了,在後來版本的 Unity 裡面可以看到解決方法,在 Shader Graph Parallax Occlusion Mapping 這個 Node 的參數可以看到問題的所在。 POM 控制垂直偏移高度的參數(Unity 中為 Amplitude)在本文章使用的是物件空間座標,如果偏移高度參數是 0.6,代表著表面到最底部距離在物件空間的座標下相差 0.6 公尺。   原始碼 有關原始碼,請詳見 Github 專案 。    問題根源-如何計算逐像素的世界空間座標偏移量 這個問題關鍵就在於 UV 空間座標的 U軸 和 V 軸這兩個基向量在物件空間的長度。當要計算各個像素位移後的深度時必須知道各個像素在偏移後的世界座標是多少,然後再計算出深度。 提醒一點:U 軸 和 V 軸基向量在某些條件對應到切線與副切線,但不是絕對,因為 U軸 和 V 軸可以沒有正交,切線與副切線卻必須正交,這個限制了使用 POM 的模型不能有太多 UV 扭曲和法線調整 從 POM 的計算裡會得到射線(viewDir)與位移後表面交點的高度(Tp 點的高度),可以藉此高度值計算 T0 到 Tp 的位移向量 T0Tp ,如果這個位移向量的長度正好就是世界空間的長度,那麼只需要將是世界空間的射線向量乘以這個長度,然而在將射線的向量轉換的過程中會令這個長度可能沒有符合世界空間的長度,所以要在轉換過程中確保轉換後的長度一致。 Unity 版本的視差遮蔽,由物件表面為 1 起始 Created by modifying " LearnOpenGL " (©  JoeyDeVries ( Licensed under CC BY 4.0 ))   用來計算 POM 的射線一開始為世界空間的單位向量(viewDirWS),如果使用此向量,得到的偏移高度會是世界空間,無法跟隨物體縮放,於是一開始先除以...

Blender:Geometry Node 應用於營造法式生成大木作構件初探-小結

摘要 本文對過去 Blender 客製化 Geometry Node 探究的過程做小結。     Blender 客製化 Geometry Node 的部分目前打算不會進行製作其他構建的嘗試,原本是已經開始在動工栱的部分,然而去年發生不少事情,目前已經沒有太多時間處理,最近終於有一些時間於是決定在這個階段收尾。    文章 Geometry Node 應用於營造法式生成大木作構件初探-梭柱篇 :初步使用 Geometry Node 生成建築構件 Geometry Node 應用於營造法式生成大木作構件初探-卷殺折線標準化篇 :初步探討如何透過程式碼 添加客製化 Geometry Node Geometry Node 應用於營造法式生成大木作構件初探-斗篇 :簡單探討如何呼叫其他程式碼撰寫的 Geometry Node   Git repository YingzaoFashi-Blender-Procedural-Model :放置了程序化生成的建築構件  blender-self-use-custom-geometry-node :添加客製化 Geometry Node 的 Blender   完成與未完成的研究  基本上目前至少可以知道,在客製化節點方面已經達成了兩件事: 如何使用 C++ 結合 Python 撰寫客製化的節點 如何在客製化的節點中呼叫其他 Geometry Node 節點的方法 未完成的部分還有這幾項: 如何在客製化節點中生成 UV、法線或切線數據 如何呼叫在節點編輯器中製作的節點 未來發展方向 未來 Geometry Node 程序化生成可能不會朝向零件也這樣做,因為工時上耗費的關係。比較可能的發展方向是採取混合,建築零件手工製作而建築整體採用程序化生成的方式。  

Blender:Geometry Node 應用於營造法式生成大木作構件初探-斗篇

圖片
摘要 本文進一步探索 Blender 客製化 Geometry Node,包含呼叫其他 Geometry Node 的功能,能夠將原本的 Node Graph 轉為單一 Node。 前言 繼上一篇處理完卷殺折線的程序化生成後,原本想要進一步處理栱的部分,不過發現栱與抖有依賴的關係,栱的一部分數據需要來自枓,主要是枓底的尺寸。 製作這些枓的程序化生成模型,首先要看看這些枓有沒有共通點? 枓的規則 枓的構成與尺寸示意 《營造法式》所有枓基本上都可以分成從上到下三個部位耳、平、欹,形狀上可以分為方或圓(現實實例的話則不只)。 基本上變化除了榫卯(包含包耳)以外還有尺寸的差異,而尺寸依然使用材分決定。整體尺寸上各種枓長寬高不同,會以相對比例決定耳、平、欹的尺寸,但在高度上耳、平、欹比例均各為 2:1:2 分配。欹䫜也不同。   枓的參數 從上面大致上整理一下,可以得到幾個可能的參數: 枓的種類:角櫨枓(方圓)、櫨枓(方圓)、散枓、交互枓、齊心枓、平盤枓 幾等材(U) 斗的長寬高:可從枓的種類求得 欹䫜的深度:可從枓的種類求得  包耳與開口的尺寸 :可從枓的種類求得,但開口寬為固定一栔(栱或枋寬) 底部尺寸:可從枓的種類求得  附註 我在翻閱營造法式相關文獻時發現有對包耳功用的討論,有相關文獻指出可能是對斗耳的拉結加固,然而相關論文我目前上無法取得,不過的確是有趣的論點。   轉換成 Geometry Node 枓的模型會以 Geometry Node 來生成,為了介面方便會使用客製化的 Node。 Node 輸入輸出與屬性(Property) 這個 Node 有屬性,主要是因為沒有想要透過輸入的方式修改枓的類別,另外使用屬性儲存類別,可以依照條件顯示輸入輸出的 Port 和屬性,在此會來開關顯示選項。 輸入: Unit(cm)          : Float (單位公分) Quality Level     : UInt Has Joinery       : Boolean (不勾選則不開榫) 輸出: 枓     ...