日々適当

やや古い話ですけど、Blender 3.6がベータになり、4.0がアルファになりました。

3.6の目玉としてはGometery NodesにSimulationノードが加わったってものですけど、普段使いで個人的には、UVの機能向上がありがたいかもしれないと思ってます。
UV Packingがアップグレードされて、UVアイランドの形状を正確な形状で取り扱うことでより効率的にパッキングされるようになったとか、UV上で重なってる同一形状のUVアイランドは重なったまま再配置してくれるとか。挙動がちょっと怪しい部分もあるけど、そこはベータ版ということですな。

球や円柱でUV展開するオプションは3.5に続いて手を加えられていて、Seamを切り口として考慮してくれるようになりました.。

ちなみにこの辺の投影で展開する時のSoftimageの考え方がとても好きでした。投影でマッピングするとその投影の基準となるガイドオブジェクトが生成されコマンドが適用されたオブジェクトの子どもとして配置され、そのガイドオブジェクトを動かせば投影の向きや位置をあとからでも調整可能なんすよね。これが便利だった。AutodeskはLightwaveを解放したVizrtを見習い、しかるべきところにSoftimageを譲渡・売却してくれませんかね（買い手がいるのかわからんけど。時間が経ちすぎててもう無理だろというのも想像つくけど）。

Blenderの親子関係構築時に、3.2あたりからParent Inverser Matrixに逆行列を保持せずに親子関係を構築する、つまりトランスフォームパネルに表示される値が親の座標系基準で表示された状態になる機能が付加されましたけど、親だけを動かして子供はその場にとどまり続ける動かし方をした時、Parent Inverser Matrixに値が入ってしまうのかぁ、というのが今日の発見。

いや、最近、オブジェクトのセンターだけを動かす方法を知りまして、それは3Dビューの右上にあるOptionからTransfrom Affect OnlyをOriginsにするってのが方法の一つなのだけど、そこにParentがあったのでそれをオンにして親階層を動かしてみたところ、子供の位置を数値で判断できなくなるじゃねぇかって思った次第です。

ちなみにそれ以外に最近知ったこととして、カメラの切り替えがOutlinerから出来たんだ、ってことです。今更かよって感じですねw

Lightwave 3Dはバージョンが一桁台後半辺りを触っていたのだけど、Lightwave COREの開発の失敗で他のソフトに行こうと思ってMODOに行って以降、触ってませんでした。とは言えその後もモデラーとレイアウトが別々というツール形態は維持したままバージョン2020までは開発が続いていたものの、開発元のNewTekがそのビデオ技術を求めたVizrt Groupにより2019年に買収されたことで、どうやらその開発チームは解散し、事実上、開発は停止されてしまっていたようです。しかしNewTekはLightwaveを誰かに売るための活動はしていたようで（あるいはそれを求める人との交渉に応じていたようで）Lightwave Disitalに移管することを合意したと発表されたのがつい先日のことでした。

【お知らせ】LightWave 3D NewTek社からLightWave Digitalへ事業譲渡発表 [株式会社ディストーム]

まあだからと言って個人的にLightwaveに戻ることは無いだろうけど、未だ愛好者が多いこのツールのこの顛末は羨ましいなぁと元Softimageユーザは思うわけでね。まあ、Vizrt社としてはLightwaveとその技術も必要としていなかったのに対し、当時のAutodeskはSoftimageはいらないけどその技術は必要としていたという違いかねぇ（そもそもAutodeskが自社の資産を他に売ったって例はあるんかな？）。

Blender 3.5がリリースされて少し経ちましたが、リリースノートを見ていて、おっと思ったもの。

UV Sphere Projection and UV Cylinder Projection now have better handling of UVs at the poles. In addition, you can now specify whether to "Fan" or "Pinch" the UVs.

Reference/Release Notes/3.5/Modeling i[Blender Developer Wik]
Blender使いの人たちはこの仕様をどう思ってどう回避しているんだろうとずっと思っていたのだけどね。

3.4以前と3.5のUV球をSphere Projectionで投影した結果が上図のように違っていて、他のツールが来た人は普通に3.5（下）の結果を期待していたと思うのだけど、3.4以前（上）はこんな結果に。「？？？？？」ってずっと思っていたのがこれで改善です。普通になったって印象だけど改善は改善。

Blender 3.5はApple Siliconを使っているMacユーザにとってはパフォーマンス面の恩恵も受けられるようになってて、

When running on a MacOS device Blender will now use the Metal back-end for the user interface and 3D viewport. Metal provides improved performance, better stability and on par compatibility compared with other platforms.

Reference/Release Notes/3.5/EEVEE [Blender Developer Wiki]
3DビューポートがMetalでの描画を選択できるようになり、上記サイトのベンチマークではMac Studioでのベンチマーク結果が出ているけど、OpenGLと比較して大幅にパフォーマンスが向上していることが見てとれます。これは喜ばしいので、今後は3.5をメインに使っていきます（でもIntel Macだとあまり効果が感じられない可能性が高そうですね）。<追記>自宅MacStudioで3.4と3.5で比較してみたけど、ぐりぐりとビューポートを回しているときに、3.4で15から26fpsで表示されていたシーンが3.5では29から41fpsでたので、なかなか嬉しいパフォーマンスの向上と言えましょう。</追記>

