前田紀貞の建築家ブログ

アクセスカウンタ

zoom RSS アルゴリズム建築と作家性 (I remember you)

<<   作成日時 : 2008/03/19 20:56   >>

驚いた ブログ気持玉 43 / トラックバック 0 / コメント 0

画像














■プロジェクト:I remember you 画像
http://www.flickr.com/photos/nmaedaatelier/sets/72157622477231441/detail/

今回は、僕たちの新しいプロジェクトの紹介ということで、久々にがっつりと「建築の話」です。

このプロジェクトの敷地は、細長く奥行きがあり形状的には大変に僕ら好みなのですが、ひとつだけ慎重に検討されなければならないことがあったとすれば、それは、敷地周囲が建物(特に南西に17階建てマンション!)にビッチリ包囲されており、通常の横(窓)からの光では部屋が薄暗くなってしまう・・・・、という点でした。
よって、結果それは「上からの開口部(トップライト)」の大々的な採用を意味することとなりました。

そこで、
【1年:春夏秋冬を通じて ・ その各季節の朝〜夕方までの光の総量】
を想定し、
『それが空から最も多く降り注ぐような「上からの開口部(トップライト)」を設ける為の建築物の形』
を模索することに考えが至りました。
わかり易く言えば、運動会の“玉入れ競争”よろしく、空からバケツで光の玉をポロポロ落とし、一番多くその玉が建物に入り込むような「上からの開口(トップライト)」を設けるような建物形状は?という設計方法になります。

今回は、そのような状況の中、17階建てのマンションなどという邪魔物をかわしながらも、この“光の玉入れ競争”で一等賞になる為の方法を考えてみた、そういうことになります。ただ、「一等賞」と言う限りは、光を取り入れる開口部の位置や大きさの配置は、ただの“勘”だけから導かれるだけでは不充分です。つまり、一番になる為の「正確な計算」をしないといけません。
これがアルゴリズムです。

この“光の玉入れ競争”で一等賞になる為の解析を行ってくれたのが、米国 コロンビア大学で教鞭を執る設計・リサーチ集団:PROXY(Toru Hasegawa & Mark Collins)でありました。
PROXY:http://proxyarch.com/

彼等は、この光の総量の解析をMAYA(エイリアス・システムズ社によるハイエンドCGソフトウェア)によって導かれるアルゴリズムによって解析しました。
下の無味乾燥な数式の羅列であるコンピュータープログラム(アルゴリズム)は、“光の玉入れ競争”で一等賞になる為、つまり、このプロジェクトの諸室群を一番明るくする為の開口部の位置と大きさを決定する為の計算式なのです。

以下、そのアルゴリズムの一部を示しますが、実際のものはこの50倍ほどの長さがあります。

//Maya ASCII 8.5 scene
//Name: maeda_study_01.ma
//Last modified: Thu, Jan 31, 2008 04:44:59 PM
//Codeset: 1252
requires maya "8.5";
currentUnit -l centimeter -a degree -t film;
fileInfo "application" "maya";
fileInfo "product" "Maya Unlimited 8.5";
fileInfo "version" "8.5";
fileInfo "cutIdentifier" "200612162224-692032";
fileInfo "osv" "Microsoft Windows Vista (Build 6000)\n";
createNode transform -s -n "persp";
setAttr ".v" no;
setAttr ".t" -type "double3" 152.29884565977292 160.53431739594538 -166.05973052115172 ;
setAttr ".r" -type "double3" 327.26164769603832 138.19999999999467 0 ;
setAttr ".rp" -type "double3" 1.7763568394002505e-015 0 7.1054273576010019e-015 ;
setAttr ".rpt" -type "double3" -1.495304618520351e-015 5.7059193352344001e-015 -1.3488547247972582e-014 ;
createNode camera -s -n "perspShape" -p "persp";
setAttr -k off ".v" no;
setAttr ".fl" 34.999999999999979;
setAttr ".fcp" 10000;
setAttr ".coi" 275.77980726405923;
setAttr ".imn" -type "string" "persp";
setAttr ".den" -type "string" "persp_depth";
setAttr ".man" -type "string" "persp_mask";
setAttr ".tp" -type "double3" -0.23348806700000013 6.7068759563204994 1.1155060949999998 ;
25 0 0 0 0.050000000000000003 0.10000000000000001 0.14999999999999999 0.20000000000000001
0.25 0.29999999999999999 0.34999999999999998 0.40000000000000002 0.45000000000000001
0.5 0.55000000000000004 0.59999999999999998 0.65000000000000002 0.69999999999999996
0.75 0.80000000000000004 0.84999999999999998 0.90000000000000002 0.94999999999999996
1 1 1
6 0 0 0 1 1 1

92
15.150843729963279 -4.8377049465262409e-016 7.1648566476058546
15.065341282123802 -1.4379574922300553e-016 2.2514849285530802
14.979838834284323 1.9617899620661299e-016 -2.6618867904996941
14.894336386444847 5.3615374163623159e-016 -7.5752585095524685
14.956616855270697 0.49273994520756226 7.5796490308596773
15.024998425606311 0.58043617471082121 2.7026828470126709
15.093379995941925 0.66813240421408027 -2.1742833368343355
15.161761566277541 0.75582863371733922 -7.0512495206813419
14.485282604100297 1.4591224834669088 8.3931511734931483
14.831840373514831 1.7414283312792083 3.604996702413287
・・・・・・・・・・・・・・・・・・・・・・・・・・・

さて、次に、今回の具体的な手順を記載してみましょう。

まず下図は、東京の緯度と経度によって決定された太陽の運行のデータです。四季を通じて・一日を通じて移動する太陽光の軌跡をデータとして定義するところから始めます。

画像




















次に、この太陽の軌跡の下に、下図(左)で、敷地周辺に密集する建物群と1年間、朝から夕方までの太陽の軌跡の通り道の合計(絵の丸い屋根のような部分)を設定します。
下図(中)は、この敷地に「光の玉」を、実際にポロポロ落としている様子です。

画像










次の段階で、空から3階の屋根に降ってきた「光の玉」が、そこから更に、できるだけ最下層の1階までずっとずっと深くまで落ちて行ってくれるような方法を考えてみます。そうすれば、下の1階もグンと明るくなりますから。
その際、おおまかに各諸室の光を当てたいポイントの優先順位・優先場所(リビング・ダイニング・寝室・玄関 等)を決めておき、それが縦方向に3層分重層してゆくという構成の中、“光の玉”が最大限一番下の地面のレベルまで落ちるよう計画します。

画像


















そしてここで、下図(右)の4本の紫色の帯(輪)が積み重ねられるような建築の「ルール」を決定します。この「ルール」設定は、アルゴリズムを走らせる為の関数のようなものです。
この「ルール」をどのように決定するか?というところに、アルゴリズムで建築のシステムが規定されていながらも、建築家の作家性の入り込む余地が確保されます。
「今回は、どんな関数(ルール)を採用しようか?」という「選択」にこそ、このプロジェクトだけの創作の個性が出るということなのです。

ちなみに、コンピューターによるアルゴリズムを走らせた結果が出る以前の形態は、手だけに依った下図(左)の模型のような形で進んでいました。
アルゴリズムの結果が出てきてから比較してみますと、相当の点で、光のシミュレーションが不正確、不充分であり狂っていることがわかりました。
ただ、「複数の帯(輪)の重ね合わせによるズレの隙間から光を取り入れることによって発生する空間(空気)」という発想は、最後まで変わることはありません。


画像












さて、アルゴリズムに話を戻します。
上図(右)の赤い部分は、ホットスポットと呼ばれ、“光の玉”が上空から一番バシバシ降ってくるポイント(明るいポイント)を示しています。赤い点で示された【この辺り】が、「上からの光」をキャッチする「トップライト」が設置されることになるであろう場所となります。


ただ、ここで【この辺り】と曖昧なふうに書いたのには理由があります。

上の赤いホットスポットの分布状況をそのままトップライトとして現実化すれば、一目見てわかる通り、「あまりに小さいトップライトが、異常に数多く散在するような建築の形」となってしまい、それは予算的・施工的にはまず不可能な提案となったまま解析が終わってしまいます。
それでは、アルゴリズムなんて、ただの絵に描いた餅に過ぎません。解析の結果が、現実の状況に生かされることが前提でなければ何も意味はありません。
そこで、これを現実の予算状況や施工精度に合うよう、擦り合わせをする必要が出てきます。

この対処法が、以下の図(グラデーション)となる訳です。

画像









上の4種類の図は、左端から右端に行く程、【解像度】が低く設定されてあります。
左端が今回のアルゴリズムの計算結果には最も近いものなのですが、これそのままですと、それは全くコンピューターの事情そのままであり、現実的には施工不能となってしまいます。
よって、このアルゴリズムを現実側に擦り合わせする方法として、その【解像度】を落とすことによって、工事費や施工精度との整合を計るように調整することが必要となります。

ちなみに、この左端の解析結果をモデルに落としたものが、下左の写真となり、今回の形態の最終調整を経た形態が下右の写真となります。

画像











以上が今回のおおまかな設計プロセスとなりますが、実は、このアルゴリズムによる検討は、「中性的な光の総量がどれだけ多いのか?」を問うことに過ぎない、ということに気付かれないといけません。
アルゴリズムとは、まずはその敷地周辺データを基にして出発したうえでの、予算状況や施工状況を加味した中での光の総量(最も明るい)の確保、ということに過ぎないのです。
つまり、プロジェクトが持つ、様々な与件を考慮した中での、最大限の明るい家、ということを示しているに過ぎません。





画像














この後に大切になってくる作業とは、このトップライト群から入ってくる光の「質」の決定なのです。
それが、「一般的なトップライトから入る光」、すなわち【一般的な光】の段階に留まっているうちは、まだここでの空間(空気)は本当の意味で現象してくることにはなりません。
それではまだ、他のどの空間(空気)とも同じなのですから。


光によって空間(空気)が現象するか否か・・・・・、ということ。
それは例えば、コルビュジェの建築に於ける光は、いたって【固有の光】になり得ています。つまり、「どこにでもある光」ではなく、見事に「ここだけの光」に成り得ているのです。
ラ・トゥーレット修道院の光はあそこでしか感じ得ない固有の光であります。
結果、しっかりと空間は現象してくれるようになります。




画像















では、この【固有の光】の【固有】とは何なのでしょうか?

それには、固有名というものを考えてみるとわかりやすいでしょう。
例えば、“建築”という言葉、すなわち「一般名」は、英語に翻訳された時、“ARCHITECTURE”というふうに翻訳・変換され、そこに「変更」が付与されますね。他にも、翻訳という作業が加われば、“山”は“MOUNTAIN”になりますから、「変更」というものが伴うことは当たり前かもしれません。これは、「一般名」すべてに言えることです。
しかし「固有名」の場合、例えば、僕の名前“MAEDA NORISADA”は、英語にしても“MAEDA NORISADA”に変わりはなく、そこに変更が加えられることはありません。
“MAEDA NORISADA”という固有名は、どこの国の言語に翻訳されても、決して、それが変更を被ることはなく、普遍的に変わることはない、いつも同じものなのです。

「固有名」というものは、「一般名」に比べて、とても特殊で個別的であり、それは普遍的には成り得ない言葉の種類だと思われがちですが、実は全くその逆で、その「個別性」故に、決して他のものと取り替えのきかない(翻訳不可能)性格を持ってしまっており、それ故、普遍的となる訳です。
ラ・トゥーレットの光は、決して、他のどこの建築の光とも交換・翻訳が不可能です。どこの建築を訪れても、あの礼拝堂の光は、あそこにしかありません。他と置き換えがきかないのです。
それ故、ラ・トゥーレット修道院の光というものは、普遍的なものと成り得ているのです。

コルビュジェの後期の作品やバラガンの光は、いつもこの固有名です。
それは、とても特殊であって、コルビュジェによってしか成し得ない、バラガンによってしか成し得ない、「その建築だけの光」なのですが、それ故に、他の一般的な建築の光と決して交換・翻訳されることはできません。
あなたの飼っている犬(うちの犬は一蔵といいますが)が、他の犬と決して交換などできないように。


ありふれた街の市民会館のトップライトから落ちる光の風景は、どこででも目にされるような大変に一般的な光の風景(空間=空気)ではありますが、それが決して普遍的になることができない、ということ。
光(空間=空気)の普遍性とは実は、固有性という特殊性によってのみ保証されることが了解されることと思います。

今回のプロジェクトは、アルゴリズムという普遍的な計算手順から、その「(光の)量」が導かれたと同時に、その「(光の)質」を決定してくれるものが、固有性という名の普遍性なのです。


そして、その「固有性」を決定してくれているものは、特に住宅の場合、その建築に関わる人の「記憶」なのかもしれません。
決して忘れ得ないものたちへの想い。
それが、光という実際に手に取れるものになることなのです。


                                                                      前田紀貞

■YouTube 動画(I remember you)
http://www.youtube.com/watch?v=b1puI5FuQug

月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ
気持玉数 : 43
驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた 驚いた
なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー) なるほど(納得、参考になった、ヘー)
面白い 面白い
ナイス
アルゴリズム建築と作家性 (I remember you) 前田紀貞の建築家ブログ/BIGLOBEウェブリブログ
文字サイズ:       閉じる