SketchupとBIM。Pluginからの出力

これはBIM専用Pluginを使わないで、汎用性のあるそれっぽいものを構築する例。
SketchupでのPluginでWisext ST2XLというのがあります。

指定したオブジェクトのデーターをExcelなどに出力する。面積表などに使用していますが、それをもう少しそれっぽく、RCボリュームや部品数などを集計していきます。

先に使うExcelファイルを決めて出力するという形式。
SU標準のレポートよりは使いやすいが、グループやコンポーネントの中身（階層内容）までは出力されません。
これはPluginだからと言うのではなく、SUのレポートでも同じ。
またSUレポートでは無名の「グループ」は、体積や面積を持っていても、中身がコンポーネントであろうとも、ひとまとめにされてしまいます。

下の画像は、建物だけを指定し、Wisext ST2XLで出力されたものをレイヤ名でソートした例。このPluginの場合、無名のグループでもレイヤ別になっていれば個別に出力します。（SUレポートはひとまとめ）

Pluginの検索視点は、何がどこにあるか（くくりが小さい）

SUレポートの検索視点は、同じもの・違うものがどこにあるか

　色んな使い方が考えられます。ただ、自分一人で描いて積算し、Layoutで図面書式にすると言うのであれば、自由に使えばいいのです。

　

でも僕は、アウトソーシングを含め、チームとして仕事をする場合は、どんな場合でも共有できる低いレベルの技術から始めるのが効率的と考えます。

障害が少ない、例外なく使える＝一元管理できるのが一番です。複雑なものより間違いなども特定しやすい。そういった意味でレイヤ名は部位の階層的につけ（下記メモ）、他のソフトにエクスポート時にも手がかりとなるように構成しています。

• SUではレイヤ階層は出来ない事と、グループやコンポーネントを解除した場合、部位に関係のない（所在不明）レイヤに拡散してしまうのを防ぐため。拡散するとレイヤオンオフの作業量作業時間は、圧倒的に増になります。

　多くのBIMソフトは、部品を入力時に多くの情報を入力するよう要求します。

物件として確定していない状況で、またはプランとして精度が高まっていない段階でも・・。つらいですよね。

正直言うと設計者はそんな不確定要素は後回しにしたいんです。

先に決めてしまいたいものが山ほどある。今はアバウトでいいんだよ・・と、設計者は考えているのに。でもBIMプログラムはそれを許さない（笑）

これは、ならば、どうするかって話です。

FBからの転載

転載

SketchupでのBIM化

この画像は僕のテンプレートをそのままレポートした物をExcelで読んだ画像。基本的な項目ですがたくさんあります。書いたもの全ての文章化なので当然ですね。

どれもこれも重要。

特にQuantity数量,Entity Name名前,Entity Volume体積,Layerレイヤ,Path所属,Price価格・・・などの項目がBIMを構成する項目です。

面積はこのレポート項目の後に出てくるXYZの実寸法で計算するか、あるいは数式型ダイナミックコンポーネントで計算しておき項目属性としてレポートする手があります。

僕がレイヤにこだわるのは、きちんとこの段階でレポートできるかどうかなのです。

描いた物がLayer0に散らばっていては、積算の基本の「どこの、何の規格の何が、いくつあるか」（部品数量表＝BOMといいます）の最初の「どこ」の段階でもう迷子になる。（BOMに関して）
余裕を見ない実数量だけは絶対に把握しておかなければならない要件です。
でも価格は変動しますよね。現場実行予算なのか、企業実行なのか、設計積算なのか（笑）
さらに制作現場分野では、定尺や板取からのロス分を、均して見込むのか、厳密に板取・定尺取りして加算するのか。　
実は、多くのBIMはそこまでは出来ません。理由はプログラマーが生産工程を知らないから・・それに尽きます。やる気になればできるのにねｗ
とにかく、それぞれ会社の運営手法によって、価格は様々。
ま、それはデーターマネージメントの考え方一つで、利益目標や工程管理まで可能です。

SketchupのLayer Matrix（レイヤ設定）

レイヤ設定用ファイル。

レイヤ設定は非常に地味で面白く無いし、時間がかかります。

だからそれぞれが、自分だけが判ればいいやと、適当な名前を付けてしまう。

そんな調子なので、時間をおいて他のプロジェクトを書いて、他のデーターを読み込むと・・・

レイヤ名が異なるので（適当に命名してるので）レイヤをマージさせるにも一苦労。

他人のデーターならば、いくら良いデーターでも、大変な作業量になってしまう。

そんなのは嫌だ！

と言う事で、作ったもの。

当然非常に地味だけど、作図ルールなんてものはそんなものです。

このファイルにはレイヤが241あります。

これらの文字はそれぞれ別のレイヤ。文字列がそのままレイヤ名になっています。

