Blog ブログ

どのようにアニメルックのアバターを実装したのか? 2Dアートデザイナーと3Dデザイナーの2人にインタビュー!

どのようにアニメルックのアバターを実装したのか? 2Dアートデザイナーと3Dデザイナーの2人にインタビュー!

こんにちは! ホロアース運営チームです。 今回はホロアース開発スタッフとして働いている2Dアートデザイナー「おぐろさん」と3Dデザイナーの「奈良早也香さん」に話を伺いました! お二人には、アニメ業界の第一線で活躍する坂本勝さんの手掛けたアバターコンセプトデザインをどのようにホロアースに落とし込んでいったのか?その時の苦労や工夫、お互いにどんなコミュニケーションを取り合っているのか? などのお話を語って頂きました! 【インタビュイー紹介】 「おぐろさん」 ポジション:メタバース事業本部 2Dアートデザイナー 入社時期:2022年2月頃 業界歴:約12年 「奈良早也香さん」 ポジション:メタバース事業本部 3Dデザイナー 入社時期:2022年6月頃 業界歴:約13年 ――まずは、お二人がなぜホロアース開発チームに参画しようと思ったのかなどの経歴を教えてください おぐろ さん(以下、おぐろ):僕の場合、元々弊社に勤めていた友人に転職の相談をした際「こういうの作ってるんだけど受けてみない?」と誘われたことがキッカケです。 正直、その時はまだメタバースに対してVRの類似コンテンツくらいの本当にフワッとしたイメージしかなく、アバターの見た目も比較的簡素なものだと思っていたのですが、ホームページに載っているイメージボードを見たりしてセルルックな世界でメタバースを作りを目指しているのだと感じ、それがすごく面白そうだなと感じて応募しました。 また採用ページにも中核メンバー募集中と書いてあって、今まで体験したことない環境でゼロから作れる経験はもうあまりないかなと、そういった所でチャレンジしていきたいという思いもありました。 面接ではプロデューサーから色々と資料を見せてもらいながらホロアースが目指しているものや、やりたいことを聞いて「本当に凄いことをやろうとしている!」と思い前のめりにここで働きたいってなりました。 奈良早也香さん(以下、奈良):私は転職を考えていた時、前職が非常に忙しかったこともあり、モデル制作が既に量産フェーズに入っている安定した環境に進むか悩んでいました。 そんなときにホロアースの話を色々聞いて、新規プロジェクトでゼロから作るということに、今まで自分がやってきたものがどこまで通用するのかという挑戦したいという思いが勝り開発への参画を決めました。 ――挑戦できる会社は他にも多くあったと思うのですが、ホロアースの開発に参加を決めた決め手を教えてください 奈良:ゲーム開発歴が長い会社とかだと、開発フローとか仕様とかの土台がすでにあると思うのですが、ホロアースの開発ではまだそれが整っていなかったので、なにもない状態からホロアースが目指すもの、ホロアースが表現したいアバターをゼロから作り上げることができるところに、やりがいを感じて選びました。 メタバースという経験したことないジャンルやゲーム会社ではないからこそ本当にゼロからの開発に挑戦できそうなところに魅力を感じたっていうのはめちゃめちゃあります。 ――では、お二人がアバター開発で担当している業務や進め方を教えて下さい おぐろ:僕は2Dチームで「衣装とか髪型・顔回り・表情など、アバターの見た目」に関わるところのデザインを担当しています。 奈良:私はアバター3Dチームのリードデザイナーとして、アバターの仕様策定からルック管理までの3Dアバターに関わる全般の担当をしてます。 おぐろ:業務のフローとしては、プロデューサーやプランナーとデザインの方向性にするかを決め、デザインが出来たら、3Dチームに持っていきます。 それに対して3Dチームの方から、アバター開発の仕様に則って実装できる・できないの判断をしてもらいます。 実装できないと判断されたデザインについては、3Dチームからこうすれば実装できるなどのアドバイスを貰ったりしつつ調整し最終的に3Dモデルに出力させていくのが今の流れになっています。 奈良:コンセプトデザインをそのままモデル化するとユーザーが自由にカスタムできるアバターシステムでは組み合わせによって違和感がでてしまうので、そうならないようにめちゃめちゃ細かい仕様を用意して制作しているのでいつもモデルを作るのに苦労しています。 おぐろ:いや、そうですね。3Dチームの方々には多大なご迷惑をおかけしています(笑) でも、それだけ細かくて複雑なレギュレーションに沿ってデザインをしないと、ユーザーが満足できるようなアバタークリエイトの自由度というものは生まれないんだなっていうのは凄く感じましたし、これが本当に良い経験で、作成する際に失敗なども度々ありましたが前向きに捉えています。 奈良:その仕様が守られることでクオリティが高いモデルが出来上がっているんですよ。 それが守られないと不具合が起きたり、変な見た目になったりというのがあるので、細かい仕様の中で良いデザインをしてくれている2Dチームのみなさんは凄いなと思います。 ――おぐろさんがアバターデザインを作るうえで工夫していることや難しさを感じていることはありますか? おぐろ:第一に坂本さんがデザインしてくれたアバターコンセプトデザインがあるので、そこからは大きくずれないようにっていうのは決めていました。 顔とかプロポーションとか髪型とか「きっと坂本さんだったらこうする」というのを常に考えながらホロアースらしさというものも大事にする。 その両立を目指すところに難しさを感じています。 ▲TRIGGER「坂本勝」さんのアバターコンセプトデザイン ――特にどこら辺のデザインが難しいですか? おぐろ:顔回りに1番難しさを感じています。特に目のパーツは、坂本さんに描いていただいたアバターコンセプトや過去に携わっていた作品など色々な資料を参考にしつつ、且つパーツを組み合わせた時に、変にならないか、特定の目や髪の組み合わせでデザインに破綻が起きないかという整合性をあわせるところで特に苦労しています。 ――2Dチームが制作したアバターデザインを3Dモデルにしていくうえで工夫したことや苦労したことを教えてください 奈良:やりたいことや表現したいことが、とにかく多くあったのでリストアップして優先度を付けつつ、量産に影響がある部分から仕様づくりを行ったんですが、この工程で非常に苦労しました。 2Dチームが大事にしたい箇所と3Dチームが大事にしたい箇所が食い合わないときも当然あり、アバター衣装のデザインルール作りにかなり時間をかけました。 衣装のデザインルールというのは、トップス・ボトムスなどの衣装パーツを組み合わせた時に、衣装同士の貫通をなるべく抑えるために、作成範囲を制限するためのルールで様々な制約の中でどこまでデザインの幅を持たせられるかのやりとりを頻繁に行ってました。 ▲トップスもボトムスもなるべくタイトにしたい衣装の時に、貫通を避けながらどれだけタイトに出来るかの検討を重ねた おぐろ:1年半ぐらいずっとやってましたね(笑) ただ、ここの仕様をしっかり決めて制作を行わなければ、どこかで品質が保てなくなっていたと思います。 奈良さんが地盤を固めてくれたお陰で、ちゃんとしたレギュレーションの中でデザインができることに助かっています。 奈良:そう言って頂けて嬉しいです。 その地盤固めの期間を頂けたのが本当にありがたかったなと思います。 ――チーム全体としてスクラップ&ビルドを恐れていない印象がありました。開発初期と今ではかなりモデルが洗練されたように感じます 奈良:実際、ベースデザインが変わったんですよ。最初これで作っていこうってなったベースデザインから、かなりテコ入れが入って衣装のデザインルールも変わりました。 ▲左が開発初期のαモデル、右が現在のモデル おぐろ:僕がチームに参画した段階ではα版のモデルは出来ていて「もう完成してるじゃん!」って思ったんですけど仕様が固まっていく中でα版のモデルでは対応できないことが発覚して、じゃあもう1から作り直そうという感じになったのを覚えています。 奈良:みんなで一緒にいいものを作ろうっていう気合で作り直しましたね。 それがあったお陰で、ユーザーさんからアバターが可愛いと言ってもらえて、やってよかったなと凄く感じました。 おぐろ:ベースデザインが変わるっていうことのヤバさを補足すると、まず、ベースデザインが変わるとモーションも全部変えないといけないんです。 作っていたモーションとかも全部作り直すと、ゲーム性にも影響したりして、本当にゼロからのスタートになるみたいな感じですよね。 ベースデザインが変わるのは「マジで!?」って思う開発の人間は多いと思います。 奈良:モーション班にもびっくりされましたね(笑) おぐろ:衣装なり髪型なり、色々なところに対応できるようなデザイン、モデルじゃないと駄目なんだと、アバターシステムの難しさを感じましたね。 奈良:当社に所属しているVTuberタレントの3Dモデルのクオリティが世間に受け入れられているところを、アバターシステムのベンチマークとして、そこのクオリティラインは達成しないといけないという高い目標が最初から設定されていました。 そこを達成していくために、ベースデザインの変更は必要なことだったと思います。 ――実際去年の12月に三角から人型アバターとして出して、ユーザーさんからの反響とかをみていかがでしたか? おぐろ:まず1番は、やっと皆様にお披露目することが出来てホッとしています。 ユーザーさんからの声を見ていると、「可愛い」とか「クオリティが高い」とか言ってもらえてチームの苦労や努力が報われたと思い嬉しい気持ちです。 しかしそれ以上に期待値をもっと超えていかないといけないっていうのは感じました。 「可愛い」という感想と同時に「こんなことできるんだ!すごい!」みたいな、驚きの声ももっと聞きたいなという気持ちがあります。 奈良:私は、アバターが「可愛い」って言ってもらえたことが、すごく嬉しくてモチベーションに繋がっています。 キャラクターデザインをしてくれた坂本さんもアバターカスタマイズを遊んで下さって、坂本さんが実際に描かれるような表情でスクショを撮ってSNSに投稿して頂いていました。 表情が動いている途中で止めても可愛く見えるように、こだわりを持って作ったので、坂本さんの投稿画像が表情モーションの中間部分だったので、ちゃんと可愛いと思ってもらえてるんだなと、こだわりが伝わって非常に嬉しかったです。 おぐろさんも仰っていたように、このレベルで止まるのではなく、他社さんのコンテンツよりもセルルックで1歩前に出られるようなところを目指したいなと思いました。 ▲モーションの途中で撮影しても可愛く見えるようにこだわった おぐろ:ホロアースをしっかりとしたジャパンアニメルックのような画にしていきたいというプロデューサーの提示する大きなコンセプトがチーム全体で目指している所ではあります。 奈良:サンドボックスでも今後、昼夜の概念が入ってくると思うのですが、どんな時間帯でも綺麗で映える画作りを実現していきたく思っています。 ――アニメルックの世界に自分自身が入っていける、没頭できるというのは大事ですよね。 おぐろ:自分は没頭してアニメ作品を観ていると「この世界に、このワンシーンに自分が一人のキャラクターとして存在していたらどうなるんだろう?」って考えてしまうんですよね。 そういった没入感をホロアースでも感じれるようにしていきたいとも思っています。 奈良:メタバースの醍醐味って感じがしますよね。そこの空間で生活しているとちゃんと体感してもらえる没入感を目指すっていうのは本当にやりたいです。 ▲「オルタナティブ・シティ」にあるファッションショップ「ALTERMODE」の壁面に映るキャラクターはおぐろさんが制作 ――他の一般的なメタバースとは違って、アニメルックの世界観に没入していくことを目指しているホロアースにおいて、亜人や獣人などの現実に存在していないものに実在感を持たせていかなくてはいけませんよね。 これは結構難しいチャレンジだと思うのですが、現時点でどういったものを考えていますか? おぐろ:そうですね。亜人・獣人表現は、開発チームとしてもやりたいという思いは強いので、しっかり設定を作って出してあげたいですね。 他種族でも違和感なくファッションを楽しめるように、悪魔だったらゴスロリ系なのかなとか、そういったところもしっかり描いていきたいなと思っています。 他にも、タレントさんにも色々な種族の方が沢山いらっしゃるので、そこ含めて一緒に世界観に入り込めるようにしていきたいです。 「あの憧れのタレントさんと同じ種族になれる!」とかも感じて貰えたら嬉しいです。 ――ファンタジー世界で他種族になれるゲームというのは沢山ありますが、ファッションとか日常を楽しめるみたいな要素は、他ゲームではなかったことかもしれませんね。 おぐろ:自分も描きたいところではあったので、プロデューサーに色々デザイン案を描いて投げているところです。 ▲WEBマンガ「Holoearth Chronicles Side:E ヤマト神想怪異譚」にて、おぐろさんが制作したキャラクターデザイン案 本作のように他種族が違和感なく日常を楽しめるようなデザインをホロアースでも実装できるか議論を重ねている 奈良:おぐろさんとプロデューサーで密にやり取りされてますよね。 おぐろ:ホロアースみたいなサービスって新規性が高くて、ゼロから作っていかなくてはいけないという面で、常に連携を取っていかないと、どこかしらで設定に穴が空いたりとかするので、僕だけではなく、3Dチーム含めて、プロジェクト全体がプロデューサーと密にやり取りをしっかりやっているのが好きですね。 奈良:気軽に話しかけに行きやすい環境っていうのがいいですよね。 ――ありがとうございます。アバターのデザインと開発っていうところを2D3Dのデザインチームにほとんど主導してもらっているじゃないですか。 これまでの開発現場ではあまりみたことないような環境ですよね。 奈良:かなり任せてもらってますね。 おぐろ:僕も経験がないです(笑) 奈良:任せて貰えたことで、こうしたらモデルのシルエットが綺麗になるとか、ルック的にいいんじゃないかなど、2D・3Dデザイナーの目線から、仕様に盛り込むことができましたね。 おぐろ:色々な自分発信の提案がこんなにフラットにできて、それが採用されたりする現場もあまり見たことがありませんね。ここまでだったらこのクオリティで作れるみたいな形で、自分たちで締め切りや全体のバランスを考え設定していくことになるので、自分達で提案した以上、それはしっかりと守らないといけない責任が生まれて業務は増えてしまうのですが、それも全然楽しいです。 奈良:一時的に忙しい時期はありましたが、締め切りまでに作らないといけないクオリティを自分たちで宣言しているので、全員が最後までやりきろうって気持ちが強いままアバターの初期リリースを完了することができました。 ――最後に、ユーザーさんに向けてメッセージをお願いします! おぐろ:ホロアースは色々な可能性を秘めているプロジェクトだと思っています。 しかし作っていく中でご迷惑をお掛けしたり、お待たせしてしまうこともあるかと思いますが、その分感動や驚きなど皆様の期待値を超えた様々なアップデートをしていけるようチームみんなで奮闘していきますので、温かく見守っていただければ幸いです。 奈良:いろんなアバターカスタマイズを皆さんに楽しんでいただけるように、細かいところまでこだわったアバター制作をしていきたいと思います。 ホロアースと一緒にアバターもまだまだアップデートしていきますので、ぜひみなさんもホロアースでの分身を作り、この世界を楽しんでください! ※本インタビューで記載されている未実装の機能や展望について言及されている内容は、正式に実装されることを必ずしも保証するものではございませんが、開発チーム内での実現可否の検証・議論は行われているものとなります。

