巨大クエリちゃんあらわる

ここしばらくモデルを作っているんですが、ある程度できたので、Unityでどんな感じになるか確認するためにBlenderからUnityに持って来たら、うっかりサイズを間違えてとんでもないサイズになっていました。

 

f:id:Manakel:20160115212523j:plain

 

ちょうどモデル本の本家でも同じようなのがあったのを思い出したので、せっかくなのでブログに張り付けてみました。

 

フィールドが大きすぎる上に遠距離用の簡易モデルの為パッと見対して大きくないように見えますが、イーサン(手前の白い奴)の100倍近くあります。

 

ちなみにフィールドはこの100倍のモデルでも余裕で走り回れるくらい巨大だったりします。

 

しかもこれ、全体マップの一部で、このサイズのフィールドをつなげてシームレスに移動できるようにする予定です。

 

これの細かいレベルデザインをすることを考えると気が遠くなりそうです・・・。

 

現在はまだ試験段階なので、フィールド自体適当ですが、Unityのterrainは使わない予定です。

 

 

・・・大きすぎて絶対重くなるので。

 

ついでに洞窟の入り口とかもシームレスに繋ごうかと思ってます。

 

空に星を浮かべる予定なので、現在は星に草をはやすいい方法が無いか検討中です。

 

Unity既存の草は日の当たらないところ(Yマイナス方向)には生えそうにないので。

 

ビルボードで一つ一つ動かすと重そうな気がするし、何とか処理的に軽く描画したいところです。

 

ちなみに今回画像に映ってる巨大モデルはゲーム用じゃないので、ゲームには登場しないと思います。

 

 

 

 

 

f:id:Manakel:20160115215046p:plain

この記事はCreative Commons Attribution 4.0 International License(CC-BY) に基づいて作成されています。

【モデル作成】 髪の毛についての考察

実は最近はまたキャラクターモデルを作成していたりします。

 

今回は髪の毛をカーブで作ったんですが、簡単ですね。

 

Blenderで髪の毛をカーブから作る方法


 

前に作った時は一本一本作ってたんでかなり大変でした。

 

 

ただ、メッシュにしたときに一つ問題があって、髪型によっては必要のない面が大量に出来てしまい、かなりの無駄になるという・・・。

 

上手く頂点をつないで、髪型を完全に面続きしようとするとかなり大変なんですよ。

 

髪の毛のモデルの場合は無理につなぐと逆に違和感があったり、

ボーンで動かしたときに変な感じに動いたりするから別に無理につなぐ必要はないんですが、ちょっと思いついたので、髪の毛をブーリアンで統合してみました。

 

 

f:id:Manakel:20160108204051j:plain

統合前

f:id:Manakel:20160108204114j:plain

統合後

 

一本ずつ統合しないといけないので面倒ですが、

比較的簡単に無駄な面が消せます。

 

ただ、上手く統合できなかったり隙間部分に変な面が残ったりするので、

最終的な調整は必要です。

 

 

使用する場合は表面の見える部分は統合しないで、内側の部分だけにした方がいいかもしれません。

 

 

ちなみにブーリアンBlenderのモディファイアーの一種で、二つのオブジェクトの足し算や引き算が出来る機能です。

 

CADとかの設計だとよく使いますが、キャラクターモデリングだとあんまり使わないかもしれません。

 

 

 

BlenderのCyclesエンジンによるベイク時の注意点

少し前からダンジョン作成でBlenderを使っているんですが、その時にCyclesエンジンの部分を使用する機会があったので、ちょっとしたメモ。

 

 

CyclesエンジンはBlenderレンダリング方法の一つのようで、Blenderレンダーとなっているところを切り替えれば使用できるようです。

 

バージョン2.6辺りから使えるようになったみたいです。

 

Cyclesエンジンを使うと今までのBlenderレンダーで出来なかったマテリアルの作成が出来るようなので、これでマテリアルを作ってモデルにベイクすれば今までよりもテクスチャ作成がしやすくなるんじゃないかと思って少しいじってました。

 