Sketchupを2枚立ち上げ、この中の作図する部分またはエリアを、コピーしてもう一方に張り付ければレイヤ設定完了。2019での一点鎖線等のレイヤ設定も行けます。

コピーした文字図形はもう用済みになるので捨ててください。

変態Sketchupの癖を利用しました。

共同でプロジェクトを行うとき、一番最初のこれを忘れるとヒサン。

とてもデーターを活かしきれません。

もう面倒だからと、基礎的管理も何もなしにVRに行っちゃいますか？

VR（バラ状態）で編集要求が出たら地獄。

VRの世界はLayer管理ではなく、オブジェクトの名前での管理の世界。

さらにバラバラになりますよ。

　

せめてこの段階で一旦整理しておかないと泣きを見ます。

Twinmotin使うから大丈夫・・？？（笑）

ダウンロード　2019/06/01

なんで日本語じゃないのか。
え～と・・・、この方がカッコいいからです。
もう、あなたをサポートする人が日本人とは限らないんです。

用途の分からない変な名前のレイヤがある。
変なので消してください。使い道は説明がめんどくさいのでその内。

SecPlan

中に～_SecPlan_F(F＝水平、V＝垂直）は、こんなこと（詳細図等）を書く必要がありそうな所に仕込む断面平面レイヤです。

2つ以上の断面平面の表現は、独自のレイヤーを持ってないと非常に邪魔くさくなりますよね？。

そのオンオフはシーンで設定しておくとLayoutにスムーズに反映されます。
建てる順序などの動画などでは、よく見られる複数の断面平面。
そりゃ動きがあって面白いですけど、ディテールまで3Dで表現する場合は必須の小道具。

それに、矩計図や断面図・展開図・平面図・天井伏せ図など、平行透視の図面化表現にはこのコントロールとシーンテクニックが必要になります。
視点が異なる構造図には構造用として、～S_secPlan_を用意しています。
軸組図を書くには必要ですので・・。

照明効果レイヤ
レンダリングソフトなどで、見える照明器具と見えない光をコントロールする場合があります。昼間なのに夜の発光をさせているレンダリングを見ますが、あれっておかすいと思いませんか？（笑）
昼間は消しましょう。それだけで昼の演出と夜の演出の2枚が簡単に出来るでしょ？
これも省エネｗｗ

Sketchupのテンプレート

Sketchupのテンプレート

通常より重たいテンプレートです（笑）
ダウンロード　2019/06/01
2018で作成してV8で保存しています。

用途
これはLayoutデーター送信を意識しています。
適当な簡易モデルより、レイヤとシーンが主役。
各階の平面図と構造図。それとあと少しの操作で展開図まで出力と言った感じ。
（Layout側の標準画面設定併用）

基本的な考え方
このテンプレートはマスタープラン用。

• webのfree Sketchupを使う場合は、マスタープラン作成後アップロードしてから、各業種への配布や分岐する方法で共有できると思います。

各階は設計密度が上がるにしたがって、それぞれの階などでコンポーネント化され、別図で編集され、インクルードなどで再構成されて行くと思いますので、レイヤ構成は最小必要限度で止めています。（更新するのでコンポーネントは解除しない前提）

レイヤ名は・・これも色々な考え方があって（笑）
色んな書き方・分類方法がありますが、基本はやはり、階（位置）とレイヤ分類。　
VRなどで使われるゲームエンジンは文字検索が強く、IFC分類よりコンポーネントを特定しやすいのが特徴。
もちろんIFC併用でも何ら問題は無いでしょうが、名前での分類は継続しておいたほうが得策ですね。
　
どうやって使うの？って聞かれると面倒なので。
簡易モデルはそのサンプル。使う直前に消してください。
レイヤとシーンだけが必要なのです。
階別平面断面は床上1000。
書かれる基準階高に合わせて、階ごとそっくり上下させています。
縦断面は階ごと・全体との兼用ができるよう、あえてレイヤの縛りをしていません。

通常、作図したオブジェクトは最低限グループ化して、何を描いたのか、それはどこの何か、ひたすら名前つけとレイヤ分類する。これをやらないと共有出来ません。
それに分類をしないと、いつまでもグチャコのままです。
手軽だからと言ってグループにグループを重ねていく。
多層グループ化していくと、最下位コンポーネントの編集・・どうしますか？

シーンタブを押しながら、アウトラインやレイヤ一覧の動きを見れば、何をやっているのか分かりますよね。

追記。
階の境目の床。
Slab（床版）とFloor（床仕上げ）とは、階を分けています。
いわゆる「2階の床」と表現があったとしても、構造の「床版は下階の工事で作られる」と言う事に由来しています。

普通に読み込んで、ファイルで「テンプレートとして保存」で、次回からテンプレートとして選べます。レイヤ設定が面倒な時用・・かな？

最近のCADのメモ

あくまでも僕が使った範囲で。

3Dソフト

1.Revitは、ほぼソフト会社側から提供されたデータ管理手法にのっとって作図する。従来型建設図学を目的にしている。CAEにもデータ移行可能とされている。

2.Sketchupは、無料から始まった遺伝子があるので、いまだに無料のsoftがある。

約0～15万。￥0があるので、Jw_cadまでは行かないが使用者のすそ野は広く取り入れやすい。

3.Rhinoceros3D（ライノセラス3D）。15万程度。海外では普及している。その作図特色はザハ・ハディットや隈研吾の弟子が使っていることでそのファンが使用し、大学の中でも普及して居る。特に最近の隈研吾作品の表層にある、細かな部品の繰り返しは、隈研吾の弟子が使うグラスホッパーというプラグインによるもの。ライノセラスは曲面が非常に得意なのでザハ・ハディットの弟子たちが好んで使っていた。ただしどちらの建築家もこのソフトは使えない。あくまでも弟子（笑）

　

実務3DCGとしての選択肢として、ほぼこの3つが代表的だ。

4.FreeCAD　無料で日本語対応。　番外に置いているが理由はバージョンアップが遅い事。理由はこれだけ。実はこの無料ソフトは非常に優秀で機械から建築までこなし、データの互換性もよい。それに簡易的CAE機能まで標準で付いている。Revitとさほど変わらない。

最終的に平面図などに図学に則った図面化する機能は上記4つは標準で付いている。

Revitは確かに現在のところはこれでよいのだが、その先が不安。メーカーに頼るしかない。RhinocerosはSketchupほど操作性がよくない。Revitを使うならば僕はFreeCADこちらを選択する。理由はコスト。

Sketchupをメインに使用しているのは、上記のソフトを使った上での判断。

複雑な造形もライノセラス並みにこなし、一般の建築のような直線構成は大の得意。

何よりもデーターの共有化が図れることだ。

どうやら日本ではBIM・BOMの使い方もあいまい。

BIMなどは、本来目的の建築性能を検討するためにあるのだが、日本では「部品価格」のアタリが付けられる物としている。それはBOM（部品管理）分野だろう。sketchupもBIMは出来る。IFCにも対応している。ただ、BIMを本気でやるにはそれなりの覚悟が必要で、そこまでモチベーションを上げなくても、設計作業が済んでしまう（笑）

コストのアタリを付けるのならばjw_cadでも出来る。部品図の中に隠し文字で記入してCSVで出力しexcel上のVBで処理すればよい。

sketchupの欠点は、使用者や機能のすそ野が広すぎ、その上に自由すぎて、Revitのようなメーカー仕様・手順がない事。簡単な図面ならば誰でも書けるのだが、それを共有管理するところで混乱する。

Jw_cadユーザーが、油断すると好き勝手にレイヤーや線種を使ってしまい、取り留めもなくなるのと同じ状態になること。だがそれらも標準的な共有ルールがあれば解決できる。

jw_cadでは大変古い話だが、ソフト開発当時、16グループ分類が可能になった直後、大手建設会社と設計事務所JV物件での図面仕様取り決めをベースにして、部品制作段階から線種及びレイヤー色を標準化し、誰が書いても一定レベルまでの表現を可能にした。最近そこを見ることがあったが、そのルールが20年以上継承されているところを見ると、少なくとも「ハズレた設定」ではなかったようだ。

逆なことを言えば、そこが建設業のCADデータ化のキモ。それを操作できるマネージャーを育成すれば、その後のハードルは低い。色んな状況になっても柔軟に対応できる。

　

だが、Sketchupを開発しているところはそう言うデータマネージメントの必要性をあまり感じていないのが現状。その点に関してはRevitの方が問題意識はある。

Sketchupでは、開発のところよりむしろプラグイン作者の人たちが非常にデーター共有意識が高く、それらのプラグインを使うと、数々の中から選択を迫られる。その都度自分の業務を見直していく作業が不可欠になる。こうして育った人材は、どんなソフトよりも有益になる。
　
何よりも、これらのソフトがどうこう・・と言うよりも、顧客データーを含めたそれらをマネージメント出来る人材が、建設業の営業段階や建物の品質、あるいは企業品質まで左右する段階にきている。それを社内か、社外で育成するのか・・自明の理だろう。

sketchup Plugin：メモ VisuHole 1.0 - Overview

sketchup Plugin：
いつも最高に優れたPluginを開発し続けているFredo6さんの作。
だけど、これはイマイチ人気がない。名前でやっちまったか？（笑）
その名も「ビス孔」。小物にも感じる命名なのだけど、これが中々すごいのだ。
sketchupにも慣れて生産工程まで視野に入れると、必然的にモデルは完全ソリッドモデルを要求される。
そうなると基本のブール演算では、時間もかかり物足りなくなってくる。
そこで、立体を「貫通させる・貼り付ける」と言うコレ。
重層的なソリッドモデルを一気に穴をあけてくれる。

例えば木造建築の壁の場合、BIM以降の物理レベルのモデリングをするならば約8層のソリッドモデルが重なる。窓を開ける場合、それをブール演算などで8回行う必要があった。
それが一度で済む。と言うシロモノ。

なぜに人気がないのか、勿体ねーじゃんという事でメモ

Sketchupでの構造用テンプレート

ちょっと前に思いついてんだけどテストしてみた。
主役はダイナミックコンポーネント。
やろうとすると更なる妄想が浮かんで中々方針が決まらないのだが、大体こう言う方法論になるんだろうな・・・と言う尻切れテスト。
お尻は恥かしいのでまだ見せない.

sketchup発excel経由でLayout

大変結構な感じですね。

一昔前にはEXCELで構造計算や省エネルギー計算をやってたので、絵柄と数字が連動してくれるってのはとても良い。

いいじゃんこれで。グローバルなIFC-BIMで無くても十分効果は出る。

saveと更新をしなきゃならないけど、その更新忘れも指示してくれるようだし、広範囲の可能性を感じます。

sketchupでらしき事をやって見る。

びむ。
いや大げさに書かなくともいいんだけどね。
BIM - Building Information Modeling
平たく言うと、他の3Dソフトと共有できる情報を持ったモデリング方法論。それにはとりあえずルールがあってそれに適合したソフトだけがBIMソフトだっちゅう話。大手設計事務所・建設業者はちょっと病気（笑）けしかけているのもいるし・・
　
技術の進歩は大歓迎だが、その影響で視野が狭くなり切り捨てる物が多くなる事があってはならない。建設業総体を見ているのかどうかが気がかりだ。どうも配慮が足りない気がする。
　
正直な所、IFC区分もどれだけ整備されているのかは知らないし、区分されていなければ、漏れた技術は一体どうするの？と言う疑問がある。ワタクシメはたかが情報ソフトの為のルールが建設やデザイン行為そのものを縛っちゃならないと言うスタンスであります。

BIM総体のビジョンとしての方向は賛成だが、それに至る手段が企業利益優先を理由に閉じられ過ぎているのが額面通りには受け取れない。
sketchupはgoogle時代を経た事で、可能性を広げるオープンな土壌がまだ存在する。jw_cadと同じく支持する理由がそこにある。

とは言いつつも、普段使ってるsketchupは一般的にBIMにちょっと弱いと思い込んでる人もたくさんいる。ゆる～い縛りがモットーのsketchup。洋服の型紙から建築や工業製品までの文房具だ。

だけど、どうやらお前さん誤解されてるみたいだぞ？出来る子だって所を見せてやれよ（笑）


という事で、IFC設定が出来るT2Hさん作のプラグインBSTを利用し、仮にIFC区分した木造部品その他を仕込んだデーターで描いてみる。
作図は全てコンポーネントで行う。これでどの時点でもどの部分も交換可能にする。コンポーネントならばsketchupは得意中の得意。必要があればそれら部品に相互関係を自己判断させる事も可能だ。これは簡単な試作例 。自分の強度を判断する。

普段使いのfreeのプラグインだけで、その他のわずらわしい入力（数値入力）は行っていない。sketchupで、pluginに仕込んだIFC設定ダイナミックコンポーネントをBIM標準ビューアーで認識するかどうかのテストをして見る。(専用のBIMは有るが英語版。価格データーも違えば寸法の押さえルールが違う。BIMに関して異論は数々あるとは思う。共有サーバーも必要。まぁ、でも色々見たけど構造toolとしてはやはりT2Hさんのが応用が利く。）

以上の手順で、ちょろっとBIM様式（IFC)図面を作った。出してしまえばもう他のBIMソフトと全く同じで、手が離れる。要は入力にどれだけきちんと書けるかが問題なだけ。そして全てソリッドコンポーネントなので・・わかりますね？各種の演算や設定もOK。開口部は省略したけれど僕のはそれらも完全なソリッドコンポーネントです。

それ専用のBIMVisionで読んでみる。ビデオにしたら元々薄い色がさらに薄くなったのでyoutubeで見た方が良いかも・・

全ての部材が仮のIFCなので比重は1で計算されている。ちゃんとやればちゃんと出て来るはず。面積はもちろん。でも重心が慣れないソフトなので判らなかった。それはsketchupで個別部品ごとにも総体でも出せる。必要とあれば製材時の木割り板取だって（笑）

IFCのルールがどれだけの地平を見据えての物かは会員ではないので正確には判らない。でも、手軽さでは文房具的存在だが、sketchupがBIM対応のソフトに比べ遜色がある訳ではない。

他のソフトの悩みと同じく、運用・データーマネージャーの腕次第という事で（笑）

さて・・3角関係の相性を試す

BlenderとUE4はレンダリングエンジンはCycles。

3ds maxとバイバイしようと思った要因にこれがかなり大きい。

いろんな参考ビデオを見てると、3dsmaxで中間処理（主に造形）しているけれどマテリアルは識別のための名前を付けているだけ・・。

つまりは、3ds max上での詳細なマテリアル設定は、役に立たないという事。同じレンダリングエンジンのBlenderならばもう少し楽なのかもしれない、という事で試す。

このデーターはsketchupで作成した物を.daeに出力しBlenderで読んでいる。下部のノード形式のマテリアル設定はUE4より省略形だが基本は同じ。

アウトラインを見ると、とりあえずグループ仕分け状態で読んでいる。逆正三角形が連なっているのは下部にグループが存在している。グループ名は見事に無い。

あれれ、こんなサミシイ図面を描いた覚えはないぞとsketchupのアウトラインを見てみると＜＞で書かれている物はコンポーネント名。なるほど、コンポート名はBlenderでは無視するらしい。他の例もそうだった。

blenderのアウトラインを見てると何と漢字がある、「差分」（笑）。これsketchupでは全てソリッド（互換時時のエラー防止）で描いているのと、いわゆるブール演算はよく使う。そのなごりだが漢字はアカン。エラーが出るぞい。シーンもカタカナで出てる。やばそうだ。

案の定FBXが出力できない。何やらキーワードがアカンらしい。とにかくデーターが悪いと文句を言っている。Blenderの該当処理プログラムを読むと・・・うむ、何ともない（解ってない）

「差分」を書き換える。sketchup開発元に言いたかったのだけどインターフェースの日本語のsketchupはありがたいのだが、わざわざデーターのどこかに日本語を付けるのはイカン。すごくイカン。いつもイカンと思ってる。名前を書き変える単純作業を163回。下層も漏らさないように検索欄に入力し検索しながら書き換えたので見落としは無い。

だがFBX出力は失敗。



もしやBlenderの設定がオカシイのかと他のファイルを試したが問題が無い。sketchup　dae形式　の経路で何かヘッダーの一部などが欠落したかと調べてみるが問題ない。ただ「差分」と言う漢字は出力されていたので、sketchup　blender間はこのデーター段階で文字変換した方が確実に作業量は減る。
おい！「グループ」ってのも残ってるじゃん！

sketchupが出力したFBXデーターはどうか。

FBX形式はゲームエンジンにもすんなりいく。やはりFBXでは「差分」はなく書き換えられている。ここで念入りに処理するぐらいなら、最初からブール演算時にわざわざ日本語で出力しなきゃいい物を・・・。
ま、sketchup側ではdae形式が素直すぎて名前をそのまんま吐き出すのは判った。

で、まだBlenderのFBX出力エラーの原因が解らない。
試しにsketchupで書いたFBXを読んでみると読めない。
読めないのなら書けないのだろう。

じゃ、BlenderのFBXの問題なのかと試す。

ゲームエンジン側で簡単なFBX出力をBlenderで読む。問題無し。


Blenderでその図形を編集して（回転させただけだが）FBX出力。問題無し。

ゲームエンジンでBlender出力FBXを読み込む。問題無し。

これ多分アレだな・・・（笑）


結論。
sketchupで作成したデーターは直接ゲームエンジンに読ませるのが吉。

-------------
追記　sketchup　3ds形式出力  Blender　 FBX出力　UE4　を試した結果。

イメージファイルまで素直に読んでいる。

このルートが最良のようだ。特殊な編集が必要な時はこれを使う。一般の時は直接でいい。

ただし細かい事だがスケール単位は1/100違うので気をつけなきゃ（笑）


よし！　これでOK！

sketchupとゲームエンジンだけで十分（忘備録）

ちょっといい例としてこのビデオ。

このビデオではrevitからスタートして 3ds maxを経由し、ゲームエンジンで仕上げをしている。1時間ほどあるので2倍速で見た。

最後55分前後から始まるカメラの動きがぎこちないと言う人もいるだろうが、これはVRのプレゼンテーションの世界。あらかじめカメラの動作を設定してレンダリングするアニメーションとは違う。（もちろん、同じようにはできる）
リアルタイムで一人称カメラ視点で空間を動き回る事を目的にしている方法。
（先に見た方が良いかもしれない）

そうでなければゲームエンジン（以降GE）の必要が無い。GEはいわば状況シュミレーションソフトと言い換えても良い。

この一連作業を見ると、revitでの建築本体にかけた時間は全体の15％ぐらいだろうか。30％程度が3ds max あとの55%がGE。それぞれのソフトに関して相当な熟練者であることは間違いない。プロ中のプロなのだが・・autodesk社の関係？（笑）。

いやRhinocerosなど、その他のCGソフトを使いこなせる環境は・・・CG学校の先生かもしれない。やることが決まってから短時間でマスターしなければならない僕らとは違う匂いがする（笑）

特段用意したプランがあっての作図ではなくその場で描き上げているが、BIM系の管理手法が災いしてなのか、随分かかっている。（思い付きを描くならSUの方が得意）マテリアル設定も後で識別出来ればいいぐらいの分類設定。

その次に3ds max。細かい造形はこちらでやっているがrebitを使った意味が無いほど手を加えBIMどころではなくなっている。最初は「このプランでいくら！」とはじき出すのかと思ったのだがそれは出来なくなったという事を意味してる。

一つの構造壁面に室内室外の仕上げなど、複数のマテリアルが使われるのが普通だが、その時には3ds maxのマルチマテリアルが有効（プレゼンテーションに限るが）なので、それをやっているのかと思ったらそうではなかった。UVマップに転記してマテリアルの数をまとめて居る。なにすんだろと思ってたら、これはゲームエンジン側のマテリアル設定数を減らす目的だった。

この先がGE。家具や照明など、このビデオの大半がGEでの作業。

こうしてみると、revitや3d maxの作業は全てsketchupで難なく行える。むしろ3ds maxを経由したおかげでポリゴンの多くは3角形の集積となってウルサイ。
revit側での3ds向けの書き方も必要ない。

見終えてrevitや3dsmaxの良い所はどこで活かされているんだろうかと疑問に思った。
これらの用途ならばsketchupのみで十分だ。いや、sketchupにはもうVRのプラグインが出来ているのでVR体験ならばそれで十分。

ただし「VRを、今までの映画やアニメーションレベルの高品質で」となると、今の所、最低このぐらいは頑張る必要がある。

BIMはいいが、クソくらえ。

ある勉強サイトで発言したのでメモ。話題はIFC（目的はBIM）なんだが、IFC分類をやらなければBIMが出来ないという事ではない。どうもそこから違うような気がする。

CADはデーターを広く共有できる事が最大のメリット。大手の設計組織の様なBIM担当「書き子」がいる所ならそれでもいいのだろうが、専門分野の職人さんや設備・電気屋さん達とデーターを共有出来ないのであればBIMなんぞ看板倒れ。

日本のソフト会社ではBIMだと徒党を組んで活動してはいるが、それらは大型物件大型設計組織向けに見える。BIM対応の高額のソフトが導入できたとしても、すそ野が対応できないのであれば役に立たない。建設技術の進歩には「図面情報を共有する」事が目的であるはずなのに、高額ソフトを売るための付加価値の視点では付き合えない。

2次元のJw_cadでだって積算など似たようなことはできる。登録図形に隠し文字で製品名や価格等の情報を記入しておく（図形以外の属性を付加する。）それをexcelに吐き出させればよい。簡単な事だ。2次元ソフトでさえそのような機能はある。

3次元になって現状のIFCの属性たるや・・・（笑）
例えば窓。建設現場での2次元施工図は開口部の種別建具番号大きさ高さ位置は記号と共に書く。2次元で高さ方向が無いからなのだが、3DIFCでも同じように書いている。（インスタンスって言うんだとww）アホちゃうか！と（笑）
それらの大手ソフトメーカーが集合してのBIM。怪しすぎるのだ（笑）

ましてやsketchupヘビーユーザーが、そんな見通しの悪い物に振り回されては、皆が共有できる3次元路線から外れてしまう。もっと楽に簡単に使えなければならない。そんな気がしたので余計なことだとは知りながら、水を差した。

反応？　そんなものは知らんww
-------------------------------------
IFCに関しては僕は臆病です。

外したことを言うと思いますがその辺は勘弁してください。
まず描いた図面は他に再利用できるのがCAD（でした）。その目的に向かっての方法として、IFCに限らずデーターに属性を付加して「分類」行うのですが、総合的なIFC対応の3DCADシステムを見ても、いまいち明確ではない、あるいは設計作業手順に沿っていない場面に出くわします。
BIMのデーターがそのまま構造計算や収益計算やエネルギー計算・ファシリティマネージメントに転用可能としても設計段階でIFCのクラス（インスタンス）まで設定するのは（それほど各社が整合性がある訳ではないし・・）作業手順としてどうなのかな？と疑問に思うのです。

確かに全てが流通商品で出来上がる昨今、でも常時既製品データーを読み込んだりクラスまで設定すること。さらにコストプランニングや構造など性能評価後に出る手戻り作業を考えると気が重くなります。

また、コストプランニングや建物の性能評価の手順とIFC分類とが完全に一致しているかと言うとそうでもない。
僕は、IFCの現状を見ると、それらゴールさせるべき地点を見ずに、細分化しているだけに思えています。

と言いながらもBIMは有効な方法論ですので、まずはsketchupに出来る事、IFC記入も含め後に手戻りが少ない事を目的にした簡単な分類に止めておこうと思いました。

BIMイコール即IFCではありません。これはそのソフト業界の都合仕様ですので、もっと楽に構えてよいのじゃないでしょうか。
むしろ、sketchupはソフトの性格上、ひたすら部品配置路線上に無くても良いのではないかとも思います。

長いですが本題です。
日本の分類もそうですが前から疑問に思っていたのが、分類が職種別あるいは素材別に分けている事。
積算もそうですが、いわゆるコンクリート工事や木工事建具工事などの分類の仕方です。この分類は設計者の意図とは違います。部品の羅列で考えている訳ではありません。

設計者は、この壁のデザインや性能・床の仕上や防音性能などと「部位」でイメージしています。また、エネルギー計算などはまずは外皮性能ですので開口部を含めた外壁と屋根と床。コストを考える時も、外壁ならば構造仕上etcの価格構成や組み合わせなどで考える。

つまりは、ほとんどの場合「部位」で考え検討している訳です。ところがIFC分類はちょっと違う・・。や、IFC分類の前に、建築部位に分ける作業ルールの方が先のように思えます。

という事で、IFC等の種別分類の前に、部位別分類としてレイヤー分類（sketchupのシーンを利用してフィルターを作る）をしています。実際はコストプランニングやエネルギー性能計算、構造計算などにもこの方が合理的です。CSV出力さえすればその部位のコストプランニングも容易。さらに換気設備や配管等や構造などとも絡めての3Dマスターデーターを作る事も簡単になります。

IFCはそれらの検討が終わった後の作業かと思います
-------------
この図形の赤はレイヤー表示色。（スタイルで設定する。）つまりは現在レイヤー0にある。レイヤーを移動させたかどうか（部位設定を行ったか）が一目でわかる。CSVにもきちんと出力される。
パースなどの時は通常スタイルに戻せばいい。　これらをテンプレートとして設定すればOK。

Sketchup Dynamic とレポートとLayoutの関係の初期メモ

 世界的な流れのBIMの技術はまずは名前を付ける事から始まる。そしてひたすら分類・・・。

でもいずれ分類する事にも疲れ、きめ細かく分けたIFC分類も、さぁ・・・ともウッスラ思っている。

その内分類が違ってたので価格を間違ったなんぞの事故を経て、分類屋なんぞが出て来る予感。

多分、このままでは余計な所で気を使うシステムになるのだろう。とは言いつつも、そんな分類する前にやることがあるんだよとと言うのがコレ。

IFC分類あるいはIFC部品を使う前に、それらが引き起こす間違いを避けるために準備しておか無ければならない。おろそかになりがちだが3DCGでもきちんと部位レイヤーに分けるべきなのだ。


2DCADの場合はどうだったか。基準線・躯体・建具・構造・設備・階段・仕上げ・寸法線・文字・記号etc・・・.

これらは2次元の図面を描く為の分類。分けたところでそう大した意味もない。どちらかと言うと「次の作図の為の能率化」と言った意味合いの方が強い。

極端な例では同じレイヤーに線の太さを変えただけと言うデーターにも出くわすのも珍しくもない。

ここ数日BIM対応漏れが起きにくい方法とは・・なんぞ考えていたが、とりあえずsketchupならばこう使うのがベストだろうという環境を作って試している。

これらの画像は、上から

1. sketchupの作図状況とダイナミックコンポーネント。全く同じものだが所属レイヤーで色が変わるようにしている（レイヤー色スタイル）
2. 図面全体のデーターレポート
3. 台な罠コンポーネントをLayoutに出力した時の属性の表示（単体）
4. くり返し同じコンポーネントを使った場合の限界

などを試した。

1.は、あらかじめ従来よりも詳細な部位別レイヤー設定を行った。レイヤー数は43。これでも建築だけ。多い？そう思う人はIFC分類にはついてこれない。

救いはsketchupのレイヤー移動がプルダウンになっている事。設定済みのレイヤーに移動させる事はそう手間ではない。離れた複数の図形選択して一度に放り込む事も出来る。僕の知る限りでは、2DCADではこれほど簡単ではなかった（この作業、少なくとも4倍速い）。

またレイヤーに適正に図形を分配するための表示フィルターも設定した。これでレイヤーをあまり操作することなく確認も出来、またアウトラインでの部品検索も素早くなる。

この色違いはマテリアル色ではなくレイヤー色。マテリアルはスタイルを変えて作図の後に行えばよい。このレイヤー色を考えた人、エライ（sketchupだけではないが・・ww）！

2.はレポート。画像上の名前の赤は1.の時点ではまだ固有化してなかった紫のキューブを固有名化して出力した。ただ所在レイヤー等が何かの調子でレポートに出力されない場合がある。

3.は単体ならば色々な情報を書き出す

4.は、この2つは名前とIFCとレイヤーだけが違い、中身が一緒なので干渉するのか書き出す属性情報が減って来る。

Building Information Modeling へのメモ

以前、BIMはこれからを見通しているか　みたいな事を書いたがその続きになるのだろうか・・。
最近、sketchupでのダイナミックコンポーネントについて色々考えていた。

ダイナミックコンポーネントは、まぁ作った方も「応用が利く便利な3Dパーツ」的な扱いだったんだろうな。うまくやれば応用が効くことは効く。一つのモデルでサイズの違う物も出来る。

とりあえず素人なので色々なケースを見てみたが、ちょっと考えさせられるのが、3D部品の悲しさなのか、設計する者のちょっとした手間を省くだけにとどまっている。いや、それが目的だったのだろうが、せっかくやるなら「もう少し建築を良くしようよ」的な感じでもいいのかなと思う。

昔ちょっと絡んだ市販用のCADソフトには、その設計が目的を達成しているかどうかの判断機能を仕込んだ。それには判断材料としていくつかのデーターベースもセットした。建築が専門分野化しすぎる傾向にあった時代。構造の基本が判る設計者が少なくなる。法規も怪しい。設備なんぞは別世界。意匠担当者はデザイン屋と化してしまっていた。これでいいんかいね・・・と言う思い。その時は建築条件と融資条件とが上手くいくとにっこりマークとなる機能だった。僕の趣味ではないが、なぜかそうなっちまった（笑）いや実はめんどくさかったんでほとんどカットされちゃった（笑）
　
ダイナミックコンポーネントの能力と言うか関数を読んでいるうちに、ありゃこれを単なる3D部品にしておくにはもったいないなと思い始めた。そこで昔を思い出す古い奴（笑）

3D部品はコンピューター内部でモノの代用品。単に空間形状だけしか設定されていなければパースのネタ程度にしかならない。それじゃ面白くないので部品が強度ぐらい自己判断する能力があれば、つまりはミクロが正しければマクロでその総体も判断しやすくなる。それで、Sketchup Dynamic Componentの練習　構造的なヤツのような物を作ってみた。

結果、ダイナミックコンポーネントの関数には沢山の物足りなさも感じるんだけど、まぁ方法論を変える事で何とかなるのかもしれない。

ボチボチだけどね（笑）

BIMはこれからを見通しているか

BIMの方向性について：

前記事のビデオは最終的にDWG形式を前提にしている話だ。
なぜその会社に集約させるのか。（CAD技術発展ではなく、自社勢力発展戦略的な事しかやってこなかったautodesk社を軸に置いてるのが気になる）

　
現在のようにHDDやPCの性能が進んだ以上、各種のデーターは（現段階では）汎用性・拡張性の高いXML形式にすべき（万能ではないにしても）。

DWG（DXFも含め）データー形式は欠陥が多過ぎ、先が詰まっている。
DWGはソフトの勢力が強かっただけで、万能なデーター形式では全くない。

xml形式であれば、3Dソフト類からでもリレーショナルデーターベースからでも、あらゆるテキストソースが読めるアプリケーションからでも、アクセスし応用できる。

ちょっとでもBIMを社会的共有資産として役立てようとするならば、重要視すべきはデーターの拡張性。それをデーターの構成目的要素にすべき。いや今の所BIMはそのような広義な社会的意義がある物とは認識されてはいない。だが、それは産業全般としてこれから重要になる要素だ。

その視点に立って見ればxml（可変長データーベース形式）は、作業としても、欠陥や限界のあるDWG等の図形方言のような有力データー形式に追従し、選別・切り捨てして納めるよりもはるかに楽だろう。

もはや各種のデーター集積として「物」を扱える時代。「物」から抽出された図形だけのデーターにすべきではない。また一対一のリレーション様式だけでは時代にそぐわない。

グローバル化は経済だけの話ではないのだ。人類がより幸福になるには、さらに学術的に、各専門分野を乗り越えた学際的な進歩を共働して遂げなければならない。
　
その為の方法論であるクラウド化や各種ビッグデーター応用世界を目前にして、このちっぽけな改善方法は、何だ！？と思う。