Date

24.5.31

Category

  • デザイナー
ホロアースのサーバーサイドの技術について

ホロアースのサーバーサイドの技術について

【執筆者紹介】 「 西根幸洋さん」 ポジション:メタバース事業本部エンジニア部マネージャー 入社時期:2023 年 10 月 業界歴:Web サービスやオンラインゲームの開発・運営に 11 年従事。主にサーバーサイド C# エンジニアとして活動し、個人として Microsoft MVP for Developer Technologies(2020-2022)を受賞。 はじめに こんにちは、メタバース事業本部エンジニア部マネージャーの西根です。 ホロアースの開発の話といえば、Unity を使ったクライアント側の実装や、アバターやライブ演出などの話が注目されがちですが、今回はサーバーサイドで利用している技術の一部をご紹介させていただこうと思います。 ホロアースの開発の裏側を知りたい、開発に参加してみたいと思っている方の参考になれば幸いです。 開発に参加してみたいと思った方はこちらから是非ご応募ください! 目次 ・使用しているプログラミング言語について ・クラウド環境や各種利用サービスについて ・ Cloudflare についてについて ・ エンジニア募集中です 使用しているプログラミング言語について Go 言語を中心に、PHP、C#、TypeScript、Rust など、複数の言語を採用しています。 ホロアースのサーバーは単一のアプリケーションではなく、分割された複数のアプリケーションによって構成されており、アプリケーションごとに使用する言語が異なっています。 ▼分割されたアプリケーションの種類 ・サンドボックスゲーム ・エントランス・シティなどのコミュニケーションロビー ・アカウントや決済などを扱う基盤システム ・etc ホロアースで最初に開発を開始したサンドボックスゲームのサーバーサイドは PHP を採用しています。 その後に開発を開始したコミュニケーションロビーや基盤システムでは Go 言語を採用しており、現在では Go 言語がサーバーサイドの開発の中心になっています。 その一方では今まで使用していなかったプログラミング言語を適材適所で採用することもあります。 たとえば現在開発中の新しいシステムでは、サーバーサイドでインゲームのロジックをリアルタイムに扱う必要がありましたが、そこではサーバーサイドにも C# を採用することで Unity を扱う C# エンジニアがクライアントとサーバーを一貫して開発可能な方針を選択しました。 その他の言語については TypeScript は Cloudflare 上のリソースと連携して動作する Cloudflare の FaaS(Cloudflare Workers)で利用したり、Rust は現在開発中の通信基盤で採用しています。 クラウド環境や各種利用サービスについて ホロアースのクラウド環境は主に AWS を使用しています。AWS の主な利用サービスは EKS、ECS、EC2、Lambda、Aurora、DynamoDB、ElastiCache などです。 ストレージや CDN には S3 と CloudFront も利用していますが、それらの多くの部分は Cloudflare に移行することでコスト削減を果たしました。 モニタリングツールには Datadog、データ分析基盤には Snowflake を導入しています。 カバーは Web サービスやゲーム開発を専門とする会社ではありませんが、そういった業界の会社様と比べても見劣りがしない環境や開発体制の整備を進めています。 Cloudflare について Cloudflare は CDN サービスとして以前から有名でしたが、最近は CDN 以外にも様々なサービスが提供されています。 ホロアースでは CDN を Cloudflare に移行したことをきっかけとして、Cloudflare を積極的に活用しようとしています。現在は CDN 以外にも Cloudflare Stream、Cloudflare Images、Cloudflare Workers などを利用しています。 この中でも Cloudflare Stream は特にヘビーに利用しています。年末年始や EXPO で行ったホロアース内の同時視聴イベントは Cloudflare Stream によって実現しています。 私は Cloudflare Stream はカバーに入社してから初めて触れたのですが、動画配信が非常に簡単かつ低コストに実現できるサービスで驚きました。 動画配信サービスの開発に興味がある方は一度触ってみていただくことを是非お勧めします。 エンジニア募集中です 今回は今まであまり表にでてきていなかった、ホロアースのサーバーサイドの技術スタックをご紹介させていただきました。 ホロアースではこうした環境でプロジェクトを一緒に進めてくれる仲間をまだまだ募集しています。 以前の記事で CTO の福田がメタバースの技術領域を「世界に関する技術の総合格闘技」と表現していましたが、これは本当にその通りで、ホロアースの開発は一筋縄ではいかないことも多くありますが、そのぶんエンジニアとしてのやりがいや楽しさも非常に大きなプロジェクトです。 サーバーサイドエンジニアだけでなく、Unity エンジニアやテクニカルアーティストも募集していますので、興味がある方は是非求人ページからご応募ください。 一緒にホロアースの開発に挑戦していきましょう!

