HDAを駆使したプロシージャルワークフロー のスケーリングについて Houdini夜会2024 Vol 1 @TrsNium 1

自己紹介 @TrsNium/@TrsVrc 普段は事業会社でソフトウェアエンジニアをしている Houdiniとの出会い ● 2021年ごろa_saitoさんのハードサーフェースモ デリングに感動し、趣味として開始。 ● 最近は背景全般の自動生成にお熱。 2

HDAについて 社寺建築 街並み生成 アジェンダ 01 03 04 街並み生成 HDAをスケールさせる方法 02 3

HDAについて 01 4

HDAについて 01 HDAとは? Houdini Digital Assetsの略 Houdiniで作成されたパラメータ化されたノードやネッ トワークをパッケージ化し、再利用可能なアセットと して保存する機能。これにより、複雑な操作やエフェ クトを簡単な操作で再現できる「ブラックボックス」 として機能する。 HDAを製作チームや他のプロジェクトで共有・再利用 することで作業効率や品質の向上をさせることができ る。 Houdiniでの作業 ノード/ネットワーク作成 パッケージ 化 再利用可能なアセット 複雑な操作の再現 ブラックボックスとしての利用 HDAとして保存 HDAとして保存 簡単な操作で 5

HDAについて 01 HDAとは? 処理のブラックボックス化 6

HDAについて 01 HDAとは? 他にも色々な機能が... ● HDAのバージョン管理 ● Embedded Asset Files ● Python Viewer State ● Scripts 7

HDAについて 01 HDA機能: バージョン管理 バージョン番号 ● 各HDAには固有のバージョン番号が付与され、HDAの更新ごとにインクリメント 変更履歴の保存 ● すべての変更には履歴が記録され、いつでも確認可能 ロールバック ● 以前のバージョンへ巻き戻すことが可能 8

HDAについて 01 HDA機能: Embedded Asset Files HDA内に関連ファイルを埋め込める機能 HDAは、関連するすべてのファイルを内包するため、移動や共有が容易になる HDA テクスチャ 3Dモデル etc 9

HDAについて 01 HDA機能: Python Viewer State Python Viewer Stateは、カスタマイズ可能なインタフェース。ユーザーがインタラク ティブに3Dビューポート内のオブジェクトと対話する方法を提供する。 身近なノードだとDrawcurve SOPなどで使用されている 10

HDAについて 01 HDA機能: Scripts Scriptsは、HDA内で利用されるスクリプト群。これらのスクリプトは、HDAの振る舞いをカ スタマイズし、よりダイナミックでインタラクティブなアセットを作成するために使用され る 例 イベント駆動 ● 特定のイベント（例えば、パラメータの変更やボタンをクリックした際に）に自動的に 実行される ユーザー定義の操作 ● HDA使用者が特定の操作を行った際にカスタムロジックを実行される 11

HDAをスケールさせる方法 02 12

HDAをスケールさせる方法 02 スケールしている状態とは 効率性 ● 複数のシナリオや条件に対応するために、異なるアセットを一から作成する必要がなく なる 柔軟性 ● プロジェクトの要件が変化しても、HDAを調整することで迅速に対応できる 再利用性 ● 一度作成したHDAは、異なるプロジェクトやシーンで再利用し、カスタマイズすること が容易 13

HDAをスケールさせる方法 02 HDAを使えば何にでもスケールするのか？ HDAは、幅広い用途での再利用性とカスタマイズ性を提供するが"万能"というわけではない スケールするさせるためには、「明確な要件の整備」と「適切な設計」が必要 14

HDAについて 02 明確な要件の整備 スコープの定義 HDAの適用範囲と目指す成果を事前に定義する。何を達成したいのか、どのような問題を解 決しようとしているのかについての明確にする。 15

HDAについて 02 適切な設計 明確な目的 HDAを開発する前に、その目的を明確に定義する。一つのHDAで全てを解決しようとするの ではなく、特定の問題を解決するために設計することが重要。 柔軟性と制約のバランス HDAは非常に柔軟ですが、その柔軟性を維持しつつも、プロジェクトの範囲や要件に合った 制約を設けることが重要。 パフォーマンス考慮 大規模なシーンや複雑なプロシージャル操作を扱う場合、パフォーマンスと計算コストを考 慮に入れる必要がある。適切な最適化が施されていないHDAは、期待する効率を発揮しない 可能性がある。 16

社寺建築 03 17

社寺建築 03 コンセプト 日本の社寺建築をプロシージャルにモデ リングする。柱、屋根、床のHDAの組み 合わせで見た目を制御する。 それぞれのHDAには、細かい見た目を調 整するためのパラメータが複数ある。 18

