たけなか制作日誌

色々なテクスチャを描き描き。少しずつ調整中です。
更新するほど進展してないですね苦笑。

3Dで背景を制作するための資料を集めたりしていく内に、
ふと思ったことがあったのですが。ファンタジー・幻想的な
風景っていうものを、今まで漠然としか捉えていなかったけど、
例えばヨーロッパのとある民族の村であったりしても、色々と
違う特徴が多い中で、何か懐かしさや親近感を感じるようなものがある。
そういった部分を取り上げていくことで、世界中の誰がみても
同じようにファンタジー・幻想的といった感情を風景から
思い浮かべることが出来るのではないのかなと思いました。

何気なしに気がついたことなので、結構おかしなことをいっているのかも
しれませんが。。別の例でいうと、FF12のデザイナーの人の話で、
風景をただ現実そっくりのもので作っていくとファンタジーな風景に
ならないので、現実にない部分を取り入れていくという話が
本に書いてありましたが。これはただ現実ばなれしたものを
作ってしまうと、何だかおどろおどろしいものになるのではないか
という気がします。つまり、ファンタジー・幻想的というのは
ただ非現実的なのでなくて、どの部分を見ても「ああ、何となく
見覚えがあるな」っていう部分が必要なのではないかと、そう思いました。

そう考えると、ファンタジー系(？)のイラストやゲームに
厚塗り風のフラットなタッチで描かれることが多いのも合点がいきます。
つまりディテールをしっかり描いてしまうと、特定の地域限定の
種類のものになってしまうのです。
いうまでもなく、決して手抜きなのではない！笑。

今日はネットでゲームのプレイ動画をみたりキャプチャしたりして
資料集めをしながら、制作用のラフを描いたりしてました。
キャラクターはデザインを決めるのがすごく難しいですね。

そういえば、息抜きに今までよく分からなかったCUDAについて
調べてみたのですが、実はこいつ、GPUとCPUを並列プログラミングさせる
言語だということが分かりました。おおー。

え？よく分からないって？

僕も今までよく理解していなかったので、あまり説明できないのですが。
以下、いつもより少し長めに説明します。

まずはじめに、DirectXやOPENGLのような3DグラフィックスAPIは通常、
座標変換やラスタライズといった処理はCPUだと重たいので
GPUによってそれらを処理させております。
GPUはCPUと違い頂点やピクセルの計算を１つづつではなく並列して
一気にまとめて計算できるように作られているので、CPUよりも
かなり高速に処理できるわけです。

が、しかし。このCPU-GPU転送間には問題もあるのです。
まず第一にCPUからGPUのデータにアクセスしたり、
メインメモリのデータをGPUに転送したりといった処理自体が
重いという問題があります。いままで何回かこの問題で四苦八苦したので
結構この辺は分かりやすいですね。

それ以外に今回発見した問題。それは…。
GPUにデータを転送した後は、実はCPU側では何も処理を
せずにじっとしていたということです！まあ考えたら、そりゃそうですよ。
あるオブジェクトをGPUが描画計算している最中に、
CPUから「これお願いしますねー」っていわれて、次から次へと
命令を送られても、どうしようもないので。

じゃあ別にCPU側で何もしてない方がいいじゃないかと思うかもしれないですが
案外そうでもないんです。例えば、ゲームでは当たり前のように
当たり判定処理を必要としますが、これを毎回描画計算の
前もしくは後に行っていると、それなりに処理が重いんですよ。
けど、当たり判定に必要なフレームの座標値はオフセット行列から
あらかじめ取得できるので、GPUに転送する前のデータだけで
当たり判定が出来ちゃうのです。つまり、この処理をCUDAを使って
GPU計算時にCPU側で処理させることで結構高速になると。そういうことです。

それじゃさっそくCUDAをインストールしてみようと思ったのですが…。
仕様書をみてみると、僕のビデオカードが対応していない！！
GeForce8000系以上にしか対応してないようです。ががーん。
さらに付け加えると、nVidiaの自社のビデオカードに
最適化するように設計されているので、他の会社のビデオカードだと
利用できないという苦笑。