Date

24.5.17

Category

  • エンジニア
窓を壁の自由な位置に設置できるようにする

窓を壁の自由な位置に設置できるようにする

【執筆者紹介】 「 井上 翔一朗さん」 ポジション:メタバース事業本部エンジニア部クライアントチーム 入社時期:2021年2月頃 業界歴:約3年 はじめに メタバース事業本部エンジニア部クライアントチームの井上 翔一朗です。 ホロアースの開発において、主に施設や建築部分の実装を担当しています。 近年ではゲーム内にハウジング要素を持つゲームが多くなっており、そこには窓も欠かさず登場します。ですが窓は多くのゲームの場合、先に窓用の穴が開いた壁を置いてからそこに嵌めるなど決まった位置にしかつけられません。チーム内からも壁に対して自由な位置に窓を付けたい!という要望があり、工夫して解決したので紹介します。 まずは実装結果の動画からご覧ください。 https://holoearth.com/wp-content/uploads/2024/04/mado_setti.mp4 動画のように一枚の壁の自由な位置に窓を設置できるようになりました! 窓を置いた部分の壁の見た目が消えることで外が見えるようになっています。 また、コライダーも見た目に合わせて穴が開けることが可能です。そうすることで将来的に、設置した窓越しに弓矢を用いた戦闘などを行えるようになります。 どのように実現したのか解説していきます。 解決策の概要 前提 窓の設置をする前に壁を設置する必要があります。窓は壁と重なるようにしか設置できないようになっていて、回転も壁に対して正しい向きに自動で調整されます。この部分の説明は省きます。 窓は以下の情報をPrefabなどに設定して持っておく必要があります。 ・コライダー(どの壁に設置されているかを衝突で検知するため) ・窓の幅 / 高さ   処理全体の流れ ①窓はコライダーを持っており、自分が設置されている壁を取得します。 ②壁に衝突するとその壁に位置とサイズ情報を渡しつつ穴をあけるように依頼します ③依頼を受けた壁は、シェーダーの値変更とコライダー管理スクリプトを実行し穴をあけます また、窓が破壊された場合は壁に穴を元に戻すよう依頼します。 見た目に穴をあけるシェーダーと、コライダーに穴をあけるスクリプトについてはこの後それぞれ解説していきます。 今回の実装の範囲では以下の限界があります。 窓の淵が壁からはみ出すことには対応していません。そのため、窓の4つの角すべてが1枚の壁の上に載っていることをRayCastで確かめています。 一つの壁に複数の窓を開けることには対応していません。二つ目の窓を付けた際は古い窓を自動的に破壊する仕組みになっています。 シェーダーにより見た目に穴をあける 基本方針は、今描画している座標が窓に重なる座標なら描画しない。というものになります。 モデルの側面が何もない空間になりメッシュの裏側が見えてしまいますが、そこは窓側が持っている窓枠の3Dモデルで隠されて見えなくなるので問題ありません。 (左:シェーダーで窓と重なる壁を削除した状態。右:そこに窓枠を置いた状態) 描画点の座標が取得できるようにSurfaceシェーダーで作ります。 窓のスクリプトから窓の中心点の座標と、窓の大きさ(幅・高さ)を受け取っています。 判定方法 以下の二段階に分けて考えます。 ①水平平面について描画座標が窓の中にいるかどうか ②垂直方向(高さ)について描画座標が窓の中にいるかどうか ①水平平面xz平面についての直線の式 z=kx+b を用いて考えます。 真上から見たときの窓に垂直な線の傾きを k とします。そして、窓の手前と奥の縁を通る直線をそれぞれ考えると b が二つ存在します。ここではそれを b1, b2 とします。 z=kx+b1 と z=kx+b2 の二本の直線で囲まれた黄色い領域の中を描画しなければよいことになります。 つまり、今描画しようとしている座標を(x1, y1, z1)とすると k*x1+b1 < z1 < k*x1+b2 であれば水平方向においては窓の中であると言えます。 ※k は窓の y軸回転量 = rotY から求めることができます。 ※タンジェントの0は未定義ですので、tan関数の引数に0を指定しないように分岐処理を設ける必要があります。 k = tan( rotY/180f * π + 0.5π ) ※b1, b2は窓の両端の座標から求めることができます。 b = z / kx ②垂直方向次にY軸について考えます。本ゲームでは窓はY軸でのみ回転するので式はシンプルで済みます。 _windowBottomY < position.y < _windowTopY であれば垂直方向において窓の中であることが分かります。 ※_windowBottomYと_windowTopYは窓の中心点Y座標に窓の幅を±すれば求めることができます。 ①②を踏まえるとコードはこのようになります。 bool isInsideWindow(Vector3 pos) // pos:今描画しようとしている点のワールド座標 {   // xz平面で窓の中   var isInsideXZ = _k * pos.x + _b1 < pos.z && pos.z < _k * pos.x + _b2;   // 高さが窓の中   var isInsideY = _windowBottomY < pos.y && pos.y < _windowTopY;   return isInsideXZ && isInsideY; } ※実際のシェーダーは同チームの回凱によって製作されました。こちらでは分かりやすく改変して掲載しています。 ※処理負荷軽減のためにも、_k, _b1, _b2, _windowTopY,_windowBottomY は窓を設置した時点で計算しておきます。 今後の課題 現状では長方形以外の形には対応していません。 他の形にも対応させたい場合は、その形の領域を計算する式を書く必要があります。例えば円形の窓であれば、xy平面に描画座標を投影した後で、描画点と中心点の距離が半径より小さいことを確かめれば実現できます。 コライダーに穴をあける 次は、見た目ではなく当たり判定に穴をあけていきます。 壁のコライダーは一つのBoxコライダーでできています。元のコライダーを窓部分をよけるように分割した4つのBoxコライダーに置き換えることで、穴が開いていることを表現します。 方法はシンプルで、最初のコライダーを削除した後で新しく四つのBoxコライダーをアタッチしています。そのためには、それぞれのコライダーの中心座標とサイズを計算で求める必要があります。 以下の変数が登場します。 壁の大きさ Vector3 wallSize 壁に対する窓の相対座標 Vector3 windowCenter 窓の一片の長さ Vector2 windowSize 計算式は以下になります ※コライダーはローカル座標系なので回転の考慮は不要です ※壁の原点は底面の中央、窓の原点は縦横の中央にあります ▼上側のコライダー var sizeX = wallSize.x; var sizeY = wallSize.y - (windowCenter.y + windowSize.y); var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = 0f; var posY = wallSize.y - sizeY/2f; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼下側のコライダー var sizeX = wallSize.x; var sizeY = windowCenter.y - windowSize.y/2f; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = 0f; var posY = sizeY /2f; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼左側のコライダー (x軸は壁の中心を0とするため、壁の左端の座標は - wallSize.x /2f となります) var sizeX = - wallSize.x/2f + windowCenter.x - windowSize.x/2f; var sizeY = windowSize.y; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = -windowSize.x/2f + sizeX/2f; var posY = windowCenter.y; var colCenter = new Vector3(posX , posY, windowSize.z/2f); ▼右側のコライダー var sizeX = wallSize.x/2f - (wallCenter.x + wallSize.x/2f); var sizeY = windowSize.y; var colSize = new Vector3(sizeX, sizeY, windowSize.z); var posX = wallSize.x/2f - sizeX/2f; var posY = windowCenter.y; var colCenter = new Vector3(posX , posY, windowSize.z/2f); これらの値を設定することで、窓の部分に被らないようにコライダーを配置します。 今後の課題 今回紹介した方法では四角形以外の穴を表現することは難しいです。 現状では四角形以外の形の窓は登場しませんが、以下のような対処法も考えられます。 積分のようにBoxコライダーの数を増やして並べることで疑似的に円形や三角形なども表現できるかもしれません。欠点としては、精度を上げようとするとBoxコライダーの数がかなり増えてしまいます。 あらかじめ三角や円形の穴が開いたコライダーを用意しておくのもいいかもしれません。四角形に穴をあけた後にその中に用意しておいたコライダーを配置します。特殊な形状のコライダの用意が手間ですが、コライダー数を少なくできる可能性があります 終わりに シェーダーとコライダー管理の組み合わせによって、窓を壁の自由な位置に配置できる体験を実現することができました!今後も魅力的なハウジング機能を作っていきたいと思います! 興味を持って頂けましたら、ぜひホロアースを遊んでみて下さい!!

Date

24.4.26

Category

  • エンジニア
2Dコンセプトアートからどのように3Dになるのか? 2Dアートディレクターと3D背景デザイナーの2人にインタビュー

2Dコンセプトアートからどのように3Dになるのか? 2Dアートディレクターと3D背景デザイナーの2人にインタビュー

こんにちは! ホロアース運営チームです。 今回はホロアース開発スタッフとして働いている2Dアートディレクターの「YKさん」と3D背景デザイナーの「シマノさん」に話を伺いました! お二人にはシミュレーションルームやキョウノミヤコなどのエリアが、2Dのコンセプトアートからどのように3Dで作られるのか? お互いにどんなコミュニケーションを取り合っているのか? などのお話を語って頂きました! 【インタビュイー紹介】 「YKさん」 ポジション:メタバース事業本部 2Dアートディレクター 入社時期:2021年4月頃 業界歴:約8年 「シマノさん」 ポジション:メタバース事業本部 3D背景デザイナー 入社時期:2022年4月頃 業界歴:約20年 ――まずは、お二人のこれまでの経歴や担当業務ついて教えて下さい。 YKさん(以下、YK):前職はコンシューマーゲーム会社で8年くらいコンセプトアーティストとして働いていました。その後、ホロアース開発チームにアートディレクターとして入社して、今は3年目になると思います。 業務としては、ホロアースに実装される背景やプロップのコンセプトアートデザインを担当しています。 ▲YKさん制作のコンセプトアート シマノさん(以下、シマノ):僕もYKさんと同じで、ゲーム業界にいました。20年くらいこの業界にはいて、コンシューマーやアーケード、スマホ・モバイル系、果ては遊技機系まで、ありとあらゆるジャンルを一通りこなしてきました。 そこから、ホロアースの開発チームに入って、ちょうど2年になるぐらいだと思います。 ホロアースでは、3D背景デザイナーとして主に背景の仕様策定や背景制作、そして最終的な品質管理を担当しています。 ――お二人が入社された当初のホロアースってどんな開発状況でしたか。 YK:2021年4月に入社したころは、まだホロアースの企画が立ち上がった最初期でして。最初に見せてもらったのは、Unityで無料アセットの中をタレントさんの3Dモデルが走っているだけというものでした。ホロアースで実現したいことの非常にラフなモックがあるだけで、具体的な骨子がまだしっかりある状態ではなかったです。 シマノ:そうですね。僕は2022年4月に入社したのですが、当時は3D背景チームがほぼない状態でした。なので、チームを組成するにあたって中心的なメンバーになって欲しいみたいな話を頂きました。 ――まだなにもない状態の時に参画されたんですね! では、今お二人がどういう風に仕事を進めているのかを教えてください。 YK:まず、プロデューサーやディレクターからプロダクト要件が降りてきます。 例えば、シミュレーションルームの要件では、ハウジングとクラフトができるマップ作りをオーダーされました。 「木を切ったら木材が手に入って、それを使ってクラフトとハウジングができる」などのUX(ユーザーエクスペリエンス)的な要件を満たしつつ、ホロアースの世界観として成立させるために、プロデューサーとデザインを詰めていきました。 ――そうして出来たコンセプトアートを元に3Dチームの方が作業をしていくという流れですね。コンセプトアートから3Dで作っていくにあたって意識していることなどありますか? シマノ:はい。基本的に3D側は元になるイメージがないと創造的な世界は勝手には作れません。 コンセプトを描く2Dアートが0から1を作る仕事だとするならば、僕の仕事はその1を100にすることだと思っています。 なので、貰ったコンセプトアートを可能な限り再現をしながら100にするために、2Dでは描かれていない裏側の風景とか、細かなディテールまで作り込むという感じで制作しています。 そして最終的に3D側でバランスの良い見た目になるように調整します。 ▲YKさん制作「シミュレーションエリア」のコンセプトアート ▲コンセプトアートには描かれていない木の裏側や細かいディテールの作り込み ――ホロアースの開発体制を見ていると、2Dチームと3Dチームが一丸となって開発しているイメージがあります。コンセプトアートが出来上がって、3Dで作り込んでいく段階になっても、密にコミュニケーションを取り合っていますよね。 シマノ:あまり畏まった感じではなく、聞きたい時に訪ねるという感じでやっています。例えば、立体化するにあたって、どういったテイストがいいか悩んでいる時に、YKさんに聞きに行くと、一緒に考えて下さって、2D側の考えと3D側の事情を織り交ぜながら、現実的な制作方法や制作の方向性を見極めていきます。 YK:最初から2Dで全てを伝えられるとは思ってはいなくて、デザインを制作する上で考えていたことなどを、こういった軽い会話の中で、詰めていけるっていう状態は凄い良いと思っています。 シマノ:アートの方が近くにいることによって、最終的なゴールイメージをブレずに保ったまま制作を進められるので、非常に良いと思っています。 ――メタバースという今までにないような分野をやっていく中で、プロデューサーやディレクターの意見が変わることもあると思いますが、それに対して、どう柔軟性を持って対応していますか? シマノ:僕の場合は、まず、作ったものを壊すことも制作の一つだと思っています。作って終わりではなく、初めに作ったものを出発点として、フィードバックを貰いながらどんどん直していきます。 一方で、3Dグラフィックチームはデザインのアウトプットとして1番最後の工程を担当しているので、締切に対する意識は非常に強く持たなくてはいけません。 なので、ずっと作り込んでいたいという気持ちと、締切に間に合わせるためにクオリティのラインを決めないといけないという考えがいつもせめぎ合っています。 YK:守らないといけないスケジュールの中で、ここだけは外せないという部分を決めて、どうしても妥協しないといけない部分は工夫して落とし所を決めています。 ――チームとして大きくなってきて、各メンバーとのコミュニケーションやチームビルディングに対してどうアプローチをしていますか? YK:そうですね。2Dチームに関しては、基本的に絶対にこうして欲しいみたいなものは、あえて設けていません。 まず各メンバーがやりたいことを出してもらって、なるべくそれを活かせる形でデザインに落としていくという感じですね。 シマノ:3D背景チームの場合は、大きな話と小さな話の2つがありまして、大きな話は、チームで大切な価値観を共有しあっているというところです。 お互いに尊重し合うこと、作り直しを厭わないこと、仲間を孤立させないこと、考えを否定しないこと。そういった気持ちをみんなが持ってくれています。 小さな話では、各メンバーのToDoを全部見える化しています。 口頭で言われた細かいオーダーを含めて全てToDoリストにすることで、タスク見逃しやタスクオーバーが起こらないよう管理し、タスクが適材適所かつ均一化できるようにしています。 ――ホロアースという今までにないようなサービスを作り上げていく上で、チームとして意識しているところはありますか? YK:さっきの話に少し繋がるんですが、プロデューサーのもっている世界観とか方針は大前提に大切にしつつ、その上で、なるべくメンバー個人個人の価値観を広げて、ホロアースに反映できたらいいなと思っています。 ――ちなみに、YKさん自身の世界観の広げ方や価値観のアップデートってどういったものですか? YK:長所を伸ばしたりとか、誰もチャレンジしていないところを考えています。 実際にあるものを参考にしながら、例えば、AとBの組み合わせは誰も見たことがないよなとか。 色々な背景とか世界観を組み合わせて誰も見たことのないようなものを日々インプットしながら探っています。 あとは、プロデューサーがもっている大枠の世界観を更に良いものにできるような世界観や価値観に対しては、なるべくアンテナを向けて摂取しようとしています。 ――シマノさんが、シミュレーションルームを作ったときのことを教えて下さい。 シマノ:シミュレーションルームの時はYKさんが描かれたコンセプトアートが出発点でした。 まずは、必死にコンセプトアートを観察し2Dイラストを頭の中で完全に3D化します。 その空間をしっかりを脳裏に保存したまま、DCCツールで3D再現していくという作業になります。 3Dで作っていく上で気をつけたことは、YKさんのイメージを損なわずになるべく素直に立体化したいというところです。 それがある程度できたと思ったら、2Dイラストで描かれていない周りの風景を360°破綻なく作っていくことに目を向けていきます。 ①コンセプトアート ②コンセプトアートから全体のモデリングをした状態 ③ライティングで全体の明るさや色味を調整した状態 ④周辺部分の作り込みやゲーム要素(ポータル)を入れた完成形 最後はテクニカルアーティスト(以下TA)と連携して独自のシェーダーや表現などを作ってもらい、全体のグラフィックレベルを1~2段階あげる作業を行います。 ▲TAと連携してステンシルと全天球動画を組み合わせて、独自の視差効果のある空の表現を生み出した ――表現の部分とか最後のディテールは、3Dモデルだけではできない場所があるので、TAと詰めていくという感じですよね。 シマノ:そうですね。そこで面白いのが、アートから3Dにフェーズが移り、3DからTAに相談をして、今度はTAがアートに相談や確認がいくというサイクルが意外とあるんですよね。 そこが僕は面白かったり、それで良くなっていくんだなっていうのを実感していますね。 ――今まで携わってきた開発現場ではあまりなかった環境ですか? シマノ:僕の感覚では、こんなに純粋なクリエイティブな環境っていうのはあまりないなと思います。 大体、締め切りとかに忙殺されて、間に合わせることに終始してしまうんですよ。 でも、ホロアースの開発では「このアセットの見た目をどうするか」とか、そういうことに時間を割けられる。 なんだったらそれが作業の6-7割を占めている感じがします。 YK:普通はアートも、デザインを作ったあとは3Dの方に関わることはあまりないのですが、 ホロアースの開発では、アウトプットに対して、2D側も責任を持って監修して、一緒にブラッシュアップしていくという環境が面白いと感じています。 ――そうやって、去年はキョウノミヤコやシミュレーションルームとしてリリースされましたね。ユーザーの反応を見て、なにか思うところとかあったりしますか? YK:まだまだコンテンツも不十分な中、それでも楽しんで頂いているユーザーさんをみると大変励みになります。 シマノ:実際に、多くのユーザーさんがシミュレーションルームとかキョウノミヤコとかを訪れてくれて、ぴょんぴょんと跳ねたりして、隅々までつっつくように見てくれているのを見ると、嬉しい反面、ドキドキもします。 ホロアースを遊んでくれるユーザーさんって、優しくも厳しいという2つの目線で見てくれているんですよね。 数多くの嬉しい言葉、そして時々鋭い指摘も頂けて、本当にありがたい存在です。 なので、リリース日は1番緊張するし、1番高まる瞬間ですね。 ▲2024年1月1日にオープンした正月仕様の「キョウノミヤコ」沢山のユーザーが初詣に訪れた ▲「年末ホロライブ〜ゆくホロくるホロ 2023▷2024〜」を大きなコタツを囲みながら、同時中継を楽しむユーザー YK:こんなに作りながらリリースするのは、コンシューマーではあまりない経験ですよね。 シマノ:そうですね。このライブ感が妙に面白いです。 ――作り込んでいける環境というのもありつつ、ユーザーさんと会話しながらリリースできる環境が両立できていますよね。 シマノ:あとは、プロデューサーから「ずっと作り続けていくものだから、本当の完成はもっと後でいい」みたいな方針を示してくれていて、ある意味ホッとしているところがあります。 この方針のお陰で、しっかりと地に足つけて、今回はここをしっかり作るとか、これは次回に持ち越すとか、どこに1番注力して作るかの整理ができるので、間に合わせるための妥協とかをしなくてする必要がなくなっています。 なので、ユーザーさんには、前回よりも良くなっていく、成長していくセカイ、グラフィックに期待を持ってもらいたいと思っています。 YK:そのためには、毎回ユーザーさんの信頼を裏切らないことが大切で、緊張感をもってやっていきたいと思っています。 ――最後に、これからチャレンジしていきたいことを教えて下さい。 シマノ:今も思っていることではあるのですが、最初のイメージのところで、アートチームに100%頼ってばかりもいられないなと思っていて、お互いに補完し合っていきたいと思っています。 0からの書き起こしではないと作れないようなイメージではない場合は、3D背景チームの方で、できる限りデザインを含めて逆に提案して作っていきたいです。 例えば、今作っている「オルタナティブ・シティ」は大きな街なので、細かい部分までアートチームに全て頼ることは不可能だと思っています。 なので、街路樹とか植え込みとか現実世界でも見かけるようなモチーフであれば、背景チームでうまくデザインして作っていくということを徐々にやっています。 今後はそういったところを強化していきたいと思っています。 YK:常日頃から、ホロアースならではの体験とは何だろうと頭を悩ませているのですが、景観や生き物等、細部に至るもののデザインがホロアースでしか得られない体験に結び付くよう作っていければと思っています。

Date

24.4.26

Category

  • デザイナー