目次
はじめに
先日RhinoInside for Revitのベータ版がリリースされましたね。
この記事では今回のベータ版の見過ごせないアップデートと、RhinoInsideの可能性について、思ったことを書きます。
今回のβ版のアップデートではオブジェクトトラッキング機能が付いたとありますが、そのインパクトたるや凄まじく、
それによってもたらされたRhino、Revit間でのデータのハンドリングの良さには目を見張るものがあります。
ハッキリと言えば今までのRhino.Insideとベータ版では雲泥の差があります。
この柔軟な適応能力とスピードが今後のRevit とRhinocerosをデザイナーツールへと押し上げる可能性を感じました。
それでは、まずは私が何を試し、何に躓き、どこに可能性を感じたかを今後の章で明らかにしていきます。
Rhino.inside for Revit のオブジェクト生成機能の改善
今までのRhinoInside for Revit(RIR) では動的にモデルを動かすことが難しかったという事が背景にあります。
なぜならGrasshopperを繋ぎ変えるたびにRecompute(再計算）が走り、重い処理を繰り返し行うからです。
当然、それを防ぐために、Stream Gate を入れたり、部分的にdisableを使用するなどして、
処理が自分の思うタイミングで動くように考えてコンポーネントを配置する必要がありました。
オブジェクトを生成するタイミングでしかスクリプトが走らないようにするために,
ファイルを分けたり、DetaDamを作ったり、様々な工夫を凝らす必要がありました。
例えばファミリを生成し、パラメーターを上書きするといった場合に、
生成のタイミングとパラメーターの上書きのタイミングが前後すると、
思うような結果が得られないというようなこともありました。
それが、今やベータ版では、スクリプトが繋がっていればオブジェクトは存在し、変更が無ければ再計算されないという仕様に変わっています。
それによって処理速度が遥かに向上しました。それによって大幅なハンドリング感の改善が見られたのです。
(追記）コンポーネントを右クリックすると、オプションが選べるようになっていて、再計算されるようにもできる事が分かりました。
詳しくは下の改善点をご参照ください。
又、ファミリ生成のタイミングやパラメーターの上書きのタイミングもスクリプトの上流から下流へと速やかに行われるようになり、
今まで気にしていた、スクリプトの実行順序や、煩雑な手順を全く気にすることなく、Grasshopperスクリプトが書けるようになりました。
今まではこういう直感的な書き方が出来なかったのですね。
上のスクリプトでは角柱ファミリの700ｘ700というタイプを新たに生成して、そのタイプパラメーターを700㎜に変更しています。
SetParameterによるパラメーターの上書きのタイミングと、DuplicateTypeの生成タイミングを気にすることなくこのように書けます。
それって当たり前では？と思うかもしれません。しかし、この改善によってGrasshopperの強みがREVITでも生かせます。
Rhino.inside for Revit （RIR) の改善点
RhinoInside for Revit の主な改善点はこのフォーラムのポストに書いてあります。
主にはエレメントトラッキングについて、詳しく載っていますので、かいつまんで解説します。
エレメントトラッキング
グラスホッパーのコンポーネントはレビットモデル内のエレメントを記憶できるようになりました。
これは、セーブしてファイルを閉じてから、開いても同様に働きます。
グラスホッパーでオブジェクトを新たに作成した場合、それは既存のREVITエレメントを上書きできる場合はそうして、
同じエレメントが2つ存在するようなことを防ぎます。
トラッキングモードの変更
トラッキングモードの変更はグラスホッパーコンポーネントを右クリックすることで可能です。
私の実験結果では、以下が観測されています。
１．Disabled トラッキングモードオフ、毎回計算が走るたびに新しいエレメントを作成し、オブジェクトの重複を許します。
２．Supersede 計算が走るたびに新しいエレメントを再作成します。オブジェクトの重複は許しません。
３．Reconstruct デフォルトでこの設定です。変更を検知すれば既存のエレメントを改変、エレメントが無ければ再作成。エレメントに変更が無ければ計算されません。
OUTPUT・ADDコンポーネントに付与されている追加のオプション
１．Highlight このアウトプットから作成されたREVITエレメントを選択しハイライトします。
２．Unpin このアウトプットから作成されたREVITエレメントのピンを外します。
３．Delete このアウトプットから作成されたREVITエレメントを削除します。
４．Release このアウトプットから作成されたREVITエレメントをトラックしません。注意：オブジェクトの重複がおこる可能性があります。
Rhino.inside for Revit （RIR）の使い方の試行錯誤
まず、私が試したのは、レビットの要素（Element)を通り芯から壁まで一通り全部Rhinocerosを通してGrasshopperで配置しました。
これによって得られる効果は、通り芯の間隔や高さを後で動的にいじれる、といったつまらないものでした。
少なくとも一つ以上の変数をREVITに埋め込んだという事にはなりますが、
これではせっかくのパラメトリックモデリング機能が通り芯や高さの調整にしか使われないというようなことになります。
もちろんREVITですから、モデルの通り芯が動けばそれに追従して各平面、立面、断面図も全て調整される(そのように設計すれば）といった具合ですが、
例えば通り芯を全部500詰めるというようなことが簡単にできるだけで、あまり旨味がありません。
そもそも通り芯の生成はＲＥＶＩＴの機能を使った方が自動でナンバリングしてくれたり色々楽という面もあります。
わざわざ変数を埋め込むだけ損という考え方もあります。
このような使い方では、全く持ってデザイナーの興味をそそらないでしょう。
ここで私の想像力は止まっていました、RIRこのツールは何のために存在するのか？もっと有益な使い方があるのでは？
そこで方向転換をする必要がありました。デザインするツールとしての使い方とはどういったものがあるでしょうか。
Rhino.inside for Revit （RIR)のアルゴリズムを生かした使い方
例えばある一定のアルゴリズムによって自動で建物がが生成されるのはどうでしょうか。
それが可能であれば、例えば見える景色の最適化というようなことがREVITの図面描画能力を生かしたまま可能になるかもしれません。
アルゴリズムを使ってデザイン検討をRevitの上でできるようになるとしたら、
最初に検討すべきスタディさえも、Rhinoceros＋Revit上でやるチョイスが出てくるでしょう。
面積もトラックしたまま形状の操作が可能になるかもしれません。
今まではハンドリングの問題がありましたが、今や前のバージョンより遥かに早くなり、Grasshopperには及びませんが、
それなりに使える速度になっている印象を受けます。(これにはモデルの重さやマシンの性能など色々な要因があるので確かではありませんが）
BIMのメリットである、フロントローディングや、図面描画能力を併せ持ったパラメトリック建築の検討が可能となるのではないかと思います。
もはや通り芯や高さ設定、マッシングなどの前提条件を全て変数にしたままデザインができるツールになっているのではないでしょうか。
これを用いれば、パラメトリックな恣意的な形を目指すだけでなく、
最適な通り芯、最適なコア計画、最適な面積計画等、Rhinoceros とグラスホッパーの得意とする、
3Dを駆使したガチガチの理詰め建築が仕上がるのではないかと思っています。
後は、このツールRIRを使う人の想像力次第で、面白い建築が可能になるのではと思います。
最後に：プログラミング的思考の必要性
これは先ほどの建築ファサード自動生成スクリプトです。
何か気になるところがありませんでしょうか。
そうなのです、繰り返しが多いのですね。
GHは一部のプラグインを除いて、繰り返し処理に弱いのです。
これが例えばC#等のプログラム言語を使えば、もっと簡潔に書ける可能性があります。
特に最後の5回繰り返しを行ってマスを積み重ねている部分は確実に同じ関数をfor文で回すことで書けるはずです。
今や図面さえもスマートに最適化できる可能性があるとすれば、
プログラミングこそが今後の鍵になってくるのではないでしょうか。
建築には未知の世界が広がっているなと感じる今日この頃です。