けど、OPENCLというAPIならCUDAと違ってマルチな設計に
してあるみたいです。まあ最適化されていない分、若干遅いようですが、
これならいいなと思ってネットで調べてみても。
…ほとんど情報が無いじゃないか。。おまけにOPENGLには
標準対応させているにも関わらず、DirectXには対応していないという。
DirectXはMicrosoft側が自社で設計を考察してるようですが、うーん。

結局、CPU-GPU間の並列プログラミングはここ2～3年にようやく
普及しはじめた技術のようなので。まだまだ発展段階のようです。
なので、まだ今の制作に生かすには早いように感じましたが、
最新の３D事情が少し位は理解できるようになったかなと、そう思いました。

それでふと思ったんですが。
わざわざそんなAPIを使わなくても普通にマルチスレッドプログラムを組んで
GPU転送前にスレッドを分けることでそれなりに速度向上できるのかなと
思ったんですが。どうなんですかね。

てか、CPUで頂点計算させる分、GPUの負荷が軽くなるなんて
今までほざいとりましたが(僕の本にそう書いてあったんですけどね)、
実際のところCPUで頂点計算させるメリットが全く無いね笑。
とりあえずシェーダで頂点計算させてみようかな。

あーでもない、こーでもない。そんな感じで最近は家の制作を進めておりました。
まあ、画像はいつもどおり中途半端な感じに逆戻りです。

そういえば。背景の制作を進めていると、なんだかキャラクターが
しょぼく見えてきたなあと思って。またネットで色々調べていたんですが。。
そんな中なんと、聖剣２がケータイでリメイクされていることを知りました！！

グラフィックが綺麗になってる！おまけになんといっても
キャラクターイラストがすごく上手い！

ディテールが上手いんですよ。当時のイラストでは描かれていない部分が
聖剣の風味を崩さない感じでデザインされていて。
僕も、まだまだ研究が足りないなあと思いました。

嬉しいことに、ぼおんさんから雲の作り方を教えて頂きましたので、
さっそくTerragen2を使って雲を作ってみました。

設定が甘くて少し雲が散り散りになってしまったのは、とりあえず
置いておくことにして笑。雲が前よりは結構いい感じになりました。

ちなみに今のところ、スペックの都合で雲のディフューズマップは
用意してないのですが、雲のように大きいオブジェクトの場合だと、
陰の部分はかなりアンビエント色に近づく感じになるので
おそらくディフューズマップがなくても頂点カラー程度で
誤魔化せるんじゃないかな、と。。
というか、僕が参考にしている１２作品目となる某RPGゲームの背景も
同じようにスペックの関係上、透過マップしか用意してない気がするんですよね。

もう少しこだわれば、きっといらないはず！と自分に言い聞かせる。

話がうって変わって。最近ようやくパトレイバーという昔のアニメを見始めました。
僕が尊敬している押井さんが監督でもあり、踊る大捜査線に
大きく影響を与えている、というらしいあの作品のことです。

まだ最初の数話しか観ていないのですが、面白いです。
ロボットものですが、警察の暢気(？)な日常にスポットを
当てているところとか、踊るに影響を与えている感じがひしひし伝わってきます。

まだまだ背景制作は続きます。

今まで中途半端な画像ばかりアップしてましたが笑。
ようやく全体像がどんな感じか見えてきました。

雲を今まで3Dで真面目に制作したことがなかったので、
結構苦戦してしまいました。うーん、綺麗で柔軟な空が作りてえです。

今回も背景のつづきです。

背景はキャラクターに比べて、色々なオブジェクトを組み合わせて
完成させることが多いので、これがなかなか難しいです。

そういえば、よく3Dゲームだとやたらフィールドが広いことが多いですが、
2Dだとドット(スプライト)単位でまとめるのに対して、3Dだと
ポリゴン単位でまとめるので、テクスチャのタイリングを
目立たないように考慮して作っていると、どうしても
背景がだだっ広くなってしまうことが分かってきました。

