せまい部屋

web/gameエンジニアのweblog

UE4 + HTC VIVE モニタリング表示領域をいじる

通常のVRPreview再生だと左右に黒帯が入った状態で再生されるが、展示その他ギャラリーがゲーム画面を見るのを想定すると、フルHD等一般的な解像度になっててほしいとか微妙な要望があるので調べた。

調査

まず表示解像度の変更と思い込んでそのあたりから調べ。 http://pafuhana1213.hatenablog.com/entry/2015/12/08/001421 にまてめてらっしゃる方もいらっしゃり素晴らしい限り。 HMDに関するコマンドがたくさんあって実行してみるが、Oculus用のコマンドなのか動作はしてるようだけどモニタリング側がフリーズして、HMDもSteamの待機中のまま動かない感じだった。
https://answers.unrealengine.com/questions/311721/vr-mirror-standard-output.html

hmd mirror mode [0|1|2] でなく hmd mirror 1 とか指定するとviveでも二眼映像になったり反応はある。けどAnswerHubにあるような0~2の変更はできないようでフリーズしてしまっていた。多分この辺のコンソールからコマンド叩くと止まるとかの諸々
https://forums.unrealengine.com/showthread.php?110529-VR-Mirror-Window-turned-Black

最終的にはこちらのフォーラムで解決へ
https://forums.unrealengine.com/showthread.php?117032-Problem-about-monitor-resolution-display-in-vive-vr-mode

エンジン内のSteamVRRender.cppを更新して、ミラーリング用に切り出す領域を変えると目的自体は達成できる模様。変数変えるだけなので16:9でなくても求める比率で指定すればどうとでもなりそう。自分の環境ではUE4ビルドして実現できたので良しとしてる。 EpicGamesLauncherから動かしてる場合はできないこともないのかもしれないけどちょっと都合がわからない。元々はReddit内でRawDataがどうやってるかから発展してるぽく、エンジンのコード読んで対応してるあたりは参考にしたい。

参考動画

www.youtube.com

Engine/Plugins/Runtime/Steam/SteamVR/Private/SteamVRRender.cpp の更新

 if (WindowMirrorMode == 1)
    {
        // need to clear when rendering only one eye since the borders won't be touched by the DrawRect below
        RHICmdList.ClearColorTexture(BackBuffer, FLinearColor::Black, FIntRect());

        /*
       RendererModule->DrawRectangle(
           RHICmdList,
           
           FIntPoint(ViewportWidth, ViewportHeight),
           FIntPointViewportWidth / 4, 0,
           ViewportWidth / 2, ViewportHeight,
           0.1f, 0.2f,
           0.3f, 0.6f,(1, 1),
           *VertexShader,
           EDRF_Default);
       */
    
        RendererModule->DrawRectangle(
            RHICmdList,
            0, 0,
            ViewportWidth, ViewportHeight,
            0.006f, 0.2825f,
            0.44f, 0.4425f,
            FIntPoint(ViewportWidth, ViewportHeight),
            FIntPoint(1, 1),
            *VertexShader,
            EDRF_Default);
    }
    else if (WindowMirrorMode == 2)
    ...

できたこと

f:id:takoji3:20170411133835p:plain

f:id:takoji3:20170411133854p:plain

になった

まとめ

UE4がんがん更新されてるのでこのあたりも将来的には設定で変更できるようになるのではなかろうかと思いつつの対応。今年のUnite早割も無事申込んだのでまだしばらくゲームエンジンその周辺をいじり続ける所存。

ライティングシナリオ

直近Unreal Engine使っているので備忘録。Unreal Engine4.14からもいろいろ機能がのってるぽいですが調べて大抵英語だったので書く。VR向けにパフォーマンス向上等なされてる模様ですが、各機能の詳細語れるほどじゃないので他所に。

www.unrealengine.com

Lighting Scenarioは公式ブログにも手順自体はある、し流れは実質これだけ
https://answers.unrealengine.com/questions/512084/who-can-explain-of-lighting-scenario-feature.html

今回は丁度ステージ切り替えをサブレベルのロードで倒していこうとしていたところ、別物になるライトがどうやればいい感じになるか探ってたら機能が出てたので使ってみた次第。


サブレベル追加して別個の平行光源のライトを各レベルに配置する。

f:id:takoji3:20170129234226p:plain

わかりやすいのでメインになるレベルの下にLightingA(緑)とLightingB(紫)を用意。

f:id:takoji3:20170129234711p:plain

f:id:takoji3:20170129234733p:plain

サブレベルの表示非表示を変えながらBuild Lighting Onlyでひとまず焼いて目的達成。
次いで適当にブループリントおいて逐次切り替えてみる。LoadStreamLevelで単純につないでいるので一瞬間がある気もするけど、実際はステージ遷移だったりでなにがしか画面にアクションが起きていると思われるので気にならないよう落とし込めるものと思う。ひとまず今回はこんな感じで進捗出すことに成功している。

f:id:takoji3:20170129235309p:plain

f:id:takoji3:20170129235644g:plain


因みにエディタ上で問題ないけどビルド後実行時にクラッシュしてたりしたけどそれっぽいことがLighting Scenarioで起きることもあるぽい。自分のとこでは現状アクティブ切り替えてるけどこれはこれで問題かもしれないので4.15が来たら早速アップデートしようと思う。

Crash in Standalone/Packaged Game on Win7 when unloading Lighting Scenario Streaming Level - UE4 AnswerHub

UE-38712

UnityからUnreal Engine移行してきてブループリントに始まりGameModeやらGameInstance、Online Subsystem、NavMeshもろもろ躓きながら見てるけど、結論慣れなので使いこなせるようにやってく所存

オブジェクト指向設計実践ガイド感想

せっかくブログあるのだし腐ってないでしょぼくても大なり小なり書こうと思った。去年2016年の冬前ほどに会社のマネージャーが颯爽と買ってきて読み終わる前にそれとなく貸してくれた。

f:id:takoji3:20161127170544j:plain:w400

所感

クラスベースの設計で具体例と共に勉強したい
継承とかmix inとか使い所が曖昧
なんとなくRubyオブジェクト指向どうやるの

とか思うふしがある場合はアプリケーションのコード書いたり機能設計を考える上で一つ指標になることあるなと思う。訳者あとがきにも初心者の方の手助けになるととても良いというふうにも書いてある。逆に数々の案件を流麗なクラス設計を目指しながら数多くこなしてきたような熟練エンジニア諸兄には初心寄りなので再確認程度になると感じた。

進みは自転車旅行を題材にしたオブジェクト指向を手順ベースで改造していくスタイルで理論寄りな説明を読む感じでなく手を動かすと良さそうな作りなので体で覚えるという意味では読みやすいし、単純に説明がわかりやすい印象もあった。 個人的に注目は最後9章のテスト。以前のユニットテストの設計や在り方を問う事案があったため、自分の認識も含めて再度勉強になったのでタイムリーだった。

最もコストが高く最も利用性が低いテストは、不安定な内部の実装に結合することで、オブジェクトの格納壁に穴を開けます。

みたいな記述は個人的に座布団一枚で、仮にオブジェクトの持つパブリックなインターフェースに変更を入れるのであれば伴って既存テスト失敗は良いと思うけども、内部実装を変えて一緒におちるテストは確かに困る。外見を変えず中身を変えるリファクタリングの成否を担保してくれるようなテストでないと、まして仕事ともなれば設計開発とビジネス要求の狭間になるので、テストがただうっとおしいだけの存在に、と経験的に感じる。インターフェース自体やスーパークラスのテストをRubyでいうModuleに切り出してるのは今までやっていなかったような気がするので機会があれば実践したいところ。インターフェースを意識するというのもこういった基本的な書物で確認できるし良いと感じる。

とりあえず知識を付けたかったり自分は出来ると思ってしまっている人についぞ渡したりするととても良い本だと思った。