Grasshopperの可読性を高めるには
大規模な建物の3Dモデリング検討にはそれなりの工数がかかるため、複数人でモデリングを進める必要が生じます。自分の参加しているプロジェクトではElefrontの利用を前提に、数多くのGrasshopperファイルがプロシージャルなモデリングのフローとともに管理されています。
Elefrontについて#3 -Elefrontを用いた場合のワークフロー
チームでの作業中、他の人が書いたGrasshopperを読むシーンがよくあります。中身を読まず常に完璧なアウトプットを得られれば理想的ですが、実際にはコードレビューやデバッグ、機能変更など内容を理解する場面がよくあります。
しかし、コンポーネントが散らかっていたり、規模が大きく複雑になればなるほど、挙動を読み解くことは難しくなり、潜在的なミスも増えます。そのため、Grasshopperを書く段階であらかじめ「可読性」を意識することが重要になってきます。
読みやすいGrasshopperは、チームでの協働をよりスムーズにし、ミスを減らし、生産性を高めます。さらには、読む側だけでなく書く側の考えを整理し、よりシンプルで軽いGrasshopperを書くことにもつながります。
今回は社内で利用する、ある程度規模の大きいGrasshopperを書くシーンを想定し、可読性を高めるためのプラクティスをいくつか紹介します。
（本記事の目的はルールを設定するものではなく、これらのプラクティスを通してチーム作業を円滑にする意識を共有することにあります）
構成が明快なレイアウト
読みやすいGrasshopperのためには、まず全体構成をわかりやすくする必要があります。Grasshopperは視覚的にオブジェクトをつないで直感的にプログラミングができるVPLの一種ですが、なまじ自由度が高いために上手く整理されていないと煩雑で難解になり、文字通りのスパゲティコードが出来上がります。
こちらは地獄のGrasshopperです。
どこから読めばいいのかわかりません。ただモデリングを進めたい場合にもどこを触れば動くのか、どこにインプット・アウトプットがあるのかすらわかりません。製作者にとっては手に馴染んだ使いやすいツールでも、読む側の苦労は計り知れません。
こちらは、先ほどのファイルを整理したものです。複雑ですが、全体の構成や流れがなんとなく推測できたり、触るべき場所が整理されて余計なエラーを起こさない操作が可能になっています。
このように、引いて見た時に、ざっくり全体の構成と部分ごとの関係が推測できるようなキャンバス上のレイアウトにすることが理想です。
また、Grasshopperのインタフェースはある程度縮小するとコンポーネントのアイコンや名前が消える仕様のため、縮小したときの見え方は重要です。
あまり大規模化するようなら、一度Rhinoモデルに出力してファイルを分割するのも手です。
操作系をまとめる
入力になるコンポーネントやスライダー、Bake用ボタン、結果のプレビュー用オブジェクト、パラメータを入れるパネル等、短期・長期的に触る可能性のあるものを左端の一か所にまとめます。
中身を読まなくともGrasshopperを使う目的を達成できるような、単純化された操作系にすることが理想です。これにより作業を効率化できます。インプットをまとめることは操作系と処理系を分けて整理したり（関心の分離）、パラメータを常にコントロールしやすい状態にしておくことで、将来的な拡張可能性を高めることにもつながります。
データの内容を可視化する
データのやりとりには要所要所で特定のデータ型のパラメータオブジェクトを利用し、処理の途中でどのようなデータが流れているのかを明示します。想定と異なる型のデータが入力された際に前もって弾いておく役割もあります。
また、RelayやDataオブジェクトに名前をつけて意味をもたせるのも有効です。
モジュール化
明確なインプット端子とアウトプット端子を持ったモジュール同士の接続でGrasshopper全体が構成されているという考えです。コンポーネント整理のために多少の手間がかかりますが、今後読解にかかる時間を大幅に短縮できます。
（ここでやっていることはモジュール化というよりグループ化ですが、入出力をもったまとまりということを意識するため、ここではそう呼んでいます）
実際、大規模なGrasshopperを分析すると、部分機能の集合になっていることがわかります。意味を把握できる程度の大きさに分割します。
簡単なモジュールの一例です。目的をもった処理のまとまりをグルーピングし、名前をつけます。各モジュールには入出力があり、途中で外とのやりとりが発生しないようにパラメータオブジェクトなどでまとめます。
こうすることで、読解の際に読むべき箇所を減らし、インプットとアウトプットの差から処理の内容を推測することができます。中身をすべて理解しなくとも全体の大まかな挙動を推測でき、Grasshopperファイルのユースケース別に応じた段階的な理解度を設定することができます。
また、エラーが起きた際、コンポーネントのまとまりがなくバラバラに散らばっていると、１つ１つコンポーネントを確認することになるため原因の特定に時間がかかったり、修正内容がどこまで影響するのかを把握することが難しくなります。これではバグ修正が新しいバグを生む可能性があります。
モジュール化がなされているとエラーの原因究明が素早くでき、かつ他の部位に及ぼす影響を把握しつつ安全に修正することができます。
勿論、クラスターを利用することで同様のことができます。キャンバス上のスペースをより圧縮できますが、ブラックボックス化するためコピペして使うもの以外では自分はあまり使いません…
以上、普段チーム作業で実践していることの紹介でした。
他にも、コメントやクレジットをつけるなど考えられますね。
以下のページも参考になります