ビジネス用品、モバイルホワイトボードよりコッチ。

世間では、スマホの定着を背景にして、打ち合わせ場面でのホワイトボードが再評価され、持ち運び出来るタイプまでも発売されている。

正直、僕はズボラなのでメモする事は滅多にない。どうでも良い事は覚えない。他人の手順や方法論には興味が無い。大事な事ならどこかの誰かにでも付随して付いてくる。漏れなく記憶する程の余裕も無いので、ダダ漏れフルイで残った分を整理しておけば良い。
　
と言う極めて雑な記憶パターンなので、ホワイトボードで綿密に考える事もこの先も多分無い。と言う事でタダのA4クリアファイル(100均)。

白紙あるいは方眼紙あるいは各種様式書類フォーマット、又はメインテーマとなる書類やスケッチを下にして、空いているクリアページを重ね、レイヤー(層)として使う。（画像編集ソフトやCAD関連を使い込んだ人なら、これがどれほど有効な手か・・判りますよねwww）

気になったり、決定段階でスマホで写真を撮る。手書き書類がコレで電子化されて時系列にファイリングされる。（適宜SAVEするわけです）

使った後はティッシュで一拭き。いつも新規ファイル状態（笑）

実は正規のカッチョイイそしてちょっとお高いホワイトボードノートも持っているんだけど、それを作った有名メーカーさんのデザイナーは、レイヤーを多用していなかったのか（笑）、レイヤー応用が利かない。

という事でアタシは100均のクリアファイルとホワイトボードマーカー。

コブとり爺さんの話

コブとり爺さんの話
　　
昔或る村に、それぞれ片方のほっぺたにコブが有る二人のお爺さんが住んで居ました。二人は「似た者同士の縁」で隣同士に住んでいました。

子供たちがコブを馬鹿にして、からかうのを聞いても、一方のおじいさんはニコニコしているが、もう一方のおじいさんは、からかう子供たちを怒る人でした。それを見た村人は「良いおじいさん」と「悪いおじいさん」と呼ぶようになりました。

ある日「良いおじいさん」は山に出かけ雨宿りをしているうちに眠り込んでしまいました。すると、何やら楽しそうな宴の音がします。そっと物陰から見ると彼らは人を食うという恐い顔した鬼達でした。

しかし余り楽しそうな宴なので「良いおじいさん」は踊りたくなり、鬼達の前で陽気に踊りました。

鬼はこのおじいさんを見てよろこび、「必ず明日の夜も来てくれ、これは明日まで預かる。来てくれたら返す、もし来なかったらひどい目にあわすぞ」と、おじいさんの体の一部のコブを取ってしまいました。

コブが取れて大喜びの「良いおじいさん」。朝になり山から帰って隣の「悪いおじいさん」にこの事を話しました。

「悪いおじいさん」はさっそく隣のおじいさんから聴いた鬼との約束の時間と場所の所に行きました。でも「悪いおじいさん」は「良いおじいさん」のようには上手に踊れませんでした。

すると鬼たちは「下手くそだな、つまらない」と言ってがっかりしました。でも「約束だからこのコブを返すぞ」と言って「悪いおじいさん」のもう片方のほっぺたにコブを付けてしまいました。

それ以来「悪いおじいさん」は両側のほっぺたにコブを付けて暮らしました。
めでたしめでたし（他人の成功をうらやんではいけないという教訓）
---------------
この話の解釈には色々ある。
代表例として
「良いおじいさん」が調子に乗って、通常は人と鬼との相容れぬ関係の鬼たちに飛び込んで踊り、運よくウケ、明日も楽しませてくれ、必ず来るようにと約束した。その約束の担保として身体の一部のコブを取られた。