社寺建築 03 コンセプト 既存の建築物の模倣だけではなく、様々 な形状を生成できるような設計にしてい る。 19

社寺建築 03 要件 日本の社寺建築の再現性 文化的特徴を反映した日本の社寺建築を再現。 床面（Grid）ベースの形状生成 床面（Grid）を基盤として、全ての建築要素が生成されることを保証。 形状制御の柔軟性 作業者がノードの組換えを通じて、建築物の形状を自由に調整可能。 パラメータベースの意匠制御 細部の意匠や装飾を、パラメータを通じて細かく制御可能。 20

社寺建築 03 設計 意匠ごとにHDAを作成する 各意匠要素（屋根、柱、床）に対して個別のHDAを作成し、再利用性と管理の容易さを確 保。 HDAのInputとOutputを決める 各HDAの入力（Input）と出力（Output）を事前に定義し、HDA間の互換性と組み合わせや すさを向上。 形状制御の柔軟性 HDAの組み合わせだけでは再現が難しい形状を、パラメータを通じてインタラクティブに調 整可能に設計。 21

社寺建築 03 設計: 意匠ごとにHDAを作成する(意匠用HDA) 柱 (Columns) HDA 様々な高さ、太さ、スタイルの柱を生成 伝統的な日本建築に見られる柱のデザインをパラメータ化 屋根 (Roofs) HDA 異なる傾斜、形状、屋根の種類をサポート 屋根の端や隅の細かい意匠もパラメータで調整可能 床 (Floors) HDA 広範囲にわたる床面のレイアウトと床下の柱の生成 22

社寺建築 03 設計: 意匠ごとにHDAを作成する(形状コントロール用HDA) ベーストポロジー生成 (Base Topology Generation) HDA プロジェクトのスタートポイントとして機能。 トポロジーマージ (Topology Merge) HDA 複数のトポロジー要素を組み合わせ、一つの連続した構造体を作成。 異なる意匠要素（柱、屋根、床）の統合を可能にする トポロジーアライン (Topology Align) HDA 構造要素の位置合わせと整列を行う 23

社寺建築 03 設計: HDAのInputとOutputを決める Input Output ポリゴン 建築物の基本形状や構造を定義す る多角形データ。 前段階のHDAからの出力と新たに 生成されたデータを組み合わせて 利用。 HDAによる処理後、前段階の形状に新たな 形状を加えた結果。 トポロジー 建築物の構造的な骨組みや配置を 示す情報。 HDAごとの処理結果に応じて更新 され、処理履歴を記録。 HDAの処理を反映した新しいトポロジー データ。以前の処理履歴も含む。 地形情報 柱の配置や高さの調整など、地形 に適応した設計のために利用。 Inputと同じものをそのまま返す。 24

社寺建築 03 設計: 形状制御の柔軟性 パラメーターを元にどの部分に柱 や床を構築するかをトポロジーの 情報をもとに生成することができ る。 ボタンはHDA Scriptsで書くことに より入力のトポロジーにより動的 に値が変わる。 25

社寺建築 03 HDAのスケーラビリティと柔軟性の課題 プロシージャル社寺建築プロジェクトにおける現在の課題は、 HDA内のノード数の増加とそれに伴う密結合の問題にある。こ れらの課題は、新たな意匠の追加や既存の設計の変更を困難に している。 ノード数の増加 HDAの複雑性が増すにつれて、管理や理解が難しくなる。 ノード間の依存関係が増加し、一つの変更が多くのノードに影 響を及ぼす可能性がある。 密結合の構造 ノード間が密接に連携しており、一部の仕様変更がプロジェク ト全体に波及しやすい。 新しい機能や意匠の追加が困難になり、プロジェクトの拡張性 が損なわれる。 26

社寺建築 03 密結合vs疎結合 密結合の課題 変更の難しさ: 一箇所の変更が多くのノードに影響を及ぼし、更新が困難に。 テストの複雑化: 密結合したノードは、機能単体でのテストが難しくなる。 疎結合にすることのメリット 変更の容易さ: 個別のHDAを独立して更新可能になり、全体の柔軟性が高くなる。 テストの簡素化: 疎結合により、機能単独でテストしやすくなる。 27

街並み生成 04 28

街並み生成 04 コンセプト 様々な年代の日本家屋をプロシージャルに モデリングする。ランダムシードなどを用 いることで大量に異なる形状を生成できる ようにする。 29

街並み生成 04 コンセプト 家単体ではなく街に出来るように、様々な 異なる細かい意匠を取り入れられるように している。 30