ボリュームデータの汎用フォーマットとして有名なOpenVDBってのがありますけど、Blenderさんはそちらの読み込みに対応しております。
んで、先日Ver.1がリリースされたEmberGenのJangaFXではEmberGenで作ったVDBファイルが配布されております。ってことで、それをBlenderに読み込んでみます。落としたのはCloud Packっての。10種類の雲のVDBファイルが入ったzipファイルをダウンロードできます。

Blenderへの読み込みは簡単で、Add→Volume→Import OpenVDB を実行し、ダウンロードしたvdbファイルを指定するだけです。JangaFXからダウンロードしたvdbファイルの雲は、数百メートルの大きさを持っています。そして読み込まれたままの状態ではマテリアルが適用されておらず、ビューポートをMaterial PreviewやRenderdにしていると何も表示されないのでマテリアルを割り振るわけですが、さて、どうしましょとなります。

こちら [GitHub] に書かれたノードを真似してみました。

そうすっと下図のように割と良さげな結果が出ました。

上のキューブに割り当てたマテリアルは雲のマテリアル内のPrincipled VolueのDensityにつながっている部分になります。なるほど、こんな模様を生み出すものなんすねって感じ。頭いい。
ともあれ、大きい雲はこんな感じで作っていけるのかもしれませんね。下図は落とした10個のvdbを並べたもの。

地域が線で囲われているようなaiファイルの図があったとして、その地域ごとに別の色をつけられるような厚みのある形状を作りたいとします。範囲ごとに厚みにある別オブジェクトになっている状態。
そのaiファイルをBlenderに読み込んだなら、まあ普通にやるなら、読み込んだ時点で各地域は別のカーブオブジェクトとして読み込まれるから、それに面を張って厚みをつければおしまいと思います。
ただし隣り合った地域同士の側面が同ポジに重なって存在するので、その面が見えてくることはない（その地域のみで見せることはない）とするなら、地域全部の一番外側の側面部分だけ残して、内側の見えてこない側面は削除したくなります。それを手動でやるのはかなり地道な作業になることが予想されるわけです。

というわけで、GeometryNodesを試してみました。せっかくなので、カーブを読み込んでからその全部をジオメトリノードで行ってみようと思いました。

こちらIllustratorでsvg保存するときのオプションです。小数点以下の桁数を最大値（7）にしておくのが良さそうです。

Blenderでの各ステップです。
左上：読み込んだカーブ
右上：読み込んだカーブに面をはった
左下：全体の側面を作った
右下：各地域ごとの側面（内側がない）
結果、完成図がこれ↓。

Outlinerでのarea.svgコレクション内が読み込んだカーブです。面を張ってます。Collection3コレクション内が各地域ごとの側面。CollectionコレクションのIsland_Outsideが全体の側面になります。試行錯誤して作っていたせいでこんな風になっているけど、今考えるとCollection3内の各地域ごとの側面がメッシュになっちゃってますが、その必要はなかったなと。Curveのままでもいけたかなと思ってます…（ってか行けます）

それぞれのノードツリーは以下です。

カーブに面をはってます。

全体の側面です。

各地域の側面です。

カーブに面を貼るのは個人的にはおなじみなので割愛。
全体の側面は、area.svgコレクション内のものを取得してマージして一つにした後、その輪郭線のみを取り出し、それを押し出してます。
各地域の側面は、このツリーではカーブに面を張ったやつを複製してメッシュ化したやつに対してGeometryNodesを適用してます。全体の側面と同様に輪郭線を取り出して押し出したものの各フェイスから、全体の側面メッシュ上の一番近い位置までの距離を出し、その距離が一定の距離以上のやつを削除してます。全体の側面と同じところにある面しか残さないって考え方ですね。
カーブから作成する場合は、Curve to Meshノードを挟んでからExtrude Meshノードに繋げばいいので、手順としてはそちらの方が遥かに楽、なはず。

結果として工程が3つに分離しちゃっているわけですが、これを一つでできるようにするには（カーブに適用したら完成とするには）どうしたもんか。いらない側面を消すのをどうやったらいいのかなーというところです。

BlenderのシェーダーにGlassってあってそれ使うのが簡単そうです。でも、デフォルトはPrincipled BSDFでありマニュアルによるとPBRはディズニーのprincipled modelに基づいててRendermanやUEなどと互換性があるとか書かれている以上、こっちを使った方が応用が効く？みたいに思った時、どうパラメータを設定すべきかというお話です。

BaseColorは1付近、Transmissionを1.0にして透明に、Roughnessは小さめの値、Transmission Roughnessはガラス内部で散乱させるなら値を持たせる、IORは1.5あたりってことになるようです。BaseColorについては透明なガラスについてはその通りで、色をつけらければそこを変えてやるってことになるのでしょう。

