Blenderでゲームオブジェクトを作るとき

はじめに

この記事は、アドベントカレンダー2024の15日目の記事だったはずの記事です、投稿は16日となってしまいましたが....

挨拶

こんにちは！！！23Bのo_ER4ことオイルフです！！
最近寒くなってきましたね。僕はこのブログ書こうとしたら寝落ちしました。()
今日はそんな話とは微塵も関係なく、Blenderの話をします。
なお、Blenderのバージョンは4.2を想定しています。

何があった？

今、僕はtraPで3Dゲームを作るプロジェクトに、ゲーム中に登場する3Dオブジェクトの一部の製作の担当として参加しています。
一応僕は過去にいくつか記事を上げているように、Blenderを使ってオブジェクトを作ること自体はまあ問題なのですが、ゲーム側(今回はUnityです)に移植まで含めて実装するのは今回が初めてでした。
先輩から参考になるサイトを教えていただいたり、自分で色々調べたりしたので、今後もゲーム側に移植する際に参考になるように備忘録をまとめようと心に決め、書くことにしました。

BlenderからUnityに移植するやり方

Blenderで作ったモデルをUnityに移植する流れは大まかに以下の通りです。

UV展開する
マテリアルをベイクする
fbx,ベイクしたファイルをUnityのディレクトリに移す

UV展開

3Dの物体を平面に展開する作業です。あまり慣れてない人には、小学校中学校の図形の展開図を描く作業だと思っていただけるとイメージしやすいと思います。

やり方は「blender UV展開」とか調べればいくらでも出てくると思うのでここで説明するのは割愛しますが、この工程を挟むとこで後でベイクと呼ばれる作業が行えるようになります。

ベイク

ベイクは、モデルの外見を、先ほど行ったUV展開より得られる図であるUV図の輪郭に沿ってテクスチャを描画し、そうして得られた画像を出力します。

まず、「レンダープロパティ」を選択していただき、以下のように設定します。

そうしたら、ノードグラフのところに「画像テクスチャ」と呼ばれるノードを導入します。

ここで注意してほしいのは、追加するのはほかのテクスチャを決めるノードに接続する必要はない、ということです。

あとは、「画像テクスチャ」ノードの「新規」のボタンを押して、ファイル名を入力します。すると、そのファイルにベイクした画像が保存されます。

そうしたら、先ほどのレンダープロパティの設定を開き、「ベイク」を実行しましょう。そうすると、うまくいけば出力されます。

ベイク

後はエクスポートを行えばOKです。ただし、Unityにエクスポートするのは、fxファイルと先ほどベイクで作った画像ファイルです。

そうしたら、それらのデータを、使いたいゲームエンジンの対応するディレクトリに移しましょう。

いかがでしたか？？

ということで、これさえわかれば誰でもBlenderでモデリングしたものをUnityに移せます。
皆さんもこれで晴れて3Dゲームのグラフィッカーとなることができました！！！
やったね！！！！！！！！！

と思いきや

それで済んだらよかったんですよね。

反省・気をつけること・改善策

てことで、ここからが本題です。
実際Unityに移植するだけならさっきの手順を追えば問題ないのですが、問題なのはそのモデルがBlenderと全然見た目が異なりうるということです。
また、実際Unityでゲームを作るときにもBlenderで設計を誤ると大幅に大変なことが待っています。
ここでは、現状自分がチェックリストにしている内容を箇条書きにしていこうと思います。

マテリアルがUnityとBlenderであまりにも異なっていないか

今回ダントツで苦しめられたやつです。

先ほどベイクすればマテリアルの画像を出力できる、と説明したのですが、その見た目がBlenderのそれとそっくりそのまま同じになるわけではないんですね。

今回の原因は、木をカーブから作っていることだったのですがほかにも生成する類のBlenderのアドオンを使うときとかは気を付けるべきなんじゃないかなと思います。

因みに実は先ほどのUnityの方の画像は、修正を加えています。元々葉っぱの色が黒色でした。

どうしたのかというと、Shader Graphで画像に緑色のカラーを加えて調整しました。

Unity で起こってる外見上の問題の解決は、UnityのShaderとかを使って修正するのが可能ならば、Unityの機能で済ませたほうが確実ではあります。

ポストプロセスの様なUnityのワールドの環境を考慮したか

今回一番反省したのはこれ(涙目)。
Unityには、ワールドに
特に今回はゲーム中に存在する空間に、ポストプロセスと呼ばれる、一部のオブジェクトの光らせ方の調整が行われており、少なくとも僕はこの光の演出が滅茶苦茶素晴らしいし、大好きなんですが、僕は別にこの辺一切かかわってないんですよね。(最近は少しずつHLSL Shaderとかポストプロセスとかも勉強しています)

で、今回モデリングと結構非同期でその辺の調整が行われており、Blenderでモデリングする際にその光の影響を一切考えていなかったんですよね。

するとテクスチャの色の見え方、陰影の見た目がBlenderで作ったのを確認したときに比べて結構変わって見えます。

実際先ほどまでのやつとはだいぶ見た目の印象が変わっていると思います。

現状対応策を決め切れていないのですが、結局さっきの項と同じように、Unity側での見た目の問題なので、よほど色がRGBすら滅茶苦茶変わって見える、というわけでもなければShader で微調整するのが楽なんじゃないのかな、と個人的には思いました。

ポリ数は本当に必要か

普段Blenderだけで作品を完結させる場合でも、モデルの頂点の数は必要以上に増やすべきではないとは思いますが、ゲームの場合はオブジェクトをゲームのプログラマーが諸々調整するわけなので、必要以上に頂点数が多いとゲームのプログラムを実装する際に余計な負荷となってしまいます。
でもローポリだと表現が安っぽくなるのでは？と思われるかもしれません。
僕は、凹凸をはじめとした表面の詳細な表現をnode graphでいい感じのテクスチャを作る、ことを徹底していました。
結構これを意識するだけでも表現の幅はポリゴン数が減ってもある程度は担保されます。
例えば、ディスプレイメントとか加えるだけでも滅茶苦茶いい感じに凹凸ができます。
そんな風にnode graphを活用すると表現に手の込んでいそうな雰囲気は割と簡単に醸成できます。

トランスフォームは忘れていないか

簡単にいうと、モデルの縮尺を保存時に1倍として再修正します。

このへんは出力時に忘れていないか特に確認しています。

まとめ

今回は本当にこれで終わりです。
今回参加させていただいたゲームのプロジェクトは、僕は途中参加だったわけですが、今まで自分でやりたいように製作してたのと違い、人の世界観に合わせたオブジェクトを作るという結構方向性の変わった製作でした。未だに自分でもかなり満足できていない箇所があるのですが、かなり知見を積む機会にはなったんじゃないかなと思います。
今後は、今回は逃げたShader、ポストプロセス周りの演出面でも勉強していければよいな、と考えています。
ここまで見ていただきありがとうございました

最後に

本来は明日であったとされている12/16日の担当は@cp20さんと@takeno_hitoさんの2人です。お楽しみに！！！