サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
logicalbeat.jp
UnityProject知見のドキュメント化の取り組みに関して こんにちは、情熱開発部プログラマ課の青柳です。 すっかり夏本番という感じで溶けてしまいそうです。 今回はUnityプロジェクトを業務で行う上で知っておいて欲しい事を色々なプロジェクトで展開する目的で書いたドキュメントを公開します。 何故この文章を作ったか 弊社内でもUnityを使うプロジェクトを行ってきた経験によってUnityに関する知見が溜まってきてはいるのですが、それを中々プロジェクト外に展開出来ないままでした。 それを解消する為に、Unityプロジェクトを始める前に知っておいて欲しい事をまとめたのが今回の文章です。 ドキュメントはGitで管理し、プルリクエスト・レビューで変更履歴と理由を残していく形で運用しています。 注意点 注意点として、社内で軽いレビューは受けていますがほぼ書いたのが私、という事と、出来立てほやほやな
はじめに こんにちは、情熱開発部プログラム2課の安東です。 入社してから今月で丁度一年、業務では経験を積む機会がたくさんありましたが、その中で初めてマーシャリングというものを扱うことになりました。 しかし、Web上には入門向けの記事が多くなく、学ぶのに少し苦労しました。 そういう経緯もありましたので、今回はUnityでマーシャリングをしてC#とネイティブプラグイン間でやりとりできるよう入門向けに解説していきたいと思います。 前提 今回はUnityにおけるマーシャリングを扱います。 その中でも、C言語リンケージのBlittable型とそのポインタ・構造体のマーシャリングが行えるよう入門向けに解説していきます。 .NET Frameworkも同様にC#ですが動作環境が異なりますので、それらの差異に関しては別のサイトをご参考ください。 マーシャリングとは そもそも、マーシャリングという言葉を聞い
こんにちは!情熱開発部プログラム課の倉平です。 4月も中旬となり来るGWの予定を立て始めている頃ではないでしょうか? いくつになっても大型連休はワクワクしますね。 私は気になるゲームがちらほら出ているので連休中はガッツリ遊ぼうと思っています! さて、主題に入りましょう! 特定のオブジェクトにだけ効果をかけたいけど、カメラを増やすのも面倒だなと感じることがあると思います。 今日はそんな時に役に立つカメラ追加無しで描画分けを行う方法を説明させていただきます。 今回の記事はSRPをある程度触ったことがある人向けとなっております。 描画Passの追加等の説明は省かせて頂いております。 こちらご了承ください。 使用したUnityのバージョン Unity 2020.3.32f1 ■概要説明 青、赤のPlaneオブジェクトがあるシンプルなシーンです。 こちらにカスタムエフェクトでセピア調効果をかけると当
こんにちは!情熱開発部の金澤です! 年も明けて寒さが厳しくなってきましたが、皆様いかがお過ごしでしょうか。 私は冬だからか今回初めての技術ブログだからなのか分かりませんが震えています。 というわけで今回は、『C++ REST SDKを使用したhttp通信』についてご紹介していきたいと思います! C++ REST SDKとは C++ REST SDKとは「ネイティブ コードをクラウド環境に移行できるようにするためにマイクロソフトが踏み出した最初の 1 歩」とMicrosoftが提供しているオープンソースのライブラリです。 JSON対応や非同期通信はもちろん、Microsoftが提供していることもあり何よりインストールが非常に簡単で、VisualStudioからであればNuGetにて直ぐにインストールすることが出来ます。 また、C++との一貫性が高いのも魅力的ですね。 それでは早速cppres
こんにちは。情熱開発部プログラム課の安田です。 Visual Studioはじめ、各種C++コンパイラのC++20対応が着々と進む中、CEDEC2020でC++20の機能を紹介する講演が実施されるなど、ゲーム業界でもC++20導入の機運が高まっています。今回はC++20の新機能の中でも、個人的に特に気になっていた「モジュール」について紹介します。 1. C++20のモジュールとは? 2. C++のビルドの仕組み 3. 複数ファイルからなるプログラムのビルド 4. #includeを使う上での注意点 5. 改めてモジュールの利点を考えてみる 6. モジュールを試してみる 7. おわりに 参考資料 1. C++20のモジュールとは? モジュールとは、C++20で新たに導入される、 インクルードに代わる新たなプログラム分割の仕組みのことです。 cpprefjpによると、C++にモジュールが必要に
はじめに こんばんは、代表の堂前です! なんだかんだで今年も残り2ヶ月を切ってしまいました。早いものです。 徐々に寒くなりますが、いかがお過ごしでしょうか? 本日は講演の話をしようと思います。 Cygamesさんで行われている「スキルサーズデー」にて外部講演として招かれまして、講演をさせてもらいました。 その様子をお伝えしたいと思います。 (※Cygamesさんの方でも記事にしていただきました!) 講演の様子 Cygamesさんのスキルサーズデーに関しては、こちらをご覧いただくとどういうものか分かるかと思います。 自分が初めて知ったのは昨年のCEDECの講演でして、勉強会を維持させる大変さというのがよく分かり、興味深い講演でした。 そんなスキルサーズデーですが外部講師を招いて話をしてもらおうということになり、担当の古閑さんより自分のところに依頼が来たという形です。 なんでも外部講師の第一号
はじめに こんばんは、代表の堂前です! 技術的な話を書くのがだいぶ久しぶりになりました・・・。 今月までは忙しかったので、これからはたくさん書けるといいな〜と思っております。 それでは今回から数回にかけて、Unity描画のバッチング処理についてまとめていきます。 初回は「Static Batchingの処理の中身」についてお届けします。 ※検証したのはMacのUnity5.5.2f1になります。 バッチング処理とは? まず簡単に、バッチング処理とはというところと、その効果について触れます。 Unityのドキュメントはこちらになります。 ざっくりと言うと、同じマテリアルの複数のオブジェクトがある際、それを予め一つにまとめて描画するという仕組みです。 以下がその例になります。 今回のシーンはオブジェクトが8つあってそのマテリアルが全て同じ状況で、右2つはバッチングがON/OFFの時のFrame
はじめに こんばんは、代表の堂前です! 前回はStatic Batchingの処理の流れと中身について書いてみました。 今回はDynamic Batchingについて書こうかな〜と思っていたのですが、facebookにて一部不明点が挙がっていたので、カリングとStatic Batchingの兼ね合いの話を書こうと思います。 ※検証したのはMacのUnity5.5.2f1になります。 まずはUnity上で検証 今回も前回と同じシチュエーションで、8つのオブジェクトを同一マテリアルにし、それを全てStaticとしてバッチングを確認する状況にしています。 この状態でカメラを横方向にシフトし、一部オブジェクトを見えない状態にしてみます。 通常だとオブジェクト単位でカリング(見えないオブジェクトを早期に処理から外す)が掛かるのですが、Static Batchingで事前にまとめられたと思われるメッシ
はじめに こんばんは、代表の堂前です! 2/18に大阪で行われたGCC’17の話題です。 前回は「会場レポート編」でしたが、今回は実際にお話ししたスライドと、それに対する補足の話を少しだけします。 講演スライド 講演のスライドは以下になります。 (※pdf・53MB) 転載などはもちろん厳禁です。 pdfへの直リンクも禁止で、このページへのリンクの形でお願いします。 補足事項 本番は50分で、講演の時はいつもそうしているのですが、説明のために敢えて省いているところもあります。 それらについて少し触れていきます。 アスペクト比と画角 対応がそこまで苦じゃない部分として「アスペクト比」を挙げました。 コンシューマの場合は16:9のみで考えていれば、まず問題ありませんでした。 (数ドット縦に広いとか、そういうハードはありますが・・・。) アスペクト比が異なると3Dでは見える範囲が変わるのですが、
早い話、これらは「RenderTextureのコピー処理」となっています。 つまりOnRenderImage()は以下の流れになっていると推測できます。 描いていた絵(dest)を複製(src)する ↓ 複製した絵(src)を利用してイメージエフェクト後の絵を作る ↓ デフォルトターゲット(dest)に書き戻す 「src」「dst」は、OnRenderImage()の引数と思って下さい。 描画の一般的な処理として、srcとdestは同一のものだと絵が確実に崩れてしまうので、一旦コピーして使うということを行っています。 もう少し分かりやすく図式します。 これがOnRenderImageの大まかな流れです。 OnPostRender()の利用 OnRenderImage()はイメージエフェクトを作成するには理には叶っていて便利は便利ですが、都度、コピー処理が走るのが負荷的に気になります。 ここ
はじめに こんばんは、代表の堂前です! というより、明けましておめでとうございます。 堂前個人としてはだいぶ間が空いてしまいましたが、新年初のブログを書こうと思います! (昨年末は地獄の進行でなかなか時間が取れませんでした。。。) 今回のテーマですが、Unityでのビュー&プロジェクション行列についてまとめていこうと思います。 これを書こうと思ったきっかけですが、これら周りでスクリプトやシェーダを作成する際に非常に混乱することが度々おきまして・・・。 早い話、自分のメモとして残しておこうと思いました。 ※検証に利用したのはUnity5.5.0f3になります。 何がややこしいのか? 先程、「Unityのビュー&プロジェクション行列がややこしい」的なことを書きました。 今回の話を進めるにあたり、自分が何に対してややこしいと思っているかを先にまとめます。 ★ビュー行列 ・UnityのScene上
はじめに こんばんは、代表の堂前です! 今回はUnityというよりも一般的な描画関連の話をしていこうと思います。 取り上げるのは「16ビットカラー」についてです。(RGB565やARGB1555といったものです。) やや基本的な話ですが、改めて紹介していきます。 ※検証に利用したのはMacのUnity5.4.1p2になります。 カラーフォーマット 描画では当然の如くテクスチャを扱うことがあり、それらはカラーで構成されています。 最近ではHDRディスプレイなどの登場によりカラーフォーマットもfloatのものが出たりしていますが、基本はARGB8888(Unityだと「ARGB32」)が主流になると思います。 (注・フォーマットという意味では圧縮テクスチャが多く使われますが、上記はカラー画素としてのフォーマットを指します。) ただARGB8888だと1ピクセルにつき32ビット、つまり4バイトも
TEXCOORDに関して言えば、Unityは4セット用意してあるのですが、それぞれがx,yしか利用できません! 更にuv,uv2は割と用途が限定されがちなので、残りはuv3,uv4で、x,y,x,yの4要素しか残りません。 これはベクトル1つ分なので、非常に心許ないです。 UV座標が4セットなのは様々なスペックの互換を考えると致し方ないところがありますが、だとしてもそれぞれの後半のz,wも使わせてもらえるとわずかですが余裕も出てくると思います。 Mesh.SetUVsの利用 そんな中、少し古い話題にはなりますが、5.2.0よりMesh.SetUVsという関数が追加されました。 これを読むとx,yのみ、つまりVector2以外にもVector3やVector4も利用できそうという感じのものになってます。 これなら1つのTEXCOORDに4要素(x,y,z,w)持たせられるかもしれませんね。
MIPMAPレベルが大きくなればなるほど解像度が小さいテクスチャになります。 「大きなMIPMAPレベルを表示している=それより小さいレベルが無駄になっている」というのを意味するので、赤や緑のテクスチャは過度に大きなテクスチャが貼られていると言えます。 これを見てテクスチャを調整し、適切なサイズを見定めることが可能です。 カメラロック範囲検知ツール 次に紹介するのは「カメラロック範囲検知ツール」です。 カメラロックとは何か?という話ですが、これもやはり「見下ろし型RPG」というのがかかってきます。 普段プレイヤーを動かしていると、中央にそのプレイヤーが来るようにカメラが追従します。 ですがマップの端の方へ行くとカメラはプレイヤーを追わず、プレイヤーが画面端に行くようなシチュエーションになります。 (モチーフとなったSFC世代のRPGも基本はそんな感じになっていると思います。) ↓ ↓(画面
本連載で何度も書いていますが、PS Vitaの事を考慮しなければなりません。 そうなるとやはり負荷とメモリが心配になってきます。 DeferredだとG-Buffer分のメモリが必要なのと、それの合成コストが掛かってしまうのが気になります。 ということでForwardに決定したいところですが、ライトの数次第というところがあります。 本作のライト数について UnityのForwardでのライト数における処理の違いについては割愛します。(ドキュメント参照) が、ライト数に比例して負荷が上がるというのは間違いないです。 少なくするための思考として、本作の特徴である「見下ろし型RPG」としてゲーム性からライト数を考えます。 ・背景のライト(環境光とか灯篭とか)はLight Probesで処理してしまう。 →Light Probesは球面調和(SH)なので、ライト数とは関係ない。 →しかしそれらの光
はじめに 前回に引き続き、「いけにえと雪のセツナ(I am Setsuna)」(Tokyo RPG Factory)でのグラフィック処理の解説をしていきます!(全4回予定で今回は2回目) 前回は「フロー編」ということでグラフィック処理全体の流れに着目していきました。 今回は「グラフィック効果編」ということで、本作における個々の細かな表現がどの様に処理されているかを紹介していきます。 ※去る2016/4/5にもUnite2016にて一部公開致しましたが、本編はそれも含めつつの内容になっています。 そちらの資料と動画も合わせてご覧いただくのをオススメします。 大前提 「いけにえと雪のセツナ」自体の紹介は割愛致します。 (公式HPを是非ご覧ください。) で、前回も触れましたが今回で特に大きくなるポイントを挙げていきます。 それは「見下ろし型のRPGである」という点です。 ゲームの大半は上の様なカ
はじめに 本日より弊社が関わったタイトルで、(ご紹介できるものだけですが)そこで使った技術を紹介するブログを公開することになりました! 記念すべき初回ですが、7/19に英語版が発売になった「いけにえと雪のセツナ(I am Setsuna)」(Tokyo RPG Factory)で、弊社が関わったグラフィック処理を4回(予定)に分けて紹介していきます。 初回は「フロー編」です。 ※去る2016/4/5にもUnite2016にて一部公開致しましたが、本編はそれも含めつつの内容になっています。 そちらの資料と動画も合わせてご覧いただくのをオススメします。 ゲーム概要 「いけにえと雪のセツナ」自体の紹介は割愛致します。 (公式HPを是非ご覧ください。) 今後の回にも関わる、グラフィック処理面での重要なポイントを挙げていきます。 ・Unity5を利用していること。 ・見下ろし型のRPGであること。(
このページを最初にブックマークしてみませんか?
『logicalbeat.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く