Cyclesエンジンでももちろんベイクは出来るんですが、今までのBlenderレンダーのベイク同様に少しわかりにくい仕様になってます。

 

そのせいでベイクに使用していたテクスチャに上書きされてしまいました。

 

今までのBlnderレンダーのベイクはUV/画像エディターとモデルの編集モードとのリンクによってベイクされていたので、3Dビューをベイクしたいモデルの編集モード、UV/画像エディターをベイクしたい画像にして、

 

ベイクしたいモデルの頂点を選択したときに画像エディターがベイクしたい画像になってれば問題なかったんですが、

 

Cyclesエンジンではこの関係性が変わっているようです。

 

どうもベイクされるのはプロパティのテクスチャで現在選択されているテクスチャになるようです。

 

しかも、周りのモデルがベイクしたいモデルに干渉していると、その部分のテクスチャに影響を及ぼすようです。

 

使い勝手が少し難しいかもしれませんが、

フィールドのテクスチャとかを作るのが結構簡単に出来そうなので、

もう少しいじってみようと思います。

 

参考サイト

ch.nicovideo.jp

水中表現を考える

ここしばらく水中の実装をしてるんですが、流石に最近のリアルなゲームのようにするのは難しそうです。

 

・・・どの道そこまで作りこむつもりはないですが。

 

水中への切り替えも問題になってくので、意外といろいろ考える必要がありそうです。

現状こんな感じになってます。

f:id:Manakel:20151224182336p:plain

 

なんだか今一つな感じです。

 

今回結構深くまで潜れるので、

上の方と下の方で演出を変えたいですが、

イメージエフェクトとかを徐々に変更するのは結構めんどくさそうですね・・・。

シームレスマップ作成のための基本システム作成

ここ数日Unrealエンジンを色々いじってみましたが、マップの作成はUE4の方が軽い感じがしました。

 

もっともまだ少ししかいじってませんが。

 

UE4ではマップを分割して読み込んだりなんだりすることで広大なマップをつかえるようです。

 

最近Unityもシームレスマップが制作しやすい環境を整えて来たようです。

複数のシーンを同時に読み込んで編集できるようになったようですね。

せっかくなので、この機会にフィールドを広げようと思い、シームレスマップを実装しようというわけです。

 

Unityにもオープンワールドのアセットは有料販売されてますが、お金が掛かるのもなんなので、自分で作ろうと思います。

 

といっても、単純に近づくと表示して、離れてしばらくすると消えるようにするだけですが。

 

こんな感じ

f:id:Manakel:20151215230818g:plain

 

試しにGIF作成してみたら、撮影時間が短くて消えるとこまで入りませんでした。

 

単純にプレイヤーとの距離が一定以上近づくとシーンをロードするようにしてみました。

同じ要領でシーンのアンロードも出来るようです。

 

 

ただ、最初に適当にロードとアンロード基準距離を同じ値でやったらUnityが無限ループに入ったらしく止まりました。

 

なので、今は基準になる距離を少し変えて、ついでにアンロードは少し遅らせてます。

 

でも、これだけだといきなりマップが消えることになるので、実際に使うときには近づくまでは低クオリティーなマップでも配置しておいて、近づいたらシーンのロードと低クオリティーマップの削除という感じになると思います。

 

低クオリティーなマップでも、被写体深度とかいじってぼやかせばなんだかそれっぽく見えるようになると思うので、出来るだけ遠くが(ぼやけて)見えないようにしたら意外と軽くなるんじゃないかとか思ってます。

 

Unityのテラインは重いので、Blenderでマップを作るようになりそうです。

分割が面倒なんですよね・・・。後配置とか。

Unrealエンジンをインストールしてみた

Unityでゲームを作っていたところ、少々情報不足な部分があり、Unityに並んで最近無料になったUnrealエンジン(UE4)にはその情報がある可能性があるということを知ったので、UE4をインストールしてみました。

 

 

UE4はUnity同様ゲームの開発環境で、今年無料になったらしいです。