というわけで色ガラスにしたい時、BaseColorの色を変えるだけでそうなるような印象を持ち、Glassシェーダーと似たような結果を得ました。
と思ったのだけど、

そう単純じゃなく、この角度から見ると反射成分かね、それの乗り方に差があるように見えますな。この辺は好みってことになるのかどうなのか。でもPrincipled BSDFの方が印象はいいでしょうか？

Blenderでスカルプトやろうとするじゃん。しかしAppleの変換はスカルプとって変換してくださいますな。スカルプってなんだ？
もとい、で、キーマッピングをIndustry Compatibleにしていると、ネット上の情報を見ていて「？」ってなることも多いわけです。なので、忘れんようメモを残すのです。

ショートカットまわり

マスクが描画されないよ？って時。ビューポートの表示の設定を確認。探しちゃいましたよ。

キーマップをBlenderにしているとショートカットEでストロークの種類を選ぶコンテクストメニューが出るのだけど、Industry Compatibleには残念ながらその設定はされてません。これはキーマップを自分でカスタマイズするのでないなら残念ながらヘッダーやツールプロパティから選択ということになりますか。（Industry Compatibleにしてるとこれ系が多くて、Blender標準キーマップで説明されているチュートリアルとか見て困ることの筆頭かもしれない）

ストロークでCurveを選んだ時、カーブのポイントの追加はControlキーを押しながらクリック（ドラッグ）っすな。

メッシュの細分化という部分でMultiresolutionモディファイヤも大切そうです。

って感じで、本当の基本の部分の知識をおぼえながらやっていくわけっすが、スカルプトについてはかなり職人技ってことになっていくから練習あるのみってところで積極的に触っていかねばなりません。スカルプトといえばZBrushであり何気にライセンスも（MAXONに買収される前のを）持っているとはいえ、とりあえずはBlenderで頑張っていきたい。世の中Blenderだけで見事なモデルを作り上げている人がいっぱいいるし、そこまでいかずともちょっとした物を作成するときに、その他3D作業をしているのと同じツールの中で触っていけるというのはそれなりに便利なことだと思うので。

とりあえずそんなわけで、塗り塗りしてマスターして行きたいなと思う今日この頃。

BlenderのFBX書き出しメニューの中にAnimationに関する設定があります。

Bake Animation, Key All Bones, NLA Strips, All Actions, Force Start/End Keying ってチェックボックスがありますな。Bake Animation以外はBake Animationをオンにすることで生きてきます。他の環境に持っていく際、Bake Animationするのは割と普通のことと思います。ということで、それにより有効になるオプションについてお勉強。

NLAはノンリニアアニメーション。アニメーションの動きの要素をタイムラインに並べてそれを繋ぐことで一つのアニメーションを作っていくって考え方ですかね。、例えば「歩く」ってモーションと「走る」ってモーションがあった時、それらをアクションって形で保持します。
書き出しオプションのAll ActionsはそのアクションをFBXに持たせるもの。以下の例はRotX, RotYっていう名前のアクションを作成して書き出したもの。All Actionsをオンにして書き出したFBXは下記画像左のようにアクションを保持してます。オフにして書き出したものが右。

書き出したfbxをFBX Review[App Store]で開いた

ノンリニアアニメーションは、それらアクションをNLAエディタのタイムラインに並べ、互いをトランジションストリップで繋ぐと、あるアクションの動きから別のアクションの動きへの遷移が滑らかな一本のアニメーションが出来上がります。NLAエディタのタイムラインに配置されたアクションはストリップという状態になってます。
書き出しオプションのNLA Stripsは各ストリップごとにFBXに書き出してくれます。

上図は先のアクション（RotX, RotY）をノンリニアアニメーションのタイムラインに並べてトランジションストリップで繋いだもの。アクションRotAをストリップStripAとして配置し再生時間を少し短くしています。アクションRotYはストリップStripBです。

FBXの出力オプションでNLA Stripsだけにチェックを入れたFBXがこんな感じ。
ストリップ名がリストアップされています。つまりはNLAエディタ上の各ストリップごとに情報が保持されているようです。

この二つはFBXの使用用途で必要ないなら積極的にオフにするべきと思ってます。っていうかそんな事態に先日陥りましてね、外部からもらったあるシーンを他のソフトに持っていくためにFBXで書き出す依頼を受けて、何も考えずBake Animationのオプションを全部オンにして書き出し処理を実行したら、いつまで経っても処理が終わらないわけです。メモリ使用量も恐ろしい勢いで増えていきまして100GB以上のメモリ消費量とかになりやがりまして（これはIntel Mac版のバグのような気もするけど）。でも、ActionとNLA Stripsの出力をオフにしたら割とスルッと出力されました。

ちゃんとオプションの意味を理解して設定しないといけないなという当たり前のことを思った次第です。

しましま作りたかったので、そのメモ。

UVのU方向の値を参考にしてサインでぐにゃっと。
とかやりつつ、まだよくわかってない…