「良いおじいさん」はうまく行って大喜びで隣の「悪いおじいさん」に話すのだが、コブが約束の担保になっている事は話したのだろうかと言う疑問。「良いおじいさん」には鬼との約束を守るつもりはなく、「悪いおじいさん」もそれを知っていたならばノコノコ鬼たちとの約束の場に出かける事はない。
その上「良いおじいさん」は「約束を守らないとひどい目に合わせる」と言う鬼との約束から逃れようと「悪いおじいさん」を利用したのではないか。「悪いおじいさん」は不都合な現状を良くしようとする努力の人で「良いおじいさん」は、本当は自分の利益の為他人をおとしいれた悪い人ではないかと言う説がある。
　
「良い」「悪い」は所詮レッテル。だが、それで思考停止になって先入観が出来てしまう怖さの教訓でもある。「悪いおじいさん」には同情するしかない（笑）
-------
まぁ、この話には宗教解釈・精神分析解釈やプログラム的解釈など色々あるが「コブとりじいさん」をそろそろ実践してみようと思う。

最初の頃は、ずっと聞きたくもない事を我慢して聞いて居たので「耳にタコ」が出来たのだろうと思っていたシコリ（腫瘍）。ワルチン腫瘍と診断されたが良性。取り除くには手術しかないと言われたが顔面の神経が集中している所なので、手術で表情筋が動かなくなる事もあると告知されビビって数年経つ。

元々外見はどうでも良い。引きつった笑いは持ち味だし、コブを見つけて馬鹿にする人も見かけないので放置していたが、最近何の勢いなのか成長してきたので取ることにした。

まぁ顔面が一部マヒしてムヒヒ状態になっていても、中身は上の説の「悪いおじいさん」に変わりはない。

ニセガネ作りのデザイン

さっきたまたま見ていた中にこう言うのがあった
-------------
一人の旅人がやってきた 
 旅人は宿屋に入り100ドルを支払った  宿屋の支配人はその100ドルを肉屋への支払いに使った  肉屋はその100ドルを付けで買ってた女に支払った  女はその100ドルを付けで泊まっていた宿屋の主人へ支払った  旅人は部屋が気に入らないと言って宿屋から100ドルを返してもらい去っていった 
誰も一銭も支払ってないのに全員の借金が無くなった 
------------
よーく考えてね（笑）


20年ほど前、どこのどいつらだかすっかり忘れたけれど（笑）、これをたくらんだんだよね。
この記事を読んでHDDを探すとこんな悪だくみの図が残ってた。

原資が1000万程度としても、地域内だけで通用する地域通貨を長く循環させればその合計総額の経済効果が産まれる。もちろんいつでも発行したところに持って行けば現金に交換できるので、町民や地域内の企業には、現金と同一価値がある。

• 経済効果（けいざいこうか）または経済波及効果（けいざいはきゅうこうか）とは(Wikipedia)
• 新規に需要が発生することにより、その需要を満たすために生産が連鎖的に誘発されることである。 それによって発生する金額の合計額（生産誘発額）や、何らかの事象が起こることによって発生すると推測される需要量より算出された合計額を指すこともある。

行政もアクティブな地域内経済効果を産む金の使い方をやるべぇ！

と知恵を絞って行けるなと思ったら総務省からアカン！となった。
いやそれでもやるべ、で効果は半減以下だが似た事をやった。

しかし、理解度が低くて残念ながらあんまりウケなかったｗｗ

いつか別の手でやるべ・・3店方式（パチンコ屋の換金）か・・などとたくらんでいるうちに平成の合併で、肝心の町が亡くなってしもうた（笑）

ずっこけた（笑）

さて・・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！

Blenderでのレンダリングtest

Blender レンダラー   

Cyclesレンダラー

とても古いデーター（2000年前後）を読み込んでレンダリングしてみた。（Dazstudioで作成-3ds maxでボーン編集)モデルの出来は問題外ww

上からblender Cycles Pov-ray.。

Cyclesはマテリアルテクスチュア方法も違うので認識しない、無いのと同じ。

blender は 3ds maxのVrayで使ったマテリアルの残滓（カラーマップ等）があって当時に近い。

が、透明のマスクマップが駄目（3dsと考え方が違う)になっているので、厚化粧状態（まつ毛アイラインなど細かな表現がベタ塗りww）になっている。衣服の干渉も上手くいってない。

pov-rayも似たような物だが衣服に関してはきちんと計算出来ていてむやみに肌を露出するような事はない。真面目だ（笑）

Pov-ray　レンダラー

Blenderでsketchupを読み込む。

やはりエラーが出た（笑）
設定はこのページ

Blenderは目的に関する予備なのであまり気にしない。
ただし、壁面が或る周期と方向性をもって変形する建物の場合には活躍するかもしれない。ブニュっとやわらかい建物とか（笑）

エラーの原因はコンポーネントとグループ。sketchup独特の仕様がやはり難しい。それらは全て固定名コマンドで処理する必要があるかもしれない。
ただし、全ての部材が分解状態で、崩壊でもするのでなければ、一括にまとめたデーターとなるFBXで出し入れした方がはるかに簡単。

ドームのコロニー・・だったのが欠けている。

デフォルトカラーのモデルなのでレンダリングは色気が無いが、その時間はどちらも1秒もかからない。この他Povrayもセッティングしてあるのだが、このデーターの様に欠落したことで矛盾が出ているような物には落ちる。

前のページで女性の目の角膜と光彩の間に無限ぽい反射を仕込んだら、もう2時間以上かかりっきりになっている。
どこまで行っても基本に忠実、真面目なソフトだなぁ・・・。

CyclesとBlenderのレンダリングは全く同じ条件でやっているけれど、これだけの開き。これ考え方が全く違うレンダリング方法なのでこうなる。

Cyclesは物理レンダリング　Blenderはサーフェースレンダ（そういう分類があるのかどうかは知らない）。Cyclesはデジタル、数値が主体での表現。もう一方はアナログ。光がどうトレースされるかと「こんな柄で一つよろしく」との違い。

後者の方が今までのパースソフトのレンダリング。元はサンプル画像なのでリアルさを頑張ると大きな画像になる。それを読み込みのに時間がかかるのが欠点。前者のは、光の挙動を追跡しどうねじ曲げられていくのかを計算して味付けにちょこっと小さな画像を使う。これが思うように行かない。

目の前の物の見え方を数字に表せという事なのでもう大変。ｒｐｇゲームなどを見ると建物素材はがさついた素材一辺倒。
あれ、レンダリングエンジンはデジタルでも作るのが難しい事の裏返し（笑）

その点アナログは何もしなくてもそれなりにくっきりしていてわかりやすい。

ゲームエンジンはどちらかと言うとデジタルだけど、unutyはアナログも出来る。UE4も出来ない事は無いが・・・マテリアル設定は時間差がある。　UE4>unityかな？

Cyclesレンダリング

Blenderレンダリング

ま、Blenderとsketchupは相性がさほど良くない事は判ったので寝る。

さらば3ds max! これからはBlender。

3ds maxがHDD故障と共に亡くなったのでBlenderを強化しておこうと設定ファイルをいじり倒すも返り討ちに合う（笑）

sketchupのファイルが直接読めたらいいなと思ってたらナニかそれらしきものがあった。いろいろ調べてみたら、インポーターを作っている人もやる気が無いみたいだし、読み込みに成功したという話は全然ない。（まぁ戦略上これは・・）

でもやって見たのが一枚目の画像。　

今のblenderは、日本語も選べるのでよい（昔は・・以下略）。プログラムの失敗ラインエラーの報告が出るけど、直す気もなし。これはボツ。

twinmotionやLumionなどでは人も車も動く。んじゃぁ動く人間も何とかせにゃならないのでmakehumanをアドオン（プラグインの意味）した。CMをしている映画ゴースト・イン・ザ・シェルっぽいがまだ動かない。（動かせるのか？ww）

もしかすると僕の建築プレゼンはオールヌードになるかも知れない。服を着せるのは結構メンドクサイ（笑）

ゲームエンジンのカメラテスト（ようやく始めた）

忘備録。

ゲームエンジンUE4のDOF。

sketchupからならばunityの方が楽なんだけど、あえてUE４を選んでいる。

これ、他人と同じことをやるのが嫌いという事ではなく、色んなこと物を比べて後に続く人が選べばいいという事。

建築のプレゼンテーションが、twinmotion Lumion Atlantisなどの時代に入ってきている今、僕が出来る事はコッチの方だろうな。その中の選択肢の一つ。（podium　waker　も経済的だし中々良かった。急ぎの時はこれが一番早い）

モデリング・テクスチュアを一通りこなしてなければしんどいのだが、幸いそれは何とかなるのでチャレンジし始めた。

建築プレゼンテーションは、広大なゲームエンジン分野の中で言えば、レベルデザイナーに位置する。ゲームでは、レベルと言っても高低や程度を表すのではなく場面の事をレベルと言っている。

そのゲームエンジンの機能の一部を抜粋したとも言える先の3つの中のソフトで、twinmotionは建築パース技術者には簡単に使える良いソフトだ。だが試用版のせいなのか、理解度が低いのか、僕には満足のいくコントロールが出来なかったDOF（被写界深度）.。これをまず確かめたい。

一般の建築写真ではボケはあってはならない。もう、カリカリに絞って長時間露光の上、更に3次元的歪みを矯正して平行性を強調する。建築パースソフトもその影響で、全てのポイントにピントが合うピンホールカメラでの設定が主流になっている。

だが、写真の商品撮影分野では、ピンホールカメラよりも、光がたくさん入るレンズの明るい（大きい）カメラで、ボケやピントなどのテクニックを駆使して商品の素材感を表現する。一般写真では当たり前なのだが、建築写真分野だけが異質なのだろう。

建築写真は物や素材を撮るのではなく、空間を映すという目的なので、それも必然。なのだが動画のプレゼンテーションとなると事情が違って来る。それにVR・ARが要求されるようになるとちょっと焦る。

-------------

で下の画像。　前から2列目、右から2つ目だけにピントを合わせている。

カメラはDSRL　レンズは50mm/ｆ＝1.8/距離473mm。を再現した。

何のことは無い。違いはそう感じられないだろうけど、僕にとってはとても重要な事。

正直ゲームエンジンをなめていた。一部機能しか使わないからと気軽に始めたが、これはとんでもなく広大な分野。機能すべてを使いこなす自信も気力も、全然湧いてこない。プログラム・音楽・ビデオ編集に加えて、実際の撮影技術や物理の知識まで・・。ウワズミしかなめてこなかったので、浅学がバレる（笑）

360 CG動画のwebテスト

ここではダメだね（笑）

360CG動画のテスト

FaceBookで試してOKだったので、そのコードを埋め込んでみる

3dsからGE（UE4)でのアニメーションを見た感想（忘備録）

インテリアアニメーション。

室内での動きのある物は無い。
それならばUE4アニメーションの必要が無いような気がする。

GEのカメラワークは割と難しい。
SU Animate と podium wakerとの組み合わせの方が楽で、自然な視線も得られる。（ただし被写界深度やタイムラインコントロールなどを駆使した映像は苦手。出来ない。）確かにpodium　wakerのライティングは品質が低い。でも、それを補う方法もある。

でも・・・どうしてもわからない事が・・・。
もしも、このアニメーションを作るのが目的だったら・・GEなど必要ない。

3ds max単体の方にはもっと使いやすいカメラがあり、カメラコントロールのタイムラインもあって、マテリアルも相当出来るし、デフォルトのレンダラーでも（Vrayじゃなくても）かなりの高品質の物が出来る。

Blenderでもこれより同等以上の物が可能だ。

上のタイムラプス　1時間9分

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を、今までの映画やアニメーションレベルの高品質で」となると、今の所、最低このぐらいは頑張る必要がある。

水の修行

地理風水要素（木火土金水）修行中だが、怠けたデーター（そうとう昔のsketchup）を使っているので緊張感が無い（笑）

メモ：ベイク

メモ：

そうか・・・　　これが静止画像レンダリング方法との違いか。