街並み生成 04 要件 汎用性 敷地の形状から様々な家を生成できる汎用性の高いHDAの構築 拡張性 新しい意匠や機能を容易に追加できるHDAの設計 メンテナンス性 HDAのメンテナンスや更新を容易に行えるようにする 31

街並み生成 04 設計: 汎用性 汎用性を実現するための設計は、プロジェクトの柔軟性と再利用性を最大化することを目的 とする。以下はHDAを設計する際に汎用性を確保するためにとったアプローチ。 1. モジュール化 目的: 再利用可能なコンポーネントの作成 実装: 建築の主要構造（ドメイン）と細部（サブドメイン）を独立したモジュールとして設 計。各モジュールは、単独で機能するようにパラメータ化され、異なるプロジェクトやシナ リオに再利用可能に。 2. インタフェースの抽象化 目的: 疎結合を実現し、コンポーネント間の依存関係を最小限にする。 実装: 各HDA間でのデータやコントロールの流れを管理するために、抽象的なインタフェー スを定義。これにより、特定のドメインやサブドメインの変更が他のコンポーネントに影響 を及ぼすことなく、柔軟な再構成や拡張が可能に。 32

街並み生成 04 詳細: 汎用性(モジュール化) 建築要素を大分類から小分類へと細かく分けHDA化していく 家 真壁 壁 屋根 大壁 ドア 窓 室外機 下見板張 簓子下見板張 ノーマル 引戸 押戸 雨戸 屋根 柵 雨樋 瓦 軒先 33

街並み生成 04 詳細: 汎用性(モジュール化) 約90個のHDAに建築要素を細分化。 HDAの組み合わせとパラメーターにより見た目を調整でき るように。 34

街並み生成 04 詳細: 汎用性(インタフェースの抽象化) 90個のHDAを扱うのは大変なため、抽象的なレイヤーを導入する。 例えばドアインターフェースは、引戸や押戸などのポリゴンにした い意匠をパラメーターインターフェースから選択することができ る。 35 壁 ドア 押戸 インター フェース 引戸

街並み生成 04 詳細: 汎用性(インタフェースの抽象化) 壁 ドア 引戸 押戸 インターフェースを抽象化するためにInputとOutputで、ポリゴン、 グループ、アトリビュートで何を入出力するのかを決める。 以下はドアの例 Input Output ポリゴン 頂点が数4のポリゴン ドアの形状 グループ どこに処理を適用する か決めるためののグ ループ 処理済みであることを示すグ ループ、マテリアルアサイン用 のグループ アトリ ビュート uv 36 インター フェース

街並み生成 04 設計: 拡張性 拡張性は、将来的に新しい機能や要素を追加できる能力だと考えた。HDAを動的に編集され るようにし、拡張性を確保できるようにした。以下はHDAを設計する際に拡張性を確保する ためにとったアプローチ。 1. HDA Scriptの活用 目的: 新しいHDAの統合を自動化し、開発プロセスを加速する 実装: HDA Scriptsを用いて、新しいコンポーネントの追加やシステムの拡張を容易にする。 自動化することにより、効率的な開発を実現している。 37

街並み生成 04 詳細: 拡張性(HDA Scriptの活用) HDAに特定のPrefixを設定することにより自動的にHDAがインターフェースHDAに配置され るようにした JPH_WALL_DETAIL_DOOR_ASSIGNOR JPH_WALL_DETAIL_DOOR_SHAPE_HINGED JPH_WALL_DETAIL_DOOR_SHAPE_SLIDING ドアの形状生成用HDA JPH_WALL_DETAIL_DOOR_UTIL_NORMAL_ROOF JPH_WALL_DETAIL_DOOR_UTIL_TENT_ROOF 屋根などの生成用HDA ドアを生成するインターフェースHDA 38

街並み生成 04 詳細: 拡張性(HDA Scriptの活用) HDA ScriptのEventHandlerを使い動的にHDAを拡張出来るようにする HDA作成時に以下の内容のPython Scriptを実行する 1. インターフェースHDAのAllow Edit of Contentsをする 2. 特定のPrefixを持つHDAをインターフェースHDA内に配置する 3. インターフェースHDAに配置したHDAのパラメータをコピーし、expressionを設定する 4. インターフェースHDA内部にある適用範囲を絞るためのSplit Sopなどにexpressionを 設定する 39 インターフェースHDA HDA作成 インターフェースHDA ALLOW EDIT 2.配置で きるHDA を検索、 HDAを配 置 3.パラ メータイ ンタ フェース を編集 4.イン ター フェース HDAの内 部的な設 定をする

