Photogrammetry 実録
目的
写実なモデル作りの記録、情報交換が目的
そのために自分の持てる情報を公開
この記事は下書きで、とりあえずキャプチャをため込む記事
まとめは別記事で将来的に。
方法、記法、ルール
キャプチャと感想と生配信を載せる
BD(=Blender), SP(=Substance Painter),MR(=Meshroom)
別のソフトで似た名前のコマンドがあるのでコンベンション
言葉で切り取りすぎると柔軟さに欠けるのでふわっと
> で内部、または次のコマンドを示す(アプリ内の、それの後の)
/ で並列を示す(また、または、とか、とを同時に)
(e.g. SP>A/B という方法で試す= SPのAとかB という方法で試す)
(e.g. BD>Vector MathならSP>Projectionより扱いやすい)
これは記入の手間を省くためで、絶対ではない。
あくまで下書きなので矛盾があってもよい
体裁もほどほどで良いけど、音声入力で手早く。
配信
記録
0203 上手なマスキング方法を見つける>BD
BD>UV project Modifierで投影した画像をUVでマスクして結合できないか捜索している中で、Shader Editor>Vector Math の項目が増えていることに気づいた私。
Blender>VectorMathならUVを投影テクスチャ単位で分けなくてもよさそうだ。
方法を見つけたグラデーションがマスク範囲のコントロールを柔軟にするのでプロジェクトノードを活用することにする。テクスチャーペイントでマスキングをするとかなり動作が重くなるのでなるべく細部に至るまで軽量で半自動的にコントロールできるシェーダーエディターのグラフを活用したい
ほとんど同じ形状のメッシュへベイクしようとして、ブロック状のノイズが生まれた。原因不明。
ベイクする際は非表示にしているはずのModifierからも影響を受けるようなので削除しておく
Emitでベイクした結果とDiffuse>Colorのみでベイクした結果が異なるのはなんでだ。
NodeAのEmitのBake結果
Material OutputにつなげていないPrincipledBSDF>EmissionStrengthを0
World>Background＞Strengthを20=>10
Glow Colorは使っていない
NodeAをPrincipledBSDFを経由してからDiffuse＞BCを抽出した結果
時間は掛かるけれどこちらを使う
0204 上手なマスキング方法を見つける>SP
割とやりたいことがSPでも多く含まれていそういなので試す。
BDと比較して有利
UVの上限が実質無い(BDはUVで投影された画像を管理する)
ブラシ操作による操作の軽さとクリック数の手間が少なそう
(BD>Vertex Paintでmasking は動作が重い)
境界面のぼかしや深さ方向へのぼかしがある
回転、平行移動、拡大は直観的に操作できる
(BDと同程度)
スケール感、比率が分かりにくい
カメラからの投影がない？
Tri-Planar はテクスチャを引き伸ばさない
Planarはテクスチャーを引き伸ばす
Tri-Planarの位置合わせがとても難しいのでPlanarで位置を決定してから変更する
だめだ一つの画像に10分かかる。BDなら5分かからない。
微妙な位置合わせに時間が掛かる。完全な位置合わせ(下地)にはBDを使って、領域の調整やマスキングにはSPを使うのが良いかもしれない。
SP>Fill Layer>Projectionよりも、Layer>Projection>カメラの向きと大きさにstencilを合わせてペタペタする方がやりやすいかも。ただし正確な位置合わせは難しいのでやはり下塗りはBD>UV Projection Modifier with multi UV maps>Merge them within Shader Editor>Bake BC onto the same mesh that has a clean UV unwrapped で完了する方が吉か。
私のカメラの設定はsubstance で言うと fov が58degフォーカルレングスが14mm
画面右手前の明るい部分がSPで補ったテクスチャ
左や奥がBDで完全に位置を合わせて投影したテクスチャ
明るさの違いがカラースペースによるものだと思うのだけれどBD>Bakeの設定にカラープロファイルを埋め込みそうな領域がない。
チョット調べた：ShaderEditorのImagetexture内のカラースペース指定は保存時に影響せず同じトーンの画像が保存される。その保存された画像を、LookDev>Emissionで見たときの印象RenderProperties>ColorManegement>DisplayDevice>sRGBView\Transform>Standardという設定にして保存した画像と、その保存した画像をビューアで見た時の色合いがよく似ている一方で、DisplayDevice>None にして同様にビューアで確認した場合には似ていない
このことから、Color Managementはテクスチャのカラープロファイル埋め込みに影響しない。Node>ImageTextureのカラースペースは表示する際の設定影響しない。一方的にsRGBで保存される
と思ったのだが違った。どうやらBDは画像の保存時にプロファイルを埋め込まないようだ。
ちなみに、exrファイルのカラースペースはほぼほぼscene-linearとのことだ。exrというのはリニアワークフローと呼ばれる方法で業界標準的に用いられている。私は末席にもいないので良く知らなかった。これには白飛びを防いだりより自然なボケやブレを再現できる利点があるそうで、MRから出力される形式を確認していないけど、ノードでの色空間はlinear指定で良いと思う
https://krita-artists.org/t/openexr-color-managed-workflow/24888/4
他JPG,PNGは基本的にsRGBでOKだと思う。つまりRender Propertiesの諸設定と画像の空間指定には問題が無くて、保存時の問題ではないということは分かった。
リニアとガンマ
しかし未だにベイクする際にどの設定を取り込んだら明るさの違いになるのかがよくわからない。
Bake>Emit>with a node directly connected to Material OutputとBake>Diffuse Color>with a Diffuse/Principle BSDF connected to Material Outputって同じ結果を出さないの？
カラーに関しては取り込んだ画像のカラーを変更することで対応
0204 Blender>DisplacementとSP>Normalのベイクダウン結果の比較
未設定
BD>Displacement32f
ローポリのメッシュの境目が強く目立っている
SP>Normal
こちらのほうが自然では。
BD>ProjectUV Midifier で投影する範囲の分割不要な UVを小さく縮小して黒く潰すカメラの部分だけ UV を作る最大8Shader Editor
UVprojection で5つのカメラからUVを分割するとできるUVはとても細かくてSmartUVProjectで分割するのと大差がない。ShaderEditorとSolid＞Render>TextureでUV展開する前に展開状況を見るのが良い。
SP>Projection で投影方向の奥側にまで投影されてしまっている。UVはかぶっていない。SPの設定で変更可能？
BDでのテクスチャプロジェクションはステンシルをカメラにピッタリつけるという手間が掛かって、5分調べたけど固定する方法が見つかりそうになかったのでSPでやる。SPもProjectionで出るステンシルとカメラ越しのモデルとはずれてしまう。しかし割と操作が楽なのでこちらにしたい。
BDでのカメラの抽出を規則的に自動的に出来る方法？
一見平らな面も、水気なんかで微妙なテカリがあって、それもDisplacement(Height)としてMeshから抽出するには相当なディティールが必要になるのでは
下面の白い樹脂部には Describers Type = SIFTかSIFT＋AKAZE＋DPSIFTが良いメッシュを作るようだ。とはいえ 結果予測は相変わらず難しい。5タイプなら5時間で出来る。Desrcivers = low でDesrciber Typeを変えて試すのが良いかもしれない。 PBR トランスペアレントαサブサーフェスを作る必要がある特に半透明の液体の部分ではゼラチン質の場合もクリアコードが必要だこれらのマップは領域を指示する手間がかかる分自動では作れない上で作る手間をこちらで補えれば作成する手間があるからUIはSPが優れているし、早い3時間動画用途であればクアッドにする方が良いUV展開まで1時間撮影からメッシュ生成まで5時間ディフューズマップの作成皿と食べ物ディフェンスをベースカラーに合成基本マップ生成30分ZFmaskingに30分動画から多分EXIFを残してスチールを抽出してくれるFree版のマスク機能は、Exifが抜けた画像しか使用できないためにReconstructされなかった
0207 スカルプトワークフロー
手前のテクスチャはノイズが発生して緻密さも下がっているので下書きでも使いにくい。たまに発生するこの失敗から、最終版としてはSPかBDを利用する
カメラをインポートするときに番号を確認するよりもフォルダ名から別に読み込んだ方が間違いが少なくて済むかも。ただしハイポリは位置合わせのために必要？
読み込むときはフォルダ名でも、暗号めいた名前ではなくて、設定値ををBD内に記入しておくことで後日再検索しなくてすむ
load camera and hi/lo mesh from MR>scale down image/camera>rotate all>adjust position of lo res to hires
UVのバグ
MR>RemeshしたメッシュをBDへインポートするとMR>Texturingでのメッシュから1割縮小していて、向きも変わっている。MR画面では大きさは変わらない。MRのノードに大きさや向きに関わるパラメータはない。向きだけならMDでインポート時に変えられるけれど、大きさも修正となると、回転方向を確認するのも骨だし、手作業が良いか。
BDだとテクスチャを表示させながらのスカルプトが出来そうにない。Zbrushなら可能っぽいので試したけれど、テクスチャがバラバラになっている。BDでUVを確認したところ、Importerから読み込んだHiresのTextureingデータはメッシュに用意されたUVとテクスチャのマッピングが違うようだ。
以前MR>メッシュフィルタリング後にテクスチャリングをした場合とメッシュデシメート/メッシュリサンプリングをかけた後にテクスチャリングをした場合でメッシュが大きく変化した現象があって、特に後者はUVが恐らくめちゃくちゃになっていてテクスチャーもバラバラに貼り付けられていたことがあったんだけれども、それに状況が似ている。
右下がMR>MeshFiltering>Texturing(Unwrap Method =Basic)をImporter経由でBDに読み込んで画像をリロードしたもの。
上2つはMR>MeshDecimate>Texturing(Left: Unwrap Method =Basic, jpg Right:Unwrap Method =ABF, exr)をImporter経由しないで読み込んだ後リロードしたもの。
MR内で以前には逆パターンでDecimate>Texturingが失敗したことがあった。この不安定さからテクスチャではMRを使わずに、SPあるいはBDで元画像を直接ペタペタしようということになったのだけれど、ハイロー双方でテクスチャバグがあるならスカルプトの調整にも使えない。
詳細を調べてみる。
MaterialにはOnjectかDataへのリンクが選べるのだけれど、Onjectへ張られているとFBXへ出力するときに消えたりする。のだけれど今回は関係なさそう。
MR>TexturingされたメッシュをImporterを経由しないでインストール、リロードするとテクスチャがバラバラにならなかった。
どうやらImporterの読み込み時の設定がUVを上手く反映していないようだ。ImporterにUVの調整項目も無いので、こちらからは何もできない。
Importerはカメラと同じ向きのオブジェクトが用意されていて、SfMのABCファイルでは出来ない写真とカメラとの紐づけと視覚化をしてくれていて、この紐づけを使うだけでも価値があるのだけれど、なぜかSfMの初期設定からオブジェクトの位置や大きさも変えてしまう不思議仕様なのである。
いやはやともあれ、カメラの位置はImporterからBDへ読み込み、メッシュやUVやテクスチャはMRから出力されたものを直接読み込み、Importer版のメッシュとMR版のメッシュとで位置を合わせ、正しく張られたテクスチャをもとにしてスカルプトするという流れになりそうだ。
TextureをZbrushで使おうとするとexrでは色とマッピングがおかしくなる。
ZBでのテクスチャがバラバラになっていたのは、UVが上下逆に読み込まれるからのようだ色の違いはマテリアルがかぶっているからだそう。
MR>Texturingから出力したobjモデルがWin>Expolorerで読み込むとエラーで読み込めず、クリスタで読み込んでも何も表示されない。
一方でMR>Meshfiltering/MeshDecimateの出力結果はWin>Explorerですべて表示された。
また、このMR>Texturingで出力したモデルは、上に加えてBDではテクスチャ共に正しく表示される。
上のImporterでのバグも、もしかしたらMR>Texturingによるバグを吸い上げているだけなのかもしれない。つまりImporterは正しく読み取り、MR>Texturing元のメッシュかテクスチャかその両方かが間違っている。
BR>Bake Texture from Texturing onto the mesh A from Mesh Filtering>export A as obj/fbx したものはExpolorer/Clipstudio上で正しく表示された。
また
MR>Texturingのデータを直接ZBに取り込み、テクスチャを貼り付けた後、obj/fbxで出力したものもExpolorer/Clipstudio上で正しく表示された。
どうやら、バグはMR>Texturingから出力したモデルのメッシュデータに含まれているようだ。これを別のメッシュで置き換えたり、BZ上で再出力すると解決する。
ちなみにBDでMR>Texturingのデータをそのままメッシュに置き換えないまま出力すると、fbx/objともにExpolorer/Clipstudiopaintで表示されない。
このことから、以下のWFに更新したい。
ZB: MR>TexturingのHiresメッシュを読み込み/Texture貼り付け/形状整え/ローポリ化/objかfbxで出力でHiresLores共にBDへ
BD1: 上データ読み込み/ Importerでカメラ読み込み/ 位置合わせ/ カメラを含めてfbxで出力してSPへ
SP2: 上データ読み込み/ カメラ越しに写真をステンシルにして塗り絵/ できたマップをロスレス形式で出力してSSへ
SS: 上画像読み込み/ ベースカラー他マップ出力してSPへ
SP2: SP1のセッションで上のマップ読み込み/mesh由来のマップ作製/ ZBで作ったHiresメッシュからHeightマップをベイクダウン/適度にマスクを作ったりして各マップを作製/ マップの出力
BD2: BD1へ上マップ読み込み/ ローポリにマテリアル当てはめ/ レンダーで見栄え確認/ 完成まで以下調整ループ
MR>MeshDecimateしたローポリデータへ焼く手間を省きたいのでZBで直接ローポリにする予定
SPを多用するのはワンステップでのマップベイク機能、保存時の名前自動付与機能、レイヤー構造によるマスキング機能、豊富なプリセットデータといった便利さと、それらをBDと比べて手間を掛けずに実行できるUIデザインの優秀さが理由。
やたらとマップを用意するのはまだどのようなマップを使うのかはっきりしていないので、選択肢を持っておきたいがため。
この記事が気に入ったらサポートをしてみませんか？