Unityに比べて日本語の情報量が少なく、また、プログラムコードもC++を使っているので、Unityしか使ったことがない私には少々難しそうですが、

 

まあ、別にUnityから乗り換えるというわけでもないので大丈夫でしょう。

 

 

インストールして驚いたんですが、Unityと違ってメニューとかが日本語なんですね。

初めて起動したときには簡単な画面の見方とかのチュートリアルが表示されて(もちろん日本語)意外と初心者向けなんでしょうか?

 

 

調べてみると、ブループリント(設計図という意味だったはず)というシステムで、プログラムコードを書かずに色々できるみたいです。

 

Unityの「玩」とかいうアセットみたいな感じでしょうか?

 

もちろんC++でコーディングも出来るんでしょうけど。

 

そして、Unityと違ってエンジン自体のコードが見れるとかなんとか・・・。

 

まあ、今回の目的はそこだったりするんですが。

 

まだ調べてる最中ですが、場合によってはUE4も併用するのもいいかもしれません。

一つのゲームを作るという場合は止めた方がいいですが、

ゲームを作る以外の目的なら、意外といいかもしれません。

 

・・・調べてみないとわかりませんが。

リップシンクもどきを作ってみた

ここしばらくプログラミングから離れてましたが、今日は久しぶりにスクリプトを書いていました。

 

動画で使用していた3Dモデルを変更した影響で、今まで使用していたスクリプトが使えなくなってしまいました。

 

以前の3Dモデルは非常に簡素なモデルだったので、しゃべっている雰囲気を出すのに首を少し動かすだけでひょうげんしてましたが、

 

今回の3Dモデルはそれなりに人型に近いため、しゃべらせるには口の動きを表現する必要が出て来たんですね。

 

 

そこでリップシンク(音声に合わせて口が動くやつ)の登場というわけです。

 

Unityにおけるリップシンクのプログラムはすでに先人(凹様)の方がプログラムを作っています。

tips.hecomi.com

 

 

これを使えばきれいに音声に合わせて口が動くことでしょう!

 

・・・使ったことないんですが。

 

本当は使いたかったんですが、正直重そうな気がしたのと、そこまでクオリティ高くする必要もないかと思って自作することにしました。

 

 

リップシンクするには音の周波数を分析してどの母音(”あ”,”い”,”う”,”え”,”お”のいずれか)の音を現在発声しているのか割り出す必要があるんでしょうけど、(詳しくは知りません)

 

ぶっちゃけアニメとかでもそこまで細かく口の動きを合わせたりはしてないはず。

(・・・してるかもしれませんが)

 

だったら、わざわざそこまで判別しなくてもそれっぽくなるんじゃないかと思って適当に作ってみました。

 

ちょうど、この方の作ったものに近い感じです。

unity-atelier.hatenablog.com

 

 

一応表情で、「あいうえお」の各口の形は作ったので、あとは音声が再生されてる間は適当に口の形を変えれば、なんだかそれっぽくなると思ったわけです。

 

・・・意外と違和感がありました。

 

 

というのも、音声データには無音の部分もあるわけで、

無音部分でも音声データ的には ”再生” 状態なわけで・・・

 

明らかに音が無いときも口が動いてしまうという。

 

なので、仕方がないから一応現在の音の周波数だけ取得して、(GetSpectrumDataでとれるようです)その値の大きさで適当に口の形を合わせることにしました。

 

作っておいてなんですが、

周波数の辺りは自分でもよくわからずに適当に作りました。

 

とりあえず配列で取得したfloat値で一番大きい値を見つけて、その値によって口を動かすかどうかと、口の開き方を対応させてみました。

 

本当のリップシンクだったら ”あ” を母音に持つ音の時に ”あ” のモーションを対応させるんでしょうね。

 

私は ”あ” の音の周波数の波形なんか知りませんので、適当に合わせました。

 

動かしてみたらまあまあの出来で動いたので、良しとしましょう。

 

 

モデル作成も一段落ついたので、今度はゲーム開発に取り掛かれそうです。