このまま進めるとMMOのように広いフィールドになってしまいそうなので
これから少し修正しようかと思います。

最近なぜかすごく眠たいのですが、それでもぼちぼちやっております。

鳥瞰視点だとキャラクターの手前の木も高いと、キャラクターが
隠れて全然見えなくなってしまうので、小さい木も作成してみました。
とりあえずテクスチャは使いまわしという笑。

背景、ちょっとずつ出来てきました。

そういえば、最近不思議だなあと気になることがふたつ。
・ひとつはMMD等でみかける初音ミクさんの3Dモデリングなのですが、
なぜか髪の分割数が少ないなあと気になってしまうことです。
腕や足よりも面積が大きいんだから、セオリー通りでいくなら髪の方が
分割したほうがいいんじゃないかなあと、気になってしまう今日この頃。
まあ、好みは人それぞれなので、あれはあれでいいのかな。
・もうひとつは、最近よくみかけるBL系の男の人のデザインに
ついてなんですが、何でどれも胴体が異常に長いのか、
気になってしまう。サラッとした髪や切れ長の目がいいって
いうのはなんとなく理解できるんですが、胴体がすんごく
寸胴なのだけが、よく分からない。。
これだけは、前々から気になっているのですが。。未だに謎です。
BL好きの人や自称BL研究家の方がいましたら、是非
詳しく教えてほしいものです笑。

…あ、ちなみに僕はBLを読んでいる訳ではないですよ苦笑。

○月×日、晴れ。

今日は家のお庭に大きな草がたくさん生えました。

娘も腕を広げて大喜びです。

という一枚。…はい、嘘です。
お庭に崖なんてありません。。あったらいいけど笑。

モデラー上の一枚なんですが、LWはビューポート上では
Zソート描画なのか、半透明のポリゴン描画がうまくいかないのが悩みどころ。
ポリゴンの最適化には便利なんだけど、レンダリングしないと
ちゃんと確認できないのは面倒だな。あと、頂点カラーを
ONにするとなぜか異常に処理が重くなるのもむず痒い。

今回は画像とは少し関係のない話。

サイトに画像をアップするために日にちを確認しようと思い、
携帯の電池が切れていたので充電してみると。。
携帯の調子が悪かったため今まで届いていなかったメールが山のように来た。

まあ、そのほとんどがいつも通りのチェーンメールだったりする訳だけども。。
中には昔の友達が久しぶりにメールを送ってくれたりしたものもあった訳で。。

さらに高校の友達の結婚式という晴れ舞台のお誘いのメールもあって。
とても嬉しかったわけだけど、同時に今の自分がすごく恥ずかしくなって
素直にお誘いに乗ることができなかった。。

この現状をなんとかするために。とりあえず、今は自分ができることをやろうと思った。

少し試したいことがあったので、今回はバジリコの超ローポリモデルの
テクスチャを制作してみました。

試してみたことは、ズバリ。LWで、XSIのGATOR機能のような
マテリアル転送ができるかということです！

以前から、サーフェイスベイクカメラを使うとマテリアルの
透過部分はそのまま前後の近接オブジェクトのマテリアルを
取得しているなと思っていたので。。ひょっとしたらと思い、
それを利用してバジリコの超ローポリモデルで試してみたところ。。

ある程度テクスチャコピーが綺麗にできることが分かりました！！

ただ、UVの範囲外は真っ黒で描画されてしまうので、ある程度
後で修正する必要がありますが、これを利用すれば
プログレッシブモデルの制作はある程度簡単にできそうです。
制作ではプログレッシブモデルの導入は考えていませんでしたが、
以前まで考えていたモーション用頂点バッファの複数確保を行うより、
距離に応じてローモデルに切り替えたほうがメモリ消費を
抑えられるので、こっちの方がいいなと思いました。

ただ…モデリング・テクスチャ制作共に作業が増えます笑。