Illustrator の画像トレース

トレースの設定を高精細でかけてみたら、うまい人の絵画タッチのようになって感動している。

f:id:ysok_na:20170723035508j:plain


拡大するとこんな感じ
f:id:ysok_na:20170723035659p:plain



元の画像はこれです

f:id:ysok_na:20170723035543j:plain




.

Blender 忘備録

Blender を雰囲気で使っているので
何度も似たようなのことを検索していて効率が良く無い。

ここを忘備録とします。

・-・-・-・-・-・--・-・-・-・
随時追加していく予定です。

・-・-・-・-・-・--・-・-・-・

コンポジション のための レイヤーについて

レンダーレイヤー についてはこれ
【Blender】レンダーレイヤーとは?【シーン・マスクレイヤー・インクルード・パス】

基本的なレイヤー操作はこれ
オブジェクトを選択し、「 m 」でレイヤー移動
【Blender】レイヤーの使い方【移動・表示】


.

アルファテクスチャ

アルファを持つ PNG 画像を使うときのノードの組み方はこれ
アルファテクスチャマッピング - Blender Cycles memo


.

オブジェクトの親子関係

親子関係の作り方はこれ
「 Ctrl + p 」で追加、後から選んだほうが親
「 Alt p 」で削除
blenderメモ: オブジェクトの親子関係


.

キーフレーム について

キーフレームについて
【Blender】キーフレームとは?オブジェクトをアニメーションする方法


キーフレームの追加と削除 について
「 i 」 で追加
「 Alt + i 」 で削除
【Blender】キーフレームの追加と削除方法


.

グラフエディター について

2点を選んで「 t 」でデフォルトの関数
【Blender】グラフエディターの使い方【キーフレーム,F-カーブ】






.

Remove all ads

坂茂 の プロジェクツ・イン・プログレス を見てきた

ギャラリー間 で行われている 坂茂 の プロジェクツ・イン・プログレス を見てきた。
www.toto.co.jp


モックがすごいという噂もあって期待して行ったんだけど、結構残念な感じだった。


坂の紙の家や、カーテンウォールの家、三日月の家、ポンピドゥーメスくらいしか見たことがなかったし、
特に大好きで追いかけている建築家というわけでは無いし、残念とも言えないのですが、全然良くなかった。


上で挙げた作品みると、造形はわかりやすく、悪い言い方をすれば、大味である。


それと同じレベルで、今回の展示にあるような、超大型建築でもやっている。大味すぎる。
それがすごく気になって、あまり良くなかった。あまりというか普通に良くなかった。
解像度がバグってるようにしかみえなかった。
1/300の模型は、部材なんて見えないくらい(3m が 1cm になるので)のはずなのに、
(多少のデフォルメがなされていたとしても)模型でははっきり部材が確認できたので、冷静に考えてもやはりバグっている。


近年は、木材の大架構をやっているようだけれど、かなりスケールアウトしているように見える。
規格品を使うから安いのであって、大きな木材買って、継ぎ手加工やってとなると、コストが安いわけでも無いし、
木材使うメリットなさそうだった。耐用年数も気になる。


ラ・セーヌ・ミュジカルのコンセプトの鳥の巣、
北京のヘルツォークか?w、みたいな感じなのもあったし、
羽のイメージの帆?、羽というか、もはやバリアであった。


富士山世界遺産センターも水面に映ると富士山みたいなのも安直すぎる。


事務所のウェブサイトで、作品を見たが、
展示で感じたことは全体的にどの作品でも言えて、あまり好きではなかった。



紙の家↓
SBA_Paper House
授業でスケッチアップで紙の家のモデリングしたものを、プリンタ屋で出力したのを見つけた。サポートなしなので空中になるところが汚い。
f:id:ysok_na:20170705002714j:plain

カーテンウォールの家↓
SBA_Curtain Wall House

三日月の家↓
SBA_Shutter House for a Photographer






一応模型の写真です。

ラ・セーヌ・ミュジカル(La Seine Musicale)
f:id:ysok_na:20170705000529j:plain
f:id:ysok_na:20170705000526j:plain


台南市美術館
f:id:ysok_na:20170705000720j:plain


富士山世界遺産センター
f:id:ysok_na:20170705000944j:plain





.

Remove all ads

伽藍とバザール を読んだ

伽藍とバザール(原題 The cathedral and the Bazaar)」 エリック・S・レイモンド 著、山形浩生 訳 を読んだ。



伽藍とバザールの概要は、 Linux 用語辞典より概要を引用します。

1998年にEric Raymondによって書かれたオープンソースに関する論文。ソフトウェアの開発の方法論として、伽藍方式(Cathedral)とバザール方式(Bazaar)があるとし、Cathedralの例としてFSFを、Bazaarの例としてLinuxを挙げている。この文書は、Netscapeオープンソース化に影響を及ぼしたとされている。


Cathedralとは、設計者がすべての計画と体制を確立して開発する、企業などで一般的に行われている開発方式をいい、あたかも大聖堂の建築を行うがごとく厳かで大がかりであることを指す。これに対してBazaar方式とは、知らない者同士がバザーで売買を行うようにアイディアや技術、またはソフトウェアそのものを持ち寄って互いに交換しながら作り上げていくことを指していると思われる。


Bazaar方式では、全体をとりまとめる責任者がいないにもかかわらず、それなりの秩序を保ったコミュニティが成立している。Bazaar方式が有効であるためには幾つかの条件があり、まず開発の最初から始めることは難しく、とりあえず何か動くものが必要であること、最初はそうでなくても、将来よいものに発展していくであろうということを開発候補者たちに納得させられること、また参加者の意見やアイデアを受け入れることができることが必要であり、コーディネーターやリーダーの対人能力やコミュニケーション能力が優れていることが不可欠であるとしている。

Linux 用語辞典(http://www.atmarkit.co.jp/aig/03linux/candb.html

.



建築設計の手法において、この「伽藍とバザール」は多く参照される。


厳格な設計図を決め、トップダウンで作られる商用ソフトを、伽藍(もしくは原題より直訳し大聖堂)とし、
オープンソースフリーソフトウェアとして全世界の多数の人間が参画しているにおいて Linux や、著者が開発を受け継いだ fetchmail 等を、広場で開かれるようなバザー、市場と例え、
すごく簡単に言うと、多数の参加、住民参加の方が良いものになるよ、ということとされることが多い。



それに対して、Linux や、 fetchmail の開発に参加している人は、
素人ではなくある程度コンピュータの知識がある人(その程度というのは、MicrosoftIBMで働いている人間も参画しているとされる)であって、
建築について素人であるその辺の子どもや、あの辺のおばちゃんをとっ捕まえてきて、建築設計に介入させれば良いのとはまた違うという批判があり、これもまた多く挙げられることだ。



この批判に対して幾つかの例を挙げると、
50回のワークショップを行い、外観のイメージや欲しい機能などを洗い出した新居千秋の大船渡リアスホールや、
工事中のシェアハウスに入る予定の住人にたいし、複数回のワークショップをして、問題が起こる前に事前リノベーションを行ったツバメアーキテクツの荻窪家族プロジェクト、
複数回のワークショップを行い、その都度、部屋の数や機能について投票によって枝切り、切断した平田晃久の太田市美術館では、
建築について素人である子どもや、おばちゃんにも設計に介入できるようにオーガナイズされていた(ようだ)。

大船渡リアスホール↓
PROJECTS / CHIAKI ARAI URBAN & ARCHITECTURE DESIGN

荻窪家族プロジェクト↓
[事前リノベーション・まちづくり・ワークショップ] 荻窪家族プロジェクト | ツバメアーキテクツ - TSUBAME ARCHITECTS

太田市美術館↓
施設概要 | 太田市美術館・図書館 ART MUSEUM & LIBRARY, OTA




最初のオープンソース万歳という誤読(?)を乗り超え、
それに対して、(色んなところに多く書かれている)素人が設計に参加するのは違うという批判があった、これも理解し、
そろそろその次の段階として、
うまくオーガナイズできれば、素人であっても参加できるようになる、
オープンソース的な、多の力をうまく利用したデザインにつながるのではないか、
そういうテイストで、このテキストをまとめにしようと思います。






あとは上の内容と直接はつながりませんが、気になったフレーズを載せておきます。

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

とても大事、心がけたい。


自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。

気をつけたいです。


(デザイン上の)「完成」とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。

これは、アントワーヌ・サンテグジュペリ(かれは児童書の古典を書いていないときには、飛行家で航空機設計家だった)の言葉だそうです。深いです。


おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。

よく言われますが確かにそうだと思います。





(終わり)



.

Remove all ads

関係代名詞の和訳

まれにある、文章の主語述語の間に他の文章が挿入されているような文章は、
関係代名詞の和訳の仕方から来るのかもしれないと思った。


わかりやすい例や、原文も見つかる資料が手元にないので、仮説です。


英語の例文集より

The camera which the clerk showed me was very expensive.
店員が私に見せたカメラはとても高価なものだった


この例文を、英語の順番通りにこのようにも訳すことができる。

そのカメラは、店員が私に見せてくれた、とても高価だった。
そのカメラは、(店員が私に見せてくれた、)とても高価だった。

英語は頭からそのまま読んで戻ってはいけないという指導もあります。



これは簡単な文章だからなんとも言えないが、
こだわって描写されている小説や、複雑な言い回しをするエッセイなどの、
長く文章、日本語にしにくいものをそのまま訳した結果、
文章の主語述語の間に他の文章が挿入されているような文章になっているのかもしれないと思った。




.

Remove all ads

Shape optimization について

前回の投稿のものについての追記。


Fusion360 での結果と、磯崎の実物を比較すると、柱の複雑さが全然違う。
これはおそらく、解析時に計算する力の数(つまりパラメータの数)だと思う。


Fusion360 では、鉛直の荷重だけしかかけていないが、
実物は水平方向の力や揺れ、回転なども加味しているだろう。


複雑な解析についてネットで検索する。




shape optimization 系のソフト、Autodesk Within や
www.autodesk.com
grasshopper のアドオン、millipade
www.grasshopper3d.com


この辺の資料を見ていると、複数のパラメータのもとで、シミュレーションすることで、
もはや理解不能な形態が生まれている。




Within によるアンダーアーマーのシューズのソール。
f:id:ysok_na:20170623080333p:plain
www.arch2o.com



adidas のシューズのソール



Autodesk の解説
f:id:ysok_na:20170623080622p:plain
www.autodesk.com





高度な解析によって人間の理解を超えていきそうで、
(最後のAutodesk の資料等は特に)、デザイナーは関与しなくていいよ(できないよ)、という風にも見えました。うーんn...





.

Remove all ads

Fusion360 の shape optimization

Autodesk Fusion360 の shape optimization の実験。

目指すイメージは、磯崎新設計のカタール国際会議場。
(The Qatar National Convention Centre)


Qatar National Convention Centre | Homepage
f:id:ysok_na:20170618224410p:plain



ファザードが佐々木睦朗の構造解析によってできている。
具体的には、屋根面だけ決めて、かかる力をシミュレーションし、形態を最適化している。
f:id:ysok_na:20170618204845p:plain


まずは、ベースのソリッドを作る。
適当にプロポーションを真似ながら2分くらいで完成。
f:id:ysok_na:20170618205018p:plain


ここからシミュレーションし、形態を最適化する。
参考にしたのは、適当に検索をかけた動画や、この辺り。
Blog | D3 Technologies



かかる力を設定して、いざ解析。


なんかダサい。
真下に落ちただけに見える。
f:id:ysok_na:20170618205440p:plain



設定を見返してみる。
材質がスチールになっていた。


鉄のせん断に対する強さみたいな何かだろうな、と予想し、コンクリートに近いような材料に変える。


木材や銅よりも、ABS樹脂の方がコンクリートっぽいんじゃないかなと変更。

ここでプロポーションをいじってしまったので、材料の設定だけが変わったから結果が変わったわけではないですorz


再度、解析する。
いい感じに見える。
f:id:ysok_na:20170618224504p:plain


パラメータをいじってみるとこんな感じ
www.youtube.com

プリントした。
f:id:ysok_na:20170620162242j:plain


サンプルを動かしたようなだけで、まだなんとも言えませんが、
割と考えていた通りのシミュレーション結果がでて良かったです。


上手く使えるように頑張ります。




.

Remove all ads

FFmpeg

連番の画像や、動画のGIF化などに便利そうなのでいれてみた
FFmpeg

homebrewのセットアップなどして、コマンドをコピペでインストール。



連番の静止画から mp4

// cf, 00001.png, 00002.png : %05d.png
ffmpeg  -i pic%05d.png movie.mp4

f:id:ysok_na:20170610180147p:plain


mp4 から gif

ffmpeg -i input.mp4  -an -r 15  -pix_fmt rgb24 -f gif out.gif


参考にしたのはこの辺り
複数の静止画から動画を作成する:tech.ckme.co.jp
http://takuya-1st.hatenablog.jp/entry/2015/07/15/002701




.

Remove all ads

Pixel Blender

https://twitter.com/_baku89/status/872612843840913408

橋本麦さんの言及している Pixel Blender という名前の実験映像のようなものがあって、好きなんだけど見つからない。
このリールの46秒以降に少し出ていました。
vimeo.com




最近モザイクの時に、 i X j 行列をつかったので、それをそのまま使い回せばなんかできそうな気がする。


2枚の画像のピクセルの色を、それぞれの係数を掛けてあわせる。
係数は時間軸からとる。
colorのデータ型をそのまま使うとなんか良くなさそうな気がしたので、それぞれRGBに分けた。

    // PImage img1, img2
    // 2種類の画像を読む

    // pick , expode RGB
    color c1 = img1.get(i, j);
    int r1 = int(red(c1));
    int g1 = int(green(c1));
    int b1 = int(blue(c1));

    color c2 = img2.get(i, j);
    int r2 = int(red(c2));
    int g2 = int(green(c2));
    int b2 = int(blue(c2));

    // remap
    float m = abs(map(count, 0,600, -1, 1));


    // set color
    stroke(int(r1*m + r2*(1-m)), int(g1*m + g2*(1-m)), int(b1*m + b2*(1-m)));

    point(i, j);

    // あとは、 saveFrameで書き出す。


書き出された後の画像を gif にするなり、動画にするなりするとき、面倒な作業をしたくないのでFFmpegを入れてみた。

gif
f:id:ysok_na:20170610182751g:plain



FFmpegでの、連番の画像の動画化、動画の gif 化ができた。
なんか思ったような滑らかさが出ない。
多分、係数の単調増加(変化)とかそのへんか、素材か、1コマあたりの速度か。
細部のつめが必要です。

このプログラムでは2枚の画像がそれぞれ単調に変化している。
f:id:ysok_na:20170610182804j:plain


sin波のようなものも考えたが、m と (1-m)では、
和が1なので全体の色の明るさが変わらないが、sin波などでは1より小さいタイミングが出てきて、そこでは多分全体的に暗くなる。



あと考えられるのは、いまは一コマ一コマ同じ速度で進んでいるけど、その時間に差をつけてもいいのかもしれない。



.

Remove all ads

Processing でモザイク

Processing でモザイクにするプログラム

とりあえず素材は、Macintosh / Library / Desktop Pictures の中の画像を使った。
良い画像が多い。

そーす

  // setup() で画像を読む

  // array
  for (int i = 0; i < width; i = i + n){
    for (int j = 0; j < height; j = j + n){
      
      // pick color
      color c = img.get(i+n2, j+n2);
      
      // set color
      fill(c);
      
      // draw rectangle
      rect(i, j, n, n);
    }
  }

色を拾う座標の部分をちょっと間違えたまま、
モザイクに加工して GIF にしてたことを、
ここでまとめていたら気がつきました...
上のソースは修正済み。


f:id:ysok_na:20170606201338j:plain
f:id:ysok_na:20170606201353j:plain
f:id:ysok_na:20170606201408j:plain



gif

f:id:ysok_na:20170605011438g:plain
f:id:ysok_na:20170605011833g:plain
f:id:ysok_na:20170605011837g:plain
f:id:ysok_na:20170605011847g:plain





この辺を読んだので、GIF の制作をしてみた。
ループする絵として、モザイクになって戻るものにした。

もうひとつ,「GIF」を考えた文章として挙げられるのが,インターネット・リアリティ研究会の始まりの座談会です.そこに「GIFとJPEGどっちが硬い?——Webの質感と〈インターネット・リアリティ〉」という一節があります.そこで,エキソニモの千房さんが「GIFとJPEGはどっちが硬いと思うか?」という問いを出すわけですね.


インターネット・リアリティ研究会
座談会「『ポスト・インターネット』を考える(β)」より
http://www.ntticc.or.jp/ja/feature/2012/Internet_Reality/document6_j.html


.



あとは、モザイクをやってみようと思った理由として、ファンが撮った橋本環奈の奇跡の一枚の転載ネタから。
ファンが撮った一枚の画像がどんどんと転載され、時にはスクショや、トリミングなどの編集が施され、今では解像度が落ち、とても小さな画像になってアップロードされている例が見受けられる。
しかし、そのように小さな画像になっても、顔の表情が見れないサイズでも、全体の色の感じであの橋本環奈の奇跡の一枚と認識できる。
作っている途中で、あの画像(画質)の劣化、劣化した場合、どこまでが認識できる写真で、どこからが認識できないゴミになるのかな、いうことも少し制作のときにどこかにあった。気がする。


ネットで少し見る限り、最大は、 6000 X 4230 、最小は、 100 X 70 くらい?

f:id:ysok_na:20170606200655p:plain
f:id:ysok_na:20170606200709p:plain


f:id:ysok_na:20170606200726j:plain
f:id:ysok_na:20170606200745j:plain

100 X 70 の画像を iPhone で見るとこんな感じ…
f:id:ysok_na:20170606202043p:plain



_

Remove all ads

アプリケーションを綺麗に使う

ソフトウェアを綺麗に使う、という最近の目標があります。



仕組みよくわからんけどなんかできてるとか、使い方おかしいけどなんか良いとか、
それはあとあと苦しい。みたいな使い方を出来るだけしないようにしたいです。



どのアプリケーションでも言えるのが、オブジェクトやレイヤの名前付けや分類などの管理を適当にやる。

フォトショのレイヤの合成の減算とか対等に選んで良さげなやつにした。

ブレンダーでマテリアルの設定で、複数のノードを無駄にミックスしまくっている。

ライノでフィレット等でサーフェスが汚い。

グラスホッパーアルゴリズムに無駄が多い。




どれも使えていると言えば使えているけど、後での修正がめちゃくちゃ面倒だし、
それが資産としてストックになっているかと言えばなっていない気がする。




テレビを見ていたら、プロの料理人が指導して、素人の芸能人が真似して作るヒルナンデス?のコーナーがやっていた。


プロの料理人が作りながら片付けもしていて料理の完成の時にキッチンが綺麗になっているが、
素人の芸能人は使い終わったボウルをその辺においたり、菜箸をシンクに入れてしまって新しいものを使ったり、
また、ごちゃごちゃしたまま進めているので、入れる材料を飛ばしてしまったりしていた。


料理でも、アプリケーションでも、上手い人はそれを綺麗に使えるのだと思いました。

Remove all ads

Belnder と Unity

CGを用いて映像を制作する時にソフトを比較した際のメモ。


Blender は、ニコニコ界隈のメイキングがあり幾つか見てみる限りかなり良さそう。
個人的に切り出した映像ではなく、アプリケーションとして作って、
演算し続けるようなものをやってみたい、という気持ちもあったので、 Unity も触れてみた。


Unity を触れるにあたり、情報デザイン学科の谷口暁彦先生の
ヴィデオゲームアートのための Unity 講座の資料を参考にした。資料はこれ→( http://okikata.org/gameart/ )

Unity

  • メリット

いわゆる3Dゲームのような具象的な表現が得意
物理演算、ライティング、フォグ、被写界深度などはコードを一切書かずに実現できる。
出来合いのアセットなどの組み合わせが豊富なので、箱庭的に空間を構成できる。

  • デメリット

逆に抽象的でジェネラティブな表現は苦手。
アセットを追加すると自分で書いていないコードが大量に入ってくるので、
エラーやメモリリークがあった場合、原因を探すのが結構大変
そしてやや不安定になる場合も。

( Intoroduction より http://okikata.org/gameart/introduction.html


以前、さくっと写経したのがこれ↓
www.youtube.com



以前触って、そして今回また少し触ってみての感想は、
谷口先生の言葉を借りますと、Unityは箱庭っていう感じがすごいしっくりきた。


うまく言葉にできないが、
すでにできている強固なプラットフォームに自分で作ったものを乗せて行く感覚。
コードもりもり書くような制作をしてないからかもしれませんが、
Unity の開発環境が凄いしっかりしたプラットフォーム(=土台)なのですが、
土台がしっかりし過ぎていて、自分で作品を作っているって感覚よりも、自分の作品をそこに置く、みたいな。


f:id:ysok_na:20170530044454p:plain
箱庭キットというものが最初にあって、そこに、市販のジオラマ用の樹木とか標識とかをおいて、
あと少し自分で作った何かを設置するみたいなイメージに近い気がします。


ふと某所で見た鉄道模型を思い出しました。
鉄道模型で、ある程度は、市販の樹木やビル、電線などを買ってきて設置し、
市販されてない東京スカイツリーや新型車両は、自分で作って設置する。
結果、市販のものと、自作のものと混在していて、模型全体ではうまくできている、みたいな。
(そして、谷口先生は最近、鉄道模型に凝っているような)


Unity とあまり仲良くなれなかったので、今回は、 Blender でいきます。
今後は、きちんと勉強して、 Unity をうまく使っていきたいと思います。

Remove all ads

Motion Blur のサンプル

サンプルを拾ったのでシャッタースピードによる結果を比較

File:Blender2.65 motion blur.blend - BlenderWiki

ファイルはこんな感じ。
上からカラフル箱が落ちてくるので、その途中の瞬間をレンダリング
f:id:ysok_na:20170529035853p:plain

短いほど、ブレが無くなりますたぶん。


モーションブラーのシャッターのパラメータです

0.0 Sec
f:id:ysok_na:20170529040057p:plain

0.2 Sec
f:id:ysok_na:20170529040119p:plain

0.4 Sec
f:id:ysok_na:20170529040155p:plain

0.6 Sec
f:id:ysok_na:20170529040235p:plain

0.8 Sec
f:id:ysok_na:20170529040254p:plain

1.0 Sec
f:id:ysok_na:20170529040400p:plain

1.2 Sec
f:id:ysok_na:20170529040435p:plain

1.4 Sec
f:id:ysok_na:20170529040447p:plain

1.6 Sec
f:id:ysok_na:20170529040504p:plain

1.8 Sec
f:id:ysok_na:20170529040519p:plain

2.0 Sec
f:id:ysok_na:20170529040537p:plain

Remove all ads

Making of Oyasuminasai

’ 夜空の画像を作るメモ ’


まず Rhinoceros

ローポリで作ると軽いので、後で幸せ。
3角メッシュのミラー、環状配列で星にする。
vertex 12 / face 20
f:id:ysok_na:20170527190823j:plain


この辺はミス、かっこいいけど
f:id:ysok_na:20170527190830j:plain
f:id:ysok_na:20170527190835j:plain


背景用にパーリンノイズでポリメッシュと、(ぺらのメッシュにしました。)
ランダムに星を配列。
f:id:ysok_na:20170527190840j:plain


パーリンのメッシュは、単独で背景用マスク用にレンダリングして画像にした。
あとでテクスチャにする。
f:id:ysok_na:20170527191331j:plain


FBXで書き出し。
Rhino から Blender では、FBXでは回転してしまう。
STLでは回転しないが、離れたものも1つのオブジェクトとして認識されるので駄目。


ここから Blender

インポート
f:id:ysok_na:20170527192028p:plain


星を光るように設定。
放射シェーダーなど。
f:id:ysok_na:20170527192127p:plain


レンダリング結果。
f:id:ysok_na:20170527192233p:plain


コンポジション機能でブラーをかけた。
f:id:ysok_na:20170527192346p:plain


1枚目のレンダリング画像と、ブラーを合わせる。
ミックスのやつで比較で合成。
f:id:ysok_na:20170527192430j:plain


平面すぎるので、奥行き感を与える。
星の間に半透明の画像をレイヤとして重ねる。

// 追記
奥行き感を出すための半透明レイヤなどしたが、
コンポジットのノードの中にカメラ距離の様な機能があった(それはそう)
フォグ、被写体深度 etc...
機能が多くあったのでちゃんと勉強しないといけない。
// 追記ここまで

f:id:ysok_na:20170527192622p:plain


奥行きの工夫のレンダリング結果、良い感じ。
f:id:ysok_na:20170527192947p:plain


奥行きのレンダリング画像に、前述のコンポジションを加える。
それと同時に、Rhino で最後に作ったパーリンの画像テクスチャを差分で合成する。
f:id:ysok_na:20170527193347p:plain


とりあえずその結果。
パーリンのテクスチャが、なんとか銀河なのかなんとか星雲なのか、よいムラになってよかった。
f:id:ysok_na:20170527192848p:plain


Blender メモ
ガムボールの位置の修正はこれ
オブジェクト > トランスフォーム > 原点をジオメトリの重心に移動
f:id:ysok_na:20170530071235p:plain


グラフエディターで2点間の補完の種類が選べる
2点を選択して、” T ”
今回は等速で動き続けてくれれば良いので、リニア
ここが詳しいです→( http://blender-cg.net/graph-editor/
f:id:ysok_na:20170530071626p:plain


動きを表現するぶれ、モーションブラー
うまくいかなかったので、今回はこれでないものでやろうかと思います
一応、サンプルファイルの検証を次の記事に入れました
f:id:ysok_na:20170530072230p:plain


透過にチェックを入れ、アニメーションとして動くものだけレンダリングし、
背景は、次のコンポジションで処理します。
f:id:ysok_na:20170530072610p:plain


動きのぶれをモーションブラーではなく、コンポジションでやります。
レンダリングした画像を保存して読み込むのではなく、
そのままコンポジションするときは、ポストプロセシングのチェックを入れます。
ノードエディターがいくつか見えていて気持ち悪いのですが、マテリアル用とコンポジション用です。
f:id:ysok_na:20170530072341p:plain


コンポジション用の設定を終えたら、アニメーションのレンダリングを始める。
今回は、動くもの5個だけ、背景はコンポジション処理なのでとても軽い。
www.youtube.com


コンポジションについては、できる人はこのようにやるようだ。
きちんと勉強しなければ...
CGcompo Blenderでコンポジット!


コンポジションがよくわからないものを、上のリンク内のキャプチャ画像を見てみる。
Photoshopの普通のレイヤのように重ねる方法は、
カラー > アルファオーバー のノードでできた。
プリマルチを1.0にする。
f:id:ysok_na:20170602000403p:plain









あとは、直接関係のない Mac OS の Chips ですが、Blender のような、起動している1アプリで1プロジェクトだけ開くようなソフトで、複数プロジェクトいじるには、複数の同一アプリを開くしかない気がする。
その方法は、 Terminal.app で、通常の

open hoge.app

ではなく

open -n hoge.app

で開くと、同一アプリの複数起動ができる。便利ですね




_

Remove all ads