街並み生成 04 詳細: 拡張性(HDA Scriptの活用) 1. インターフェースHDAのAllow Edit of Contentsをする Allow Edit of Contentsをしない場合、 HDA内にノードを配置したりパラメー ターインタフェースを編集できないた め、この方法を取っている。 Allow Edit of Contentsをすることのデメ リットは、本質的な変更をしたのかが判 断しずらい。 40 node = kwargs['node'] node.allowEditingOfContents()

街並み生成 04 詳細: 拡張性(HDA Scriptの活用) 2. 特定のPrefixを持つHDAをインターフェースHDA内に配置する nodeTypeCategories APIを使うことによ り、使用可能なノード一覧を取得するこ とができる。 取得したノードの名前から、prefixで配置 するノードを絞り込み配置する。 41 def getNodeTypes(): # Get the list of available node categories node_categories = hou.nodeTypeCategories() # Loop through each category and get the node types all_node_types = [] for category in node_categories.values(): node_types = category.nodeTypes().values() all_node_types.extend(node_types) return all_node_types def getDoorPreprocessorNodeTypeNames(): shape_nodes_type_names = [] for node_type in getNodeTypes(): name = node_type.name().lower() if "jph_wall_detail_door_preprocessor" in name: shape_nodes_type_names.append(node_type.name()) return shape_nodes_type_names

街並み生成 04 詳細: 拡張性(HDA Scriptの活用) 3. インターフェースHDAに配置したHDAのパラメータをコピーし、expressionを設 定する 配置したHDAのパラメータテンプレートグループからパラメータを取得する。 パラメータをそのままコピーしインターフェースHDAにパラメーターを追加した場合、 パラメータ名が衝突する可能性があるので、Prefixにノード名を追加しコピーする。 最後に配置したHDAとインターフェースHDAのパラメータ間に参照もしくはexpression を設定する。for_each内に配置したHDAはexpressionで設定。それ以外は参照で値を取 得するようにしている。 ※ コードが長く張り付けられないので、ブログの部分を参照してください (https://blog.trsnium.net/dynamic%E3%81%AAhda%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%9 9%E3%82%8B%E6%96%B9%E6%B3%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-682b37 625a62) 42

街並み生成 04 詳細: 拡張性(HDA Scriptの活用) 4. インターフェースHDA内部にある適用範囲を絞るためのSplit Sopなどに expressionを設定する 43 どこのメッシュグループに対して、処理 をするかを決めるためにパラメーターを 作り、エクスプレッションを設定する。 wall_base_split = hou.node(node.path()+"/WALL_BASE_SPLIT") wall_base_split.parm("group").set('`chs("../wall_base_group")`',langua ge=hou.exprLanguage.Hscript)

街並み生成 04 設計: メンテナンス性 メンテナンス性は、システムが時間の経過とともに効率的に更新、改善、拡張できることだ と考えた。メンテナンス性を高くすることで長期的な開発を効率よくできる。以下はメンテ ナンス性を向上させるためにとったアプローチ。 1. ドキュメンテーション 目的: 構造と機能を容易に理解できるようにする。 実装: 各HDAの出力するグループとアトリビュートなどを明確にしたドキュメントを整備。 2. 疎結合のアーキテクチャ 目的: システムの各部分が独立していることで、個別の更新や改善を容易にする。 実装: インターフェースと抽象化を利用し、コンポーネント間の依存性を最小化。 44

街並み生成 04 詳細: メンテナンス性(ドキュメンテーション) ドキュメントなしでも管理できるHDAの数だが、今後数が増えても対応できるようにド キュメントを整えている。Notionのデータベース上にHDAごとにアイテムを作り内容を記 述していっている。 45

街並み生成 04 今後の展望 1. PDGを用いたワークフローの並列化 現状For EachブロックにFeed Back Loopを使っているため、Compileブロックを使った並列 化ができない。1つの家を生成するのに最大3,4分程度かかるため、大量の家を生成するため の並列化のフローを整えたい。 2. マテリアルのベイクフロー 一個一個のGroupにマテリアルをアサインし、ベイクするのに時間がかかってしまう。マテ リアルをアサインするためのHDAの整備をしたい。また、Mantraでのベイクはできている が、GPUでのベイクフローが整っていないので、GPUベースでのベイクをできるようにした い。 46

まとめ 47

まとめ HDAをスケールさせるためには、要件の整備と設計が大事。 社寺建築プロジェクトでは、1つのHDAに大量のノードが含まれているために密結合にな り、メンテナンス性や拡張性が損なわれていることがわかった。 街並み生成プロジェクトでは、設計の段階で意匠を細分化しHDA化することにより、疎結合 にすることができた。また、HDA Scriptsを用い動的にHDAを変更することで拡張性を向上 させた。社寺建築で問題になっていた、メンテナンス性や拡張性などの問題は払拭すること ができた。 48

49