Godot 4.7、HDR対応でもC++17本体は据え置き — なぜ言語標準を変えなかったのか

GodotでHDR前提のルックを作る制作者にとって、競合エンジンとの差は表示品質だけで制作判断にも直結する課題だ。UnityやUnreal EngineではHDR（High Dynamic Range）出力が一般化し、SDR（Standard Dynamic Range）前提の確認だけでは、太陽光やネオン、爆発表現の最終像を読み違えやすい。Godot 4.7 Beta 1は5つのプラットフォーム（Windows、macOS、iOS、visionOS、Linux）へのHDR出力に対応した。ただしWindows経路だけは特殊で、C++20必須のC++/WinRTを使う構成になっている。Godot本体のC++17方針を守りながらWindows固有コードを隔離した設計が、このHDR対応を単純な機能追加より技術的に複雑なものにしている。

C++20必須のWindows経路をC++17本体から切り離す

WindowsでHDR出力を扱う経路には、Windows Runtime向けのC++投影であるC++/WinRTが関わる。今回の実装で必要になったC++/WinRTインターフェースはC++20を前提にする一方、Godot本体はC++17でビルドされている。ゲームエンジンの言語標準を上げると、レンダリング、入力、ファイルI/O、エディタ、拡張モジュール、ビルド環境まで影響が広がる。HDRのために全体をC++20へ移す判断は、機能追加よりも移行コストの方が重くなりやすい。

bruvzg氏はWindows固有のHDR処理をC++20で実装し、メインコードベースへ影響しない形に分離した。C++17で書かれたGodot本体は従来の前提を保ち、Windows側のHDR出力に必要な部分だけが別の言語標準を使う。プラットフォーム依存コードを狭い範囲に閉じ込めたことで、LinuxやApple系OSのビルド条件まで巻き込まずに済む。

Godotはオープンソースエンジンであり、個人開発者、スタジオ、移植担当者が同じリポジトリを扱う。全体のコンパイラ要件が変われば、古い開発環境や自動ビルド環境での失敗が増える。HDR対応をプラットフォーム固有層へ押し込んだ判断は、機能を増やしながら参加者の負担を抑えるための設計でもある。

Godot 4.7は2026年4月中旬時点でBeta 1段階にある。HDR実装を中心的に開発したのはAllen Pestaluky氏、Josh Jones氏、ArchercatNEO氏だ。Godot公式のHugo Locurcio氏はこの実装を「すべてのサポート対象プラットフォームで可能な限り高品質に見える、クラス最高水準のHDR実装」と評しているが、制作現場では品質評価とベータ版固有の制約を切り分けて読む必要がある。

5系統OSと2レンダラー、HDR有効化の条件

Godot 4.7 Beta 1でHDR出力の対象になるOS（Operating System）は、Windows、macOS、iOS、visionOS、Linuxの5系統だ。LinuxではWayland環境が条件で、X11は対象に含まれない。レンダラー側ではForward+とMobileが対応し、Compatibility rendererはグラフィックスAPI（Application Programming Interface）の制約で外れる。

プロジェクト側での有効化は以下の条件が揃って初めて機能する。

Project SettingsからDisplay > Window > HDR > Request HDR Outputをオンにしても、上記の条件が揃わなければHDR表示にはならない。実際の出力はOS、GPU（Graphics Processing Unit）ドライバ、ディスプレイ、レンダラーの組み合わせに依存する。制作チーム内で同じプロジェクトを開いても、環境差によってHDR表示の有無が分かれる点は事前に把握しておきたい。

LinuxでX11が外れる理由は、HDRが単に明るい値を描画するだけでは済まないためだ。HDR出力では色空間、輝度範囲、ディスプレイへのメタデータ、コンポジタとの受け渡しが絡む。Waylandではこうした表示パイプラインを現代的なプロトコルとして扱う流れが進み、Vulkanと組み合わせた経路を作りやすい。X11は長年の互換性を抱えた表示基盤であり、HDR向けの色管理を統一的に通すには設計上の制約が大きい。

Compatibility rendererが外れる点も、古い環境を重視するプロジェクトでは見落としやすい。GodotのCompatibility rendererは対応範囲を広げるための選択肢だが、HDR出力に必要なグラフィックスAPI機能を前提にできない。Forward+またはMobileへ移ると、画面の見え方、負荷、対応端末の範囲が変わる。HDRの採用は単なる画質設定ではなく、対象ハードウェアの線引きにも関わる判断だ。

AgXとグローが白飛び時の色ずれを抑える仕組み

Godot 4.7のHDR出力は、AgXトーンマッパーとの組み合わせが重要になる。AgXはTroy Sobotka氏の研究に基づくトーンマッピング手法で、ACES（Academy Color Encoding System）より彩度を抑えた自然な色再現を狙う。強い露出で明るい領域が黄色やマゼンタへ寄る現象を抑える点が、Godot側でも重視されている。

トーンマッピングは、レンダラー内部の広い明暗情報を、ディスプレイが表示できる範囲へ変換する処理だ。ゲーム内のライトや発光マテリアルは計算上はSDR画面より広い輝度を持てるが、最終段でその値をそのまま押し込むと白飛びや色相のずれが起きる。トーンマッパーは高輝度部分を圧縮し、暗部と中間調とのつながりを保ちながら、画面全体の色の印象を決める。

太陽光が差し込む屋外シーンでは、雲の縁や金属反射の階調が差として出やすい。ネオン看板のある夜景では、発光部分の色が白に潰れるか、赤や青の印象を残したまま明るく見えるかが変わる。AgXはこうした輝度差の大きい場面で、色の派手さを過剰に押し出さず、HDR表示の階調を活かす役割を担う。

Godot 4.6ではAgXトーンマッパーが大幅に再設計され、4.7でHDR出力との完全互換へ到達した。グロー機能もHDR品質に合わせて調整され、トーンマッピング前のScreen blend modeで処理される。発光表現を最終出力後に重ねると明るさと色の関係が崩れやすいが、トーンマッピング前にグローを扱えば高輝度情報を保ったまま最終変換へ渡せる。

Unityとの差はAndroidとLinuxの表示経路に出る

UnityやUnreal EngineはHDR出力を先行して整備しており、商用ゲーム制作ではHDR対応が珍しい機能ではなくなっている。Godot 4.7 Beta 1の追加により、オープンソースエンジンでも同じ表示領域を前提にした制作へ近づく。差が残るのは、機能名としてのHDR対応より、どのOSとレンダラーで安定して使えるかという実装経路だ。

AndroidでUnityとの差が最もはっきり出る。UnityはAndroidのHDR出力をサポート済みで、対応端末をターゲットにした検証へ進められる。GodotのAndroid向けHDRサポートは4.7後のアップデートで実装予定で、現時点のBeta 1では対象に入らない。

Android展開を前提にするプロジェクトは、HDRルックの本格調整をPCやApple系OSで先行し、モバイル実機確認を後段へ回す戦略が必要になる。

Linuxについては、WaylandとVulkanを前提にした対応が最新の表示スタックへ寄せた選択であり、X11環境のユーザーを対象外にする。Linuxゲームの配布では、デスクトップ環境やコンポジタの差が画面出力に影響する。GodotでLinux向けHDRを掲げる場合、配布ページや動作要件にWaylandとVulkanを明記しなければ、ユーザー側の期待と実際の表示がずれる。

WindowsではC++/WinRT、Apple系OSではMetalまたはVulkan、LinuxではWaylandとVulkanというように、HDR出力はプラットフォームごとに別々の道を通る。Godot 4.7 Beta 1の価値は、それらを1つの設定から要求できる形にまとめた点にある。

Beta 1で試す前に確認すべき制作手順

Godot 4.7 Beta 1でHDRを試す場合、最初にレンダラーをForward+またはMobileへ設定する。次にWindowsならDirect3D 12、macOS・iOS・visionOSならMetalまたはVulkan、LinuxならWayland環境のVulkanを確認する。Project SettingsのDisplay > Window > HDR > Request HDR Outputをオンにし、HDR対応ディスプレイで表示を検証する。OS側のHDR設定やディスプレイの入力モードが合わなければ、設定をオンにしても見た目はSDRのままだ。

制作時のチェックシーンは、輝度差が大きい場面を固定して用意するのが有効だ。明るい空、金属反射、ネオン看板、爆発、暗所の点光源、発光UIを同じプロジェクト内に置けば、AgXとグローの挙動を追いやすい。HDR表示で調整した露出は、SDR表示で白飛びや暗部の沈み込みを起こす場合がある。HDR版とSDR版を並行して確認し、配信先ごとの見え方を早い段階で切り分けるべきだ。

Godot制作者にとって今回のHDR対応で変わる点は、最終表示を競合エンジンに近い条件で検証できることだ。太陽光、ネオン、爆発、発光UIの調整を、SDRへ圧縮された画面だけで判断せずに済む。C++17本体を維持したままWindowsのC++20経路を分離した設計は、既存プロジェクトやビルド環境への負担を抑える。GodotでHDR前提のビジュアル設計を始める土台はBeta 1で見えた。

Beta 1既知の制約: NVIDIA環境のWindowsでは3D ViewportTextures使用時にクラッシュが発生している。Android向けHDRサポートはGodot 4.7後のアップデートで実装予定のため、モバイル展開を前提するプロジェクトはPC・Apple系OS環境での調整を先行させること。ベータ版での試用は、対象OSをWindows、Apple系OS、Wayland版Linuxのいずれかに絞って検証するのが現実的だ。