『PSO2ニュージェネシス』における雪原の跡付け表現について

1.はじめに

株式会社セガ 第3事業部 第3オンライン研究開発プログラム1部の釘田と申します。
連日の寒さも徐々に明け、春の訪れを感じる頃合いです。
今年の冬は何度か弊社オフィスのある大崎でも雪が降りました。

私はこれまで雪のあまり降らない地域で過ごしてきたこともあり、
雪が積もるとつい童心に帰り、雪の上を歩きたくなります。

この雪の上で跡が付く様子ですが、ゲームではどのように表現されているでしょうか?
今回の記事では『ファンタシースターオンライン2 ニュージェネシス』における
雪原の跡付け表現について紹介したいと思います。

2.目次

3.前置き

記事内の画像は開発時のゲーム画面となります。
実際にリリースされているゲーム画面とは異なる場合もありますので、あらかじめご了承ください。
また、以降『ファンタシースターオンライン2ニュージェネシス』のことを『NGS』と表記します。

4.フィールドでの雪原の跡付け表現

まず、『NGS』における雪と氷のフィールドである「クヴァリス」での雪原の跡付け表現について説明します。
「クヴァリス」では一部の雪原において、キャラクターが歩いた場所に足跡が残ります。

4.1.キャラクターの足跡表現

足跡を雪原に残すにはどうすればいいでしょうか?

まずは実際に現実世界で雪がどのようにしてへこむかについて考えてみましょう。
冒頭の写真のような雪が積もった道を思い浮かべてみてください。

雪は柔らかいため、足を踏み入れると雪が積もっていた高さから踏み込んだ深さまでへこみ、足跡として残ります。

『NGS』では、地面の高さを雪の厚みの分だけ上昇させ、キャラクターが歩いた場所をへこませています。
これは以下のような処理で実現できそうです。

  1. 地形とキャラクターに対する深度撮影
  2. 軌跡テクスチャの作成
  3. 雪面の変形

それでは実際の処理について見ていきましょう。

4.1.1.地形とキャラクターに対する深度撮影

キャラクターの足によってどの位置でどの程度の深さまでへこませるかを決めるために、
カメラを地面の下から上方向に向けて地形とキャラクターに対して深度撮影を行います。

4.1.2.軌跡テクスチャの作成

次に、跡を付ける深さの情報が格納された軌跡テクスチャを作成します。
雪がへこむのは以下の図のように、キャラクターの足が地面と雪面の間にあるときです。

条件式で表すと以下のようになります。

地面の高さ < キャラクターの高さ < 雪面の高さ

ここでは説明のため、キャラクターの足の位置を「キャラクターの高さ」と表現します。

先ほどの深度撮影の結果を用いて
「キャラクターの高さ」はキャラクター深度から、「地面の高さ」は地形深度から求まります。
また、「雪面の高さ」は「地面の高さ」と「雪の厚み」を合わせた値です。
「雪の厚み」は内部的に設定されたパラメータで、場所によって厚みが異なります。

「雪をへこませる割合」は雪がへこんでいない状態を0.0、すべてへこんでいる状態を1.0として、
以下のように計算します。

雪をへこませる割合 = (地面の高さ + 雪の厚み - キャラクターの高さ) /  雪の厚み

シェーダーで計算された値は軌跡テクスチャへと書き込まれます。

地形深度を用いているため、傾斜のある地形などでもへこませることができます。

4.1.2.1.軌跡テクスチャのフィルタ処理

次に作成した軌跡テクスチャに対して、より自然なへこみ跡を表現するため、フィルタ処理をかけています。
ここで冒頭の写真を再度見てみましょう。

足跡と雪の縁の部分に着目してみると、足跡側ではへこみが緩やかに広がっています。
また、雪側では踏まれて押し出された雪によって盛り上がっていることがわかります。

これらを表現するために、フィルタ処理では平滑化を行い、へこみを緩やかにしたうえで、
へこみ部分の縁の高さを調整し隆起させています。

以下は実際のゲーム内でのフィルタ処理の有無の比較画像になります。

フィルタ処理をかけることで、全体的に滑らかな跡になり、縁部分での雪の盛り上がりも表現できています。

また、軌跡テクスチャにはプレイヤーキャラクターを中心として80m四方の範囲内の跡が記録されており、
プレイヤーキャラクターからの距離に応じて徐々に足跡が消えていく表現についてもフィルタ処理で行っています。

4.1.3.雪面の変形

最後は雪面の描画時に、作成した軌跡テクスチャの情報を元に雪面を変形させます。
雪面の変形にはテッセレーション処理を用います。

テッセレーション処理では地形モデルのポリゴンを分割し、分割されたポリゴンの頂点の位置を変更します。
頂点位置の変更の際に軌跡テクスチャを参照することで、跡付けを行う部分をへこませます。

下記がテッセレーション処理の有無の比較画像になります。

テッセレーションなし(左)とテッセレーションあり(右)の比較

ちなみに、テッセレーションに対応していない場合でも、軌跡テクスチャを用いた法線の調整やAOにより陰影をつけることで疑似的に表現しています。

5.ハウジングコンテンツでの雪原の跡付け表現

ここまではフィールドにおける雪原の跡付け表現について説明しました。

ここからは、『NGS』のハウジングコンテンツである、「クリエイティブスペース」の雪山風マップ
「クヴァリステーマ」における雪原の跡付け表現について説明します。

「クリエイティブスペース」内ではフィールドと同様のキャラクターによる雪への跡付けだけでなく、
プレイヤーが設置可能なオブジェクトである「ビルドパーツ」による跡付けにも対応しています。

5.1.オブジェクトよる跡付け表現

基本的な処理の流れについてはフィールドでの跡付けと同様です。

今回はオブジェクトによる跡付けを行うため、追加でオブジェクトに対する深度撮影を行い、
軌跡テクスチャ作成時にオブジェクトの高さも考慮します。

処理の流れは以下の通りです。

  1. オブジェクトに対する深度撮影
  2. 地形とキャラクターに対する深度撮影
  3. オブジェクトの深度を考慮した軌跡テクスチャの作成
  4. 雪面の変形

以降の説明では、1. と 3. について紹介します。

5.1.1.オブジェクトに対する深度撮影

まずは 「1. オブジェクトに対する深度撮影」についての説明です。

オブジェクトを設置する際にカメラを地面の下から上方向に向け、
オブジェクトの表面と背面の深度を撮影します。
描画結果は二枚のキャッシュテクスチャに格納されます。
表面と背面の両方で深度を描画する理由については後述します。

「クリエイティブスペース」ではオブジェクトの設置だけでなく、地形の高さも編集することができます。
オブジェクトに対する深度撮影の際には地形の編集が可能な、高さ100m、256m四方の範囲が収まるように
キャッシュテクスチャへ深度が書き込まれます。

これによって「クリエイティブスペース」内にいる間は、オブジェクトの跡が付いた場所から離れても跡が残ります。

また、オブジェクトに対する深度撮影はオブジェクト設置時に一度だけ行うことで、
深度撮影による負荷を抑えています。

5.1.2.オブジェクトの深度を考慮した軌跡テクスチャの作成

次に「3. オブジェクトの深度を考慮した軌跡テクスチャの作成」について説明します。

オブジェクト深度の使い方について、
まずはキャラクターの場合と同じように深度テクスチャを一つだけ使う場合を考えてみましょう。

次のようなオブジェクトを設置します。

雪がへこむのは、オブジェクトの底面が地面と雪面の間にあるときです。

条件式で表すと以下のようになります。

地面の高さ < オブジェクト底面の高さ < 雪面の高さ

ここでオブジェクト底面の位置を、説明のため「オブジェクト底面の高さ」と表現します。
「オブジェクト底面の高さ」はカメラを地面の下から上方向に向け、
オブジェクトに対して深度撮影した、オブジェクトの表面の深度から求まります。

「雪をへこませる割合」についてもキャラクターの場合と同様に計算します。

ここまではキャラクターの場合と同様に、オブジェクト表面のみの深度撮影で問題なさそうです。

では次のケースを見ていきましょう。

「クリエイティブスペース」ではプレイヤーが自由にオブジェクトを設置でき、
地形の高さも編集できるため、オブジェクトが地形に埋まる場合があります。
以下のようにオブジェクトを地形に埋めた状態で配置する場合はどうでしょうか?

地形に埋まった状態で設置した場合、オブジェクトの底面が地面よりも低くなってしまい、
埋まった箇所で跡が付きません。

そこで、地面の高さよりも低い位置にオブジェクト底面が来た場合は、
「雪をへこませる割合」を1.0とし、雪をすべてへこませます。

この場合は以下のように地形に埋まった箇所でも跡を付けることができます。

しかし、上記の改善を加えた場合でも別の問題が二つ起きてしまいます。
次で詳しく見ていきましょう。

5.1.2.1.オブジェクトの深度撮影が表面のみの場合に起きる問題

まず一つ目はオブジェクトが完全に地中に埋まってしまった場合です。

この場合だと「オブジェクト底面の高さ」だけではオブジェクトが完全に埋まったかの判定が取れず、
以下のように不自然に跡が付いてしまいます。

二つ目の問題はオブジェクトを回転させたときに起きます。
先ほどのオブジェクトを次のように回転させ、一部地中に埋まった状態で設置する場合を考えてみましょう。

この場合も完全に埋まった場合と同様に、地中に埋まって隠れってしまった部分で不自然に跡が付いてしまいます。

これらの問題に対応するために、オブジェクトに関しては表面と裏面の両面で深度を描画しています。
表面と裏面の深度の使い方について、先ほど回転させて設置した場合を例に見ていきます。

まず、オブジェクトの上面が地面よりも上にくる領域に着目します。

条件としては以下のようになります。

地面の高さ < オブジェクト上面の高さ

ここでも底面と同様に、オブジェクト上面の位置を、説明のため「オブジェクト上面の高さ」と表現します。
「オブジェクト上面の高さ」はカメラを地面の下から上方向に向け、オブジェクトに対して深度撮影した、
オブジェクトの背面の深度から求まります。

次に、「オブジェクト底面の高さ」を用いて雪をへこませる部分を決めます。

上図の①のように、オブジェクト底面が地面と雪面の間にくる場合は、先ほどの説明の通り、
キャラクターでの跡付けと同様の方法で「雪をへこませる割合」を計算します。

また、上図の②のようにオブジェクトの底面が地面よりも下にくる場合は、
「雪をへこませる割合」を1.0とし、雪をすべてへこませます。

これにより、オブジェクトが完全に地中に埋まってしまう場合や、
一部だけ埋まってしまう場合に対しても自然な跡付けを行うことができます。

最終的に二枚のキャッシュテクスチャに保存されたオブジェクト深度、キャラクター深度、
地形深度を用いて軌跡を描き、キャラクターの跡付けの際と同様のフィルタ処理を経て、
「クリエイティブスペース」での軌跡テクスチャができます。

6.まとめ

今回『NGS』における雪原表現について、フィールドとハウジングコンテンツにおける事例を紹介しました。

フィールドではキャラクターの足跡による跡付け、
ハウジングコンテンツでは自由な配置を踏まえたオブジェクトによる跡付けについて説明させていただきました。

現実世界は目を引く景色、心を動かす風景、興味深い光学現象であふれています。
それらを注意深く観察し、ゲームに落とし込むことでさらに感動を与える表現が生まれると思っています。

今回紹介した手法は目新しいものではありませんが、何かの参考になりましたら幸いです。

7.最後に

セガでは一緒に働く仲間を募集しています。
共に感動体験を色々な人に提供できるようなゲームとそのグラフィックス表現を作りませんか?
もしご興味を持たれましたら下記のサイトにアクセスをお願いいたします。

採用サイト

SIEM on Amazon OpenSearch Serviceによるセキュリティログの可視化について

はじめに

株式会社セガ ゲームコンテンツ&サービス事業本部技術本部開発IT支援部の長谷川と申します。今回はセキュリティログの活用法の一例としてSIEMを用いた可視化方法を紹介します。

目次

背景

昨今セキュリティ対策不足によるデータの抽出やサービス操作される被害が発生しており、ログからユーザの行動を抽出し、可視化するまでを一括管理できるものが求められていました。さまざまなサービスの中でSIEM on Amazon OpenSearch Serviceにてログ情報からユーザの行動を可視化・検索により原因を改善するができるため、利用し始めました。 セキュリティログをgrepやAthena利用して調査を行ってきましたが、可視化を行うまでは進んでおらず全体的なセキュリティを確認するまで相当な時間がかかっていました。上記のサービスを利用することで、原因特定までの時間が軽減されました。

Opensearch(Elasticsearch)とは

  • 大容量データを処理することを想定した全文検索エンジン
  • 複数のノードにデータ分散して保存する分散設計
  • システムログの可視化・検知やユーザへのレコメンドや分析など多種多様な範囲で利用可能

SIEMとは

  • SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。Amazon OpenSearch Service は、OpenSearch と OpenSearch Dashboards を大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。Amazon OpenSearch Service の環境に SIEM として必要な機能を実装したのが SIEM on Amazon ES です。

github.com

Cognitoとは

大きくユーザプールとIDプールに分けて認証・認可を行うシステムです

ユーザプールとは

  • ユーザの作成、管理及び認証を行うユーザディレクトリです
  • アプリからの多数の承認フローが利用可能です
  • サインイン後に発行されるトークンを用いて、認証されたサービスへアクセスを行います

IDプールとは

  • ユーザプールにて認証されたユーザがどのリソースへのアクセスに対してユーザの権限を管理します
  • 未承認のユーザに対して、一時的なリソースへのアクセス権を付与することができます
  • ユーザのアクセス権をルールベースおよびアクセスベースでの制御が可能です

アーキテクチャ

設定方法

※今回はセキュリティ面を考慮しまして、VPC内でOpenSearchを構築いたします

  1. SIEMの設定方法は下記より構築しています SIEM構築
  2. ECS on Fargate,SecretsManager,Cognito,ELB,Route53サービスの作成します
    1. terraformにより作成(作成方法については割愛します)
  3. Cognito設定を一部抜粋して紹介します
    1. ユーザプールの作成

      1. 該当のユーザプールのサインインエクスペリエンス欄より、多機能認証を必須設定する
      2. アプリケーション総合よりアプリケーションクライアントの作成をします
        1. 認証フローについては該当の項目を選択します

          Note If you don't specify a value for ExplicitAuthFlows, your user client supports ALLOW_REFRESH_TOKEN_AUTH, ALLOW_USER_SRP_AUTH, and ALLOW_CUSTOM_AUTH. docs.aws.amazon.com

        2. コールバックURL,サインアウトURLを記入します
    2. IDプールを作成します

      1. ユーザアクセス欄より認証されたユーザに対するロールを作成します
  4. nginxプロキシによるCognitio認証設定します
    1. https://repost.aws/ja/knowledge-center/opensearch-outside-vpc-nginx
    2. セキュリティの観点より環境情報などをSecretsManagerより値を取得し、nginxに取得した環境変数を渡します ※下記はタスク定義の設定を抜粋して記載しています
{
    "containerDefinitions": [
    { ------ 中略 ------
        "secrets": [
            {
                "name": "opensearch_domain",
                "valueFrom": <secretsmanager_arn>:<opensearch_domain_key>::
            },
            {
                "name": "cognito_domain",
                "valueFrom": <secretsmanager_arn>:<cognito_domain_key>::
            }
        ]
    }
}

Cognitoによるログイン

  • SIEMのURLにアクセスすることでCognito認証によるログインを行います
  • MFA設定されている場合は次にTOTPよりコードを入力します

セキュリティログの可視化

  • Discover画面にて特定のインデックスで取り込んだログを表示が可能になります

    • フィルターやSearch欄でクエリで絞り込むことで特定ログ・項目の絞り込みが可能になります
  • DashBoardにおいても特定フィルター、特定アカウント、特定ACLの絞り込みにより必要なデータの可視化が可能になります


    クロスアカウントのCloudTrailログの可視化


WAFログの可視化

補足

※今回はアカウント間のデータを一括収集を行い、データの可視化を行う例となっております。

  • 特定の条件(特定のIP、国、UAからDDosアタック)が発生した場合にOpensearchのアラート通知を送るなどでシステム改善の気づきを与えます
  • セキュリティログに限らずアクセスログも収集しているため、Athenaに頼らずに検索や可視化までが一括して可能になるため汎用的な調査が可能になります
  • アクセスログ(CloudFront,ELB,WAF,VPCFlowログなど)の可視化により不要に開放しているセキュリティグループやパスを改善する手がかりを得られ、システム改善にも貢献します
  • 他のメンバーにも確認しやすいDashBoardになっているため、インフラ面の改善に限らずアプリケーション側の改善やBotなどの防ぐべき対象を可視化することができます

まとめ

  • セキュリティログの一元管理および可視化としてSIEMを利用しました
  • 一括管理することで、情報が整理されて必要な条件下でのセキュリティの対策を包括的に行うことが可能になります
  • S3のトリガー経由でログの取り込みが行われるため、同一アカウント・クロスアカウントに限らず様々なサービスログを取り込むことも可能になります

※まずは、セキュリティに不安がある方や様々なサービスを用いて通知疲れになっている方はSIEMを用いて一元管理して可視化してみると効率的な監視の手がかりがつかめると思います。

セガで働くことにご興味を持たれましたら下記サイトにアクセスお願いします。 www.sega.co.jp (C)SEGA

参考

『PSO2 ニュージェネシス』におけるトゥーン表示対応について

1.はじめに

株式会社セガ 技術本部 技術統括室 ソフトシステムセクションの西濱 高志と申します。 今回の記事では『ファンタシースターオンライン2 ニュージェネシス』におけるトゥーン表示対応について紹介いたします。

2.目次

3.前置き

記事内の画像は開発時のゲーム画面となります。実際にリリースされているゲーム画面とは異なるところもありますので、あらかじめご了承下さい。

また、表記として『ファンタシースターオンライン2 ニュージェネシス』のことを『NGS』、『ファンタシースターオンライン2』のことを『PSO2』と呼称することにします。

トゥーンレンダリングに関する最新技術の話はありませんが、何かしら参考になれば幸いです。

4.トゥーンレンダリングとは?

トゥーンレンダリングとは、コンピュータグラフィックスにおいてアニメ風、広くは漫画やイラスト風の作画でレンダリングする手法のことを言います。 セルシェーディングとも呼ばれ、ゲームの表現において個人、企業問わず採用する例が増えています。

トゥーンレンダリングを実現する上で、重要な要素となるのが「陰影のマルチトーン化」と「アウトライン表現」の2点になります。

4.1.陰影のマルチトーン化

トゥーンレンダリングにおける陰影は、物理的な計算を解いて表現するフォトリアルな陰影とは違い、デザイナー(アーティスト)が指定、調整した色で陰影も表現されることが多いです。

一般的な実装としては色の段階を設定したテクスチャ(ランプテクスチャ)を用意し、陰影の表現に使用する形が多いです。

しかし陰影を段階的にする都合上、人間の顔など複雑な凹凸がある物体では陰影が綺麗にならないことが多いです。 このため、トゥーンレンダリングでは物体の法線を調整して陰影を綺麗にし、アニメのような表現に近づけるといった工夫がされています。

この記事では、このようなトゥーンレンダリングにおける陰影の段階化を「陰影のマルチトーン化」と呼称することにします。

4.2.アウトライン表現

イラストやアニメにおける、「線画」を表現するため、アウトラインの表示もトゥーンレンダリングでは重要な要素になります。

実装方法としては、「背面法」と「輪郭線の抽出」の二つがあります。 「背面法」とは対象のモデルについて頂点を法線方向に拡大して裏面を描画した後、通常の描画を上塗りすることでアウトラインを表現する手法になります。1

「輪郭線の抽出」とは、レンダリング途中で生成した深度情報等をもとにフィルタ処理をすることで輪郭線の抽出を行い、アウトラインを描画する手法になります。 下記図は、出力された画像に対してSobelフィルタを用いてアウトラインを描画する例になります。

それぞれ特徴があり、まとめると下記のようになります。

手法 クォリティ 処理負荷 モデルデータの改良
背面法 描画する物体が多くなるほど高くなる 必要
輪郭線の抽出 描画する物体に関わらずほぼ一定 不要

このため、プレイヤー等、描画する物体が少ない場合はクォリティが高い「背面法」、背景や小物など描画する物体が多い場合は処理負荷を抑えられる「輪郭線の抽出」と使い分けをすることが、最近のゲームでは多いです。

5.『NGS』におけるトゥーン表示対応について

『NGS』では、元々トゥーンレンダリングを想定してモデルデータを作成していません。 このため、いくつか異なるアプローチで実装する必要がありました。 ここでは具体的にどのような実装をしたのかについて紹介いたします。

5.1.『NGS』のレンダリングシステムについて

『NGS』では、不透明の描画について「ディファードレンダリング」を行い、半透明、カットイン画面で「フォワードレンダリング」を行うという実装になっています。 通常のレンダリングパスを図にしたものが下記になります。

また、描画したGBufferの内容が下記になります。

前述したように、モデルデータがトゥーン表示用のものではないので必要な情報を適宜GBuffer等から取得して、活用していくことで実装しました。 最終的なトゥーン表示におけるレンダリングパスが下記になります。

5.2.拡散反射光(陰影)のマルチトーン表現

最初に拡散反射光(陰影)のマルチトーン表現について説明します。 前述したように、拡散反射光(陰影)のマルチトーン表現を行う際はランプテクスチャを用意して、陰影付けを行うのが一般的です。

しかし、『NGS』の既存のモデルデータにランプテクスチャを追加するのは難しく、GBufferにモデル毎のランプテクスチャの値を入れるための容量もありません。 なので、一律のパラメータを用意し、計算で陰影付けを行いました。

具体的なパラメータは下記になります。

struct ToonDiffuseParameter
{
    float brightness;     //!< 陰影の明るさ
    float subsurface;     //!< どの程度表面下散乱の色(血の色)を使用するか
    float threshold;      //!< どの段階から暗くするか
    float gradation;      //!< どの程度陰影をくっきりさせるか
}

ToonDiffuseParameter m_diffuse_bright; //!< 明るい部分のパラメータ
ToonDiffuseParameter m_diffuse_middle; //!< 中間部分のパラメータ
ToonDiffuseParameter m_diffuse_dark;   //!< 暗い部分のパラメータ

これらのパラメータを用いて、陰影を3段階に分けています。

『NGS』の拡散反射光は「Lambert BRDF」を使用しています。 このため、トゥーンレンダリングにおいてもモデルの法線とライトの内積値を元に、陰影を3段階に分けて陰影付けに使用しています。 実際にパラメータを調整すると下記のように陰影の調整ができます。

また、GBufferにどのシェーダを使用しているかの情報(ShaderID)を格納しているため、陰影をつけている物体の判別ができます。 これを用いて『NGS』では「毛髪用のパラメータ」と、「それ以外のパラメータ」の二つを用意して別々で調整ができるようにしています。2

5.3.鏡面反射光(スぺキュラ)のマルチトーン表現

次にスぺキュラのマルチトーン表現について説明します。 トゥーンレンダリングのスぺキュラ表現では、ワンポイントで表現することが多いかと思います。 実装方法としては、「スペキュラ自体をテクスチャに描きこむ」、或いは「スぺキュラマスクを用意して指定した箇所のみスペキュラを描く」等があります。

しかし、『NGS』ではゲーム中に登場するNPCの「グレン」のように、顔の色がほぼ黒色のキャラクターを作ることができます。 このようなキャラクターは前述した、「拡散反射光(陰影)のマルチトーン化」をしても陰影ができず、真っ黒になってしまうといったことが発生しました。

このため、『NGS』でも「陰影のマルチトーン化」と同様に「スぺキュラのマルチトーン化」を行うことで、黒色のキャラクターでもアニメ調のような陰影が見えるように実装を行いました。 下記が調整するパラメータになります。

struct ToonSpecularParameter
{
    float brightness;     //!< スペキュラの明るさ
    float exponent;       //!< スペキュラの広がり
    float gradation;      //!< どの程度くっきりさせるか
}

ToonSpecularParameter m_specular_bright; //!< 明るい部分のパラメータ
ToonSpecularParameter m_specular_middle; //!< 中間色のパラメータ
ToonSpecularParameter m_specular_dark;   //!< 暗い部分のパラメータ

基本的には「拡散反射光(陰影)のマルチトーン化」とほぼ同じような処理でスぺキュラを3段階に分けて描画しています。

実際にパラメータを調整すると下記のような表示になります。

特にパラメータの調整では黒色のキャラクターでも真っ黒な顔にならないようにしつつ、キャスト(ロボット)等の金属の光沢がカッコよく表現できるように調整しました。

また、スペキュラのマルチトーン化は「肌」、「毛髪」、「その他」で別のパラメータを調整しています。

5.4.アウトライン表現

次に、「アウトライン表現」について説明します。 前述したように、トゥーンレンダリングのアウトライン表現では「背面法」と「輪郭線の抽出」の二つが手法としてあります。 『NGS』では、下記のような制約があり「背面法」を採用することができませんでした。

  • モデルについて、片面しかないモデルやハードエッジを使用しているモデルがあり、法線方向に拡大した時にアウトラインがひび割れてしまう等、不自然な描画になってしまうことがある。
  • 多数のプレイヤー、NPCをトゥーン表示にする必要があり、「背面法」では処理負荷が高くなってしまう。
  • 半透明のアウトラインについて対応することが難しい。

このため、「輪郭線の抽出」を用いてアウトライン表現を実装しました。

5.4.3.輪郭線の抽出

『NGS』ではGBufferのうち「深度」、「法線」、「マテリアル」情報を用いて輪郭線の抽出を行いました。 処理としては、近傍の値と比較して一定以上の差異がある場合、アウトラインを描画するという内容になります。

また、ShaderIDを用いて、「顔と毛髪以外は法線によるアウトラインを使用する」、「毛髪のみ、マテリアルによるアウトラインを使用する」と、カテゴリ毎に分けて使用することで、アウトラインを描画するようにしました。 下記が、それぞれの情報を用いて輪郭線の抽出を行った結果になります。

パラメータとしては、アウトラインの太さや色を調整できるようにしました。 特にアウトラインの色については、近傍の色を元に明度と彩度の調整をすることで色トレスができるようにしています。 また、これらのパラメータは「肌」、「毛髪」、「その他」で調整ができるように実装しています。

struct ToonOutlineParameter
{
    float brightness;   // 明度
    float saturation;   // 彩度
}

ToonOutlineParameter skin_outline_param;    // 肌のアウトライン
ToonOutlineParameter hair_outline_param;    // 毛髪のアウトライン
ToonOutlineParameter other_outline_param;   // その他のアウトライン
float outline_weight;                       // アウトラインの太さ

6.トゥーン用の顔データの作成について

ここまでの処理で、プログラム上の処理が一通り完了しました。 しかし、既存のモデルではやはり顔の陰影が綺麗になりにくいといった問題が発生しました。

これに対処するには、顔モデルの法線を調整する等、データに対して調整を行う必要があります。 『NGS』では、トゥーン表示用に法線等を調整したモデルを新たに用意し、トゥーン表示に切り替えた際に顔モデルを切り替えることで対処するようにしました。3

元々、『PSO2』から『NGS』にアップデートする際、顔のデータは『PSO2』で体のデータは『NGS』といったように、顔と体で別のデータを切り替えることができるシステムとデータを作っていました。 このため顔の切り替え処理については実装をスムーズに行うことができました。

詳細な情報については、CEDEC2022の資料「『PSO2 ニュージェネシス』 長期運営タイトルにおける、大規模バージョンアップの開発事例の紹介」を参照してください。4

トゥーン用の顔データの作成では主に「法線の調整」、「目の陰影を追加」、「ラフネス値の調整」をデザイナー(アーティスト)の方に行っていただきました。 行った調整について簡単にご紹介させていただきます。

6.1 法線の調整について

顔の法線については、モデルの頂点法線について下記のような調整を行っています。

  • 頬の陰影が綺麗になるように調整
  • 口元や、鼻の陰影がくっきりでるように調整

下図が通常時との比較になります。

6.2 ラフネス値の調整について

一部の顔モデルについては、頬、鼻先、唇にスペキュラが出やすくするためにラフネスの調整をしています。 下記が通常時との比較になります。

6.3 目の影について

イラストの表現では、目に対してまぶたの影をつけることで立体感を表現することがあります。 『NGS』のトゥーン表示でも同様に目に影をつけることでイラスト特有の立体感のある目を表現しています。

7.その他の対応

以上がおおまかな、対応内容になります。 しかし、後付けの処理であるため様々な問題が発生しました。 ここでは、発生した問題や対処した方法について紹介したいと思います。

7.1.カットイン画面のトゥーン表示対応

『NGS』では、キャラクターの顔が小さいウインドウに表示される「カットイン描画」と呼ばれるものがあります。この機能は主に、チャット画面やショップでのプレビュー画面で使用されます。

このカットイン画面は、全てフォワードレンダリングで描画しています。 既存の処理ではGBufferの情報を出力しない設計になっていたので、新しくGBufferの情報を一部追加で出力するように改良する必要がありました。 最終的には下記のように、フォワードレンダリングの結果だけでなく法線、マテリアル情報も出力するように変更しました。

後は、前述した処理と同様に「陰影のマルチトーン化」や「アウトラインの表示」を行っています。 下記がトゥーン表示時における、カットイン描画のパスになります。

7.2.半透明のアウトライン

『PSO2』では半透明を使用しているものが多くあります。例として、プレイヤーが身に着けられるアクセサリーである「フォトンマフラー」は、不透明と半透明の組み合わせで作られています。5

このデータでアウトラインを表示した場合、不透明部分だけ考慮されるため、半透明部分で不自然なアウトラインが描画される問題が発生しました。

この問題に対処するため、新しく半透明部分を表すアルファマスク作成し、半透明部分にアウトラインが描画されない対応を行いました。 下図が対応後の結果になります。

8.調整するパラメータについて

内部で調整できるパラメータの合計は最終的に60個になりました。 実装当初、用意したパラメータは固定値とする予定でした。

しかし、『NGS』では人間、キャスト(ロボット)、或いはその枠を超えた様々なキャラクターを作成することができます。

システムの都合で個別にパラメータを設定することが難しいですがそれでも調整できる方が良いと判断し、上記のパラメータをシンプルな形で調整できるようにしました。

製品では「影の濃度」と「輪郭の強調」の二つのパラメータを調整することで、見た目が変わるようにしています。

9.まとめ

これらの対応を行うことで事前にトゥーンレンダリングを想定していなくとも、ある程度のクォリティでキャラクターのトゥーン化を行うことができました。

リリース前はプレイヤーの皆様に受け入れてもらえるか不安でしたが、「キャラクタークリエイトの幅が広がった」、「過去のコスチュームの見た目がよくなり使用する機会が増えた」といった好意的な意見があり、実装してよかったと感じました。

10.最後に

汎用ゲームエンジンが流行りつつありますが、自社でゲームエンジンを開発することで、どういった処理が最適なのかを基礎から学び、ひいては独自の実装で特徴ある表現を可能にすることができます。特に今回のような「ゲームの表現を途中で変えるような大きな変更対応」は自社のゲームエンジンでしか実現ができないものだと思います。自社でゲームエンジンを「使う」だけでなく、「作る」ことができる環境。 セガで働くことにご興味を持たれましたら下記サイトにアクセスお願いします。

(C) SEGA www.sega.co.jp


  1. 描画負荷としては裏面を後で描画する方が良いですが、わかりやすさのために上記の記載になっています。
  2. キャラクターの肌について、肌ではないけど肌と陰影を合わせたいアクセサリーがあり、パラメータを分けることはしませんでした。
  3. トゥーン用に用意してあるのは、『NGS』で新しく作成した顔モデルのみになります。
  4. https://cedil.cesa.or.jp/cedil_sessions/view/2614
  5. 『PSO2』における、髪型も半透明と不透明の組み合わせで作られています。

CEDEC 2023 セガサミーグループによるセッション紹介!

今年も夏がはじまり、CEDECが近くなってまいりました。

今回はハイブリッド開催となったゲーム業界最大のカンファレンスに、

セガサミーグループからも登壇します!

cedec.cesa.or.jp

会期:2023年8月23日(水)~8月25日(金)

今年で8回目となる、セッションと登壇者紹介に加え、ここでしか見られない当日の資料の抜粋チラ見せ付き(一部公募のみ)でブログ本文は株式会社セガ、第3事業部の麓がご紹介致します。

続きを読む

『PSO2 ニュージェネシス』におけるハイダイナミックレンジ対応について

1 はじめに

株式会社セガ ゲームコンテンツ&サービス事業本部 技術本部 技術統括室 ソフトシステムセクションの西濱 高志といいます。 現在グラフィックスプログラマとして株式会社セガが開発運営する『PSO2 ニュージェネシス(以下『NGS』)』に携わっています。

今回の記事では『NGS』におけるハイダイナミックレンジ(HDR)ディスプレイ対応について紹介いたします。

2 目次

3 注意事項

この記事において、2点注意することがあります。

3.1 各ゲームにおけるHDRディスプレイ対応についての注意事項

現在、様々なゲームにおいてHDRディスプレイ対応がされています。 しかし、対応方法については各ゲームで異なっている場合や、ユーザーが調整できるパラメータに違いがある場合があります。 この記事ではあくまで『NGS』におけるHDR対応の話になりますのでご注意ください。

3.2 掲載している画像についての注意事項

この記事では随所にSDRディスプレイへの出力結果とHDRディスプレイへの出力結果の比較画像を掲載しています。 しかし、HDRで出力した画像はHDR出力に対応をしているディスプレイやデバイスでないと正しく表示することができません。

そこで、SDRとHDRの違いがわかりやすくなるように加工したSDR画像を掲載しています。 実際の数値や実機上での見た目とは異なりますのでご注意ください。

4 ハイダイナミックレンジ(HDR)とは?

それでは、本題に入っていきたいと思います。 HDRとは一言でいってしまうと「従来の標準ダイナミックレンジ(SDR)と比べて、より広い範囲の明るさを表現できる技術、或いはビデオ映像」のことを言います。

SDRとの違いは表現できる「明るさの幅」、「色の幅」の2点になります。 この2つの幅についてHDRの方が圧倒的に広いため、今まで表現できなかった明るさや色を表現できるようになります。

実際に、同じシーンでHDRとSDRを出力した結果を掲載します。 今回、比較に用いたのはゲームの拠点となる「セントラルシティ」と、ゲームプレイ時に発生する「ナーデレフのライブイベント」になります。 違いとしては、主にハイライト部分の箇所と全体的な色合いになります。

セントラルシティにおける比較(左:SDR出力、右:HDR出力)
ライブイベントにおける比較(左:SDR出力、右:HDR出力)

セントラルシティにおいては、太陽の部分についてHDRの方が白飛びしておらず、色合いについても植物の緑色などが色濃くでているのがわかるかと思います。 ライブイベントにおいては、後ろにあるライトについてHDRでは白飛びせずライトの色が識別できるようになっているのがわかるかと思います。

4.1 明るさの違い

ディスプレイにおける明るさはnit(ニット)という単位面積あたりの明るさ(カンデラ毎平方メートル)で表されます。 出力することが可能な明るさの範囲はディスプレイのスペックによって違いますが、SDRとHDRでおおよそ下記の範囲になります。

  • SDR:0.1nit以下~数百nit
  • HDR:0.1nit以下~数千nit

あくまでイメージとなりますが表現できる白色について見た時、下記画像のような違いがあります。

4.2 色の違い

HDRとSDRでは利用されている色空間が違うため、表現できる色の幅についても違いがあります。 具体的にはSDRではRec.709が利用され、HDRではRec.2020が利用されています。

それぞれの色空間についてのグラフは下記になります。

あくまでイメージとなりますが、実際の見た目としては赤色(R)、緑色(G)、青色(B)で下記画像のような違いがあります。

このようにHDRディスプレイ対応を行うことで、明るさの幅と色の幅が広がり、今まで表現することができなかった色や、白飛びしてしまっていたライトの光等を精密に表示することができるようになります。

5 HDRディスプレイ対応について

ここまでの内容でSDRとHDRでどういった所が違うのかについて、説明いたしました。 ここからは『NGS』における対応方法について説明いたします。

5.1 SDR時におけるレンダリングパスについて

レンダリングパスとはグラフィックス処理の順序のことを言います。 『NGS』ではHDR時とSDR時でレンダリングパスは、ほぼ同じ構成になっており、SDR時の出力を基準としてパラメータでHDRへ拡張をするといった対応をしています。 このためSDR時の処理について先に説明します。

下記がSDR時におけるレンダリングパスになります。 注目する点としては、それぞれの処理における「輝度の範囲」、「色空間」、「テクスチャフォーマット」になります。 またオレンジ色はHDRの区間、青色はSDRの区間を表しています。

SDR時のレンダリングパス

今回はHDRディスプレイ対応と関連性がある、「Gbuffer描画からHDRポストプロセスにかけて行うHDRレンダリング処理」、「トーンマッピングとガンマ補正処理」、「カラーグレーディング処理」について簡単に説明いたします。1

5.1.1 HDRレンダリング処理について

HDRレンダリングとは十分な計算精度を保ったまま幅広い諧調を扱うレンダリング方法のことを言います。 SDRで出力する場合でもHDRの範囲で一旦描画を行い、この後の「トーンマッピングとガンマ補正処理」においてSDRに変換することで、幅広い諧調を持った画像を出力できるようになります。 HDRレンダリングの結果が下の画像となります。

HDRレンダリングの結果

5.1.2 トーンマッピングとガンマ補正処理について

トーンマッピングとガンマ補正処理においては、先ほどのHDRレンダリングの結果をSDRディスプレイにおいて適切な見た目となるように変換する処理を行っています。2

5.1.2.1 トーンマッピング

ゲームでは生成したHDRレンダリング画像に対して、トーンカーブを用いることで出力するディスプレイで正確な表現ができるように変換します。 SDRディスプレイに出力する場合、0~1の範囲に変換します。 トーンカーブは様々な種類があるのですが、『NGS』ではACES Filmicを使用しています。

// 使用している係数
// a = 3.0
// b = 0.03
// c = 2.43
// d = 0.59
// e = 0.14
float3 ACESFilmic(float3 x, float a, float b, float c, float d, float e){
    return (x*(a*x+b))/(x*(c*x+d)+e);
}

『NGS』において設定しているACES Filimicの係数を当てはめた結果が下記の画像となります。横軸が変換前の値で、縦軸が変換後の値です。

SDR時のトーンカーブ

輝度値が低いところでは変化が大きくなり輝度値が高いところでは変化が緩やかになり、1.0に収束していることがわかるかと思います。 トーンマッピングを行った結果が下記になります。

トーンマッピング後の画像

5.1.2.2 ガンマ補正について

ガンマ補正の説明をする前に、まず電気光伝達関数(Electro-Optical Transfer Function)と光電伝達関数(Opto-Electronic Transfer Function)について説明します。 (以降、電気光伝達関数はEOTF、光電伝達関数はOETFとします。) EOTFは映像信号をディスプレイの光に変換するための関数、OETFはシーンの光を映像信号に変換するための関数を表しています。

現実の世界でカメラを用いて説明しますと、被写体をカメラで撮影した時、カメラの内部でシーンの光を映像信号に変換するOETF処理が行われます。 次にこのカメラ内の映像信号はカメラに内蔵されているディスプレイ等に送られ、ディスプレイ側で映像信号をディスプレイの光に変換するEOTF処理が行われます。 カメラで撮られた画像はこのようにして、私たちの目に届くといった仕組みになっています。

カメラにおけるEOTFとOETF

ゲーム等のCGでは、カメラにあたる部分がないため生成した画像をそのままディスプレイに渡してしまうと、ディスプレイ側でEOTF処理が行われてしまうため、想定と違う見た目になってしまいます。 このため、あらかじめOETF処理を行うことでディスプレイ側で行われるEOTFの効果を相殺します。

ゲームにおけるEOTFとOETF

SDRディスプレイにおけるEOTFは様々有り、ガンマ1.9、ガンマ2.2、ガンマ2.4等と呼ばれます。 これをOETFで相殺する処理を(特にSDRでは一般に)ガンマ補正と呼びます。 『NGS』ではsRGBのガンマ2.2として扱い、ガンマ補正として画素に対して1/2.2を累乗を行うことでSDRディスプレイにおいて適切な見た目で表示できるようにしています。

ガンマ補正後の画像

5.1.3 カラーグレーディング処理について

次にカラーグレーディング処理について説明いたします。 カラーグレーディング処理とは出来上がった画像に対して色味を変える処理のことを言います。 広義としては色調補正、カラーコレクション等と呼ばれたりします。

ゲームではシチュエーションによっては赤味を強くしたいといった要望や、過去回想などにおいてセピア調にしたいといった要望があると思います。 これらの処理を行うのがカラーグレーディングの役目となります。 具体的にはPhotoshop等を用いて作成したルックアップテーブル(LUT)テクスチャを用いて色の調整を行います。

下記画像がカラーグレーディングの比較画像になります。

カラーグレーディングの比較画像(左:なし、右:あり)

見比べてみるとかなり色味が変わってることがわかるかと思います。 『NGS』では、地域、天候等によってLUTを複数用意しており、ライブイベントの場合4つのLUTを使用して、時間変化で切り替えています。

長くなりましたが、以上がSDR時のレンダリングパスの説明となります。

5.2 HDR時におけるレンダリングパスについて

次に、HDR時におけるレンダリングパスについて説明いたします。 基本的には先ほどのSDR時のレンダリングパスからの追加対応について説明していく形になります。 下記が初期に実装したHDR時のレンダリングパスになります。

初期に実装したHDR時のレンダリングパス

違いとしては、SDR時にトーンマッピングとガンマ補正を掛けていた箇所がHDR用のトーンマッピングになり、出力の手前でOETF処理をしているところになります。 また、オレンジはHDR、赤色は最大輝度で変換したHDR、紫色はOETF処理をしたHDRを表しています。

5.2.1 HDR用のトーンマッピングについて

HDR用のトーンマッピングの説明をする前に、まずHDRで表現できる数値について説明いたします。 SDRでは0~1の範囲に変換をしたと思うのですが、HDRでは1.0以上の値で表示が可能となります。

ディスプレイのスペックによって変わってくるのですが例えば最大輝度(ピーク輝度)が350nitの場合、単純なケースでは3.5までの値が描画可能となります。3 これは、HDRの規格上100nitが標準白レベル(1.0 = 100nit)として取り扱っているためです。 このため、1.0以上の範囲で変換できれば対応することができそうです。

まず、最も簡単な方法としてACES Filimicの係数を変更してみることにします。 ACES Filimicの処理について、「x」が無限大に近づくときの値は「a / c」になります。 このため、「a / c」が最大輝度となるように係数を導出すれば表現できそうですね。 「a = 3.0」とすると、「c = 3.0 / 最大輝度」となるため、これを式に当てはめてみます。

// a = 3.0
// b = 0.03
// c = a / L
// L = 最大輝度
// d = 1.0
// e = 0.14
float3 ACESFilmic(float3 x, float a, float b, float c, float d, float e){
    return (x*(a*x+b))/(x*(c*x+d)+e);
}

係数を調整し、1.5に収束するようにした結果が下記になります。

HDR時のトーンカーブ(青:HDR、緑:SDR)

また、この「最大輝度」はパラメータ「HDR設定:最大輝度レベル」としてユーザーが調整できるようにしています。 このカーブを用いれば、ディスプレイの最大輝度に合わせた画像を出力することができます。

しかし、ここで問題が起きました。

5.2.1.1 HDR用のトーンマッピングの問題点

元々『NGS』ではトーンマッピング後はSDR前提で処理が組まれています。 このため、カラーグレーディングやSDRポストプロセス処理で問題が発生しました。

特にカラーグレーディング処理では0.0~1.0の値を前提として作られているため工夫が必要でした。 対策として、最大輝度で除算を行いカラーグレーディング処理を行った後、元に戻すと対応を試してみましたが色合いが不自然になってしまう問題が発生しました。

下の画像がSDR時の画像とHDR時の画像の比較になります。

左:SDR出力、右:HDR出力

今回の対応では「明るさの幅」を拡張したいのですが全体的に青みが強く出てしまっています。 この問題に対処するため、レンダリングパスについて再度見直す必要がありました。

5.2.1.2 HDR時におけるレンダリングパスの改良

先ほどのレンダリングパスについて、改良を加えたものがこちらになります。

改良したHDR時のレンダリングパス

違いとしては、UI描画の手前までSDRで処理を通し、その後HDR用のトーンマッピングをかけているところです。 この対応を行うことでUI描画の手前までの区間はSDR時と同じ処理になるため、色味に不具合が発生しないようにしました。

また、元々のSDR時のレンダリングパスでは8bit精度で処理を通していたのですが16bit精度にしています。 これはSDRに範囲を狭くして、後から引き延ばす都合上精度を落とさないようにするために行っています。

5.2.1.3 HDR用のトーンマッピングの改良

それでは新しくUI描画の手前に移したHDR用のトーンマッピング処理について説明いたします。

HDR用のトーンマッピングではこちらの3つを満たすものを独自実装しました。

  • SDR用のトーンマッピング後の値を使用すること
  • 輝度の値が低いところについてはSDRと同じにすること
  • 輝度の値が高くなるにつれて既存のHDR用のトーンカーブの変化率に近づくようにすること

これらを満たすトーンマッピングを実装したコードが下記になります。

// ガンマ補正の効果を相殺するため、ガンマ2.2を処理
color.rgb = pow(color.rgb, 2.2f);

// 係数を算出
float3 rate = color.rgb;
rate = pow(rate, 10.0f);

// HDR用のトーンマッピングをかける
// max_nit_level:最大輝度
color.rgb = lerp(color.rgb, color.rgb * max_nit_level, saturate(rate));

// UI素材と色空間を揃えるため、再度ガンマ補正を処理
color.rgb = pow(color.rgb, 1.0f/2.2f);

下記がトーンマッピング適用時のグラフになります。

青:既存のHDR用トーンカーブ、緑:SDR用トーンカーブ、灰:改良したHDR用トーンカーブ

グラフを見ると、輝度の値が低いところはSDRと同じで、輝度が高くなるにつれてHDRに近づいているのがわかるかと思います。

この改良したトーンマッピングを行った結果とSDR時の画像を比較したものが下記になります。

左:SDR出力、右:改良したトーンマッピングによるHDR出力

改良前と比べ全体的な色見は変わらず、ライトの白飛びが改善していることがわかるかと思います。

5.2.2 HDRにおけるOETFについて

次にHDRにおけるOETF処理について説明します。 HDRの場合はOETF処理と合わせて下記の処理を行っています。

  • ガンマ2.2を処理
  • 色空間の変換処理
  • 輝度の補正
  • PQ補正

一番最初にガンマ2.2を処理しているのは、ここまでガンマ補正後の画像で処理されているためです。 SDRディスプレイとHDRディスプレイで使用されているEOTFは違うので、ここでガンマ補正前の画像にします。

5.2.2.1 色空間の変換について

『NGS』ではRec.709で描画処理を行っているため、HDRディスプレイにそのまま値を出力すると下記画像のようにSDR時の画像と比べて鮮やかすぎる見た目になってしまいます。

色変換せずに出力した画像

HDRディスプレイではRec.2020で処理するため、Rec.709の値をそのまま渡してしまうと下記の画像のように座標変換で引き延ばされてしまい、想定と違う色味になってしまうのが原因です。

座標変換による引き延ばし

そこで、Rec.709からRec.2020への変換処理を行うことで元の画像と同じ色合いになるようにします。

// Rec.709からRec.2020への変換
float3 ConvertRec709To2020(float3 value){
   float3x3 matrix709to2020 =
   {
      { 0.627404f, 0.329282f, 0.043314f },
      { 0.069097f, 0.919541f, 0.011362f },
      { 0.016392f, 0.088013f, 0.895595f }
   };
   return mul(matrix709to2020, value);
}

これで、SDRディスプレイの時と同じ色合いの画像をHDRディスプレイで出力できるようになります。

5.2.2.2 色空間の変換における改善

上述のように色空間の変換を行うことで元の画像と同じ色合いにしましたが、これはHDRなのにも関わらずRec.709の範囲の色しか扱えていないとも言えます。 本来であればゲームの素材をすべてHDR用に調整して、表示すればいいのですが運営しているタイトルですべての素材をHDR用に調整し直すのは現実的ではありません。 そこで、色の範囲を疑似的に拡張しました。

先ほどRec.709の値をそのまま渡すと、色空間がRec.2020に引き伸ばされると言いました。 これはRec.2020の色の範囲を扱えているとも言えます。 なので、色空間の変更後と変更前で線形補間を行い調整できるようにしました。

この「線形補間の係数」はパラメータ「HDR設定:彩度調整」としてユーザーが調整できるようにしています。

float3 rec709 = color.rgb
 
// rec709の数値をrec2020に変換
float3 rec2020 = ConvertRec709To2020(rec709);
 
//rateはユーザーが調整できるようにする
color.rgb = lerp(rec2020, rec709, rate);

これで、ユーザーの好みに合わせて色域の拡張を行い鮮やかさを調整できるようにしました。 「HDR設定:彩度調整」の値を50(計算上は0.5)にした結果が下記になります。

係数を0.5にした時の画像

5.2.2.3 輝度の補正

次に輝度の補正について説明します。 HDRでよく問題になるのが、SDRと比べて画像が暗くなるという問題です。

これは、SDRとHDRで標準白レベルの明るさに相違があるため発生します。

一般的なSDRディスプレイでは、1.0を100nitで表示しておらず、おおよそ200~300nitで表示されています。 このため、HDRで1.0を100nitとして表示を行うと暗くなるという問題が起きます。

この問題については輝度の補正をすることで対処します。 具体的には標準白レベルをパラメータで制御することで、明るさを調整できるようにします。 HDRは規格上10000nitまで表現が可能ですので、「標準白レベル ÷ 10000」乗算することで補正します。

この「標準白レベル」はパラメータ「HDR設定:標準白レベル」としてユーザーが調整できるようにしています。

// 指定した輝度に補正する
float3 NormalizeBaseNit(float3 value, float base_nit){
    base_nit = max(base_nit, 1.0f);
    return value * base_nit / 10000.0f;
}

5.2.2.4 PQ補正

次にPQ補正について説明します。

HDRディスプレイのEOTFではPQ方式が使用されます。 これは、人間の視覚特性に基づいて新しく開発されたガンマカーブになります。 OETFではこの逆関数であるPQ補正を行います。

// PQ補正
float3 LinearToPQ(float3 value){
    float m1 = 2610.0f / 16384.f;
    float m2 = 2523.0f / 4096.0f * 128.0f;
    float c1 = 3424.0f / 4096.0f;
    float c2 = 2413.0f / 4096.0f * 32.0f;
    float c3 = 2392.0f / 4096.0f * 32.0f;
    
    float3 cp = pow(value, m1);
    float3 n = (c1 + c2 * cp);
    float3 d = (1 + c3 * cp);
    return pow(n / d, m2);
}

以上の処理を行い、描画した結果をSDRディスプレイに表示した結果がこちらになります。

OETF後の画像

SDRとHDRで使用しているEOTFが違うため、白っぽい見た目になりますがこちらの画像をHDRディスプレイで表示することで下の画像のように適切な見た目となります。

ディスプレイに表示される画像

以上がHDR時におけるレンダリングパスの説明になります。

6 調整するパラメータについて

『NGS』で調整できるパラメータは下記3つになります。

  • HDR設定:標準白レベル(輝度の補正で使用)
  • HDR設定:最大輝度レベル(HDR用のトーンマッピングで使用)
  • HDR設定:彩度調整(色域の拡張で使用)

これらのパラメータを用意した理由はディスプレイによって、明るさや色味が違うためです。 『NGS』では調整しやすいように下記のような調整用の画像を用意しました。

調整用の画像

標準白レベルでは250nitが基準となるようにし、最大輝度レベルではそのディスプレイが表現できる明るさに調整できるようになっています。 しかし、ディスプレイの設定やスペックによっては眩しすぎたり、暗くなったりすることがあるため好みに合わせて調整してただくのが適切かと思います。

7 まとめ

長くなってしまいましたが、『NGS』におけるHDR対応についてまとめに入ります。 HDR対応では下の3つのことを行い、SDRの見た目を維持しつつ明るさと色の拡張を行うことができるようにしました。

  • HDR用のトーンマッピング処理
  • 色の範囲の拡張
  • HDRにおけるOETF処理

最初に記述したようにこれは『NGS』におけるHDRの対応方法になります。 ゲームによっては「SDRとは違った絵を出したい」といった要望や「HDR用に素材を調整したい」等の要望によって、対応方法に違いが出てくるかと思います。 この記事にかかれていることについては、あくまで参考として活用いただけると幸いです。

8 最後に

汎用ゲームエンジンが流行りつつありますが、自社でゲームエンジンを開発することで、どういった処理が最適なのかを基礎から学び、ひいては独自の実装で特徴ある表現を可能にすることができます。 自社でゲームエンジンを「使う」だけでなく、「作る」ことができる環境。 セガで働くことにご興味を持たれましたら下記サイトにアクセスお願いします。

(C) SEGA

www.sega.co.jp


  1. Gbuffer描画からHDRポストプロセスの区間については処理を省略して掲載していますのでご注意ください。
  2. 実際の処理としては、トーンマッピング前に露出制御を行っていますが詳細説明は省略いたします。
  3. 表現できる最大値はディスプレイの表示モードによって変わることがあります。
Powered by はてなブログ