- Minecraft Java Edition がグラフィックスレンダリングエンジンを OpenGLからVulkanへ移行
- 1990年代から使われてきた OpenGLの更新停止とmacOSサポート終了 が移行の背景
- Vulkanは Windows・Linuxで標準対応、macOSは変換レイヤーで対応し、性能低下はなし
- この移行により 視覚品質の向上とフレームレート改善 が期待される
- スナップショットでOpenGLとVulkanを並行テストし、安定性を確保でき次第OpenGLを削除する予定
Bringing modern rendering to Java
- Minecraft: Java Editionでは Vibrant Visualsの準備作業 が継続しており、レンダリングコードのリファクタリングと近代化が進められている
- これまでのアップデートでレンダリングコード構造の改善を実施
- レンダリングの基盤技術そのものを置き換える段階に入った
- ゲームのレンダリング技術を OpenGLからVulkanへ移行 する予定
- グラフィックスおよび性能面で新たな可能性を確保するのが目的
- Modコミュニティや一部プレイヤーに影響が出る見込み
What are we changing?
- 現在のJava Editionは1990年代に作られた OpenGLグラフィックスAPI を使用している
- OpenGLを採用した理由は Linux・Windows・macOSの全OSをサポート できたため
- ほぼすべてのPCとMacで動作するよう設計されていた
- OpenGLは9年前に更新が止まり、macOSでは 非推奨（Deprecated） 状態で、将来的には実行できなくなる予定
- macOS互換性のため古いOpenGLにとどまる必要があり、その結果コードベースの近代化が難しくなっていた
- macOSやLinuxを含む大半のPCでJava Editionを今後も動作させ続けるため、OpenGLからの移行が必要
Introducing: Vulkan
- Vulkanは 10年以上にわたり市場で使われてきたグラフィックスAPI であり、主要なハードウェアベンダー全体で採用されている
- Windowsおよび最新のLinuxでは標準対応し、macOSでも 変換レイヤーの適用でサポート 可能で、性能低下なしに動作する
- 長期的には性能向上と機能拡張の可能性を確保できる
- Vibrant Visualsの実装に必要な基盤を提供
- GPUが10年以上前のものだとVulkanに対応していない可能性がある
What does this mean for modders?
- OpenGLからVulkanへ移行することで OpenGLベースのレンダリングModに影響が出る
- Vulkanへの移行作業は通常のリリース対応よりも多くの労力を要すると見込まれる
- ModコミュニティにはOpenGL依存を減らすことを推奨
- 内部レンダリングAPIを可能な限り再利用することを推奨
- 必要であれば開発チームと直接技術的な議論も可能
- Vibrant VisualsのDiscordチャンネルで技術的な議論を実施
- 告知用チャンネルではなく、開発者同士の深い技術議論の場
What does this mean for players?
- 一部のModは移行過程で影響を受ける可能性がある
- 今後のスナップショットでは OpenGLとVulkanを並行提供する予定
- スナップショットおよび正式版でレンダラーを選択可能
- 安定性確保とバグ最小化の作業も並行して進める
- バグは bugs.mojang.com から報告してほしい
When is this happening?
- 夏の間にVulkanをスナップショットテストへ導入することを目標としている
- テスト期間中はOpenGLとVulkanを切り替え可能
- 安定性・性能の検証が完了した時点でOpenGL実装を削除する予定
Vulkan and Vibrant Visuals
- レンダラーの近代化は Vibrant Visualsロードマップの中核的ステップ
- Vulkanへの移行によってグラフィックス改善の余地が広がり、性能面の強化も可能になる
- ドライバ起因のバグ減少も期待される
- macOSで継続して動作可能にすることが中核目的
- すべての対応OSのプレイヤーが同じように参加できることを保証するため
アップデートの意味
- 今回の移行は、Minecraft Javaが 現代的なグラフィックス技術スタックへ移る 重要なステップ
- ゲームエンジンの技術基盤を強化 し、今後の拡張性や機能追加に有利な構造を整える
- OpenGLからVulkanへの移行は ゲーム業界全体におけるグラフィックスAPI世代交代の流れ とも重なる
3件のコメント
Hacker Newsの意見
時間が経てばメインスレッドのCPUオーバーヘッドが減ることを期待したい
DX11から12へ、OpenGLからVulkanへ移植されたゲームが単にAPIの置き換えだけで性能向上を得たのではなく、並列ドローコール処理能力を活用したからでもある
MinecraftはGPUがレンダリングできる速度よりCPUの方が遅くてボトルネックになっているので、この変化でMod環境でもCPUに余裕が生まれることを期待している
試しにWindows版をProtonで動かしてみたら性能が30%向上した
おそらくProtonが使っているdxvkライブラリのマルチスレッド化のおかげだと思う
Minecraft Java Editionはデスクトップ専用なので、モバイルのVulkanドライバ問題を避けられる点ではよい選択だと思う
ただ、Microsoftほどの規模なら、プラットフォームごとに安定したAPI（DX12、Metal）を使うクロスプラットフォームRHIを作る余力があると思っていた
Javaレンダラーを3種類維持管理するのは負担が大きく、とくにModエコシステムが中核なので、今回の変化だけでも混乱は大きいはず
Shader Modの保守をさらに難しくする必要はないと思う
macOSでもVulkanを動かせるので、わざわざDX12を新規プロジェクトで使う理由はよく分からない
私の古いAcer C720 Chromebook（Intel HD4400 iGPU）ではVulkanがサポートされていないので、Minecraftが壊れそう
昔はどんなハードウェアでも動くのが長所だっただけに残念
なぜコメントをソース側に移さないのか気になる（関連スレッド）
MicrosoftがAppleよりKhronos標準に近づいているのが興味深い
SPIR-VをDirectXシェーダーコンパイラの出力および入力フォーマットとして採用し、Vulkanとの相互運用性を高めた
AppleはOpenCLの扱い方に不満が多く、SonyとNintendoはKhronosにほとんど関心がない
実際、Khronos APIは拡張スパゲッティ問題のせいで完全な移植性に欠ける
VulkanModは性能向上が大きいが、ほとんどのModと互換性がない
今後、フルModpackでもVulkanを使えるようになれば本当に楽しみ
Vibrant VisualsがJava Editionにも早く来てほしい
シェーダーを使うのにいつもModが必要なのは残念
複雑なローダーやセキュリティリスクなしに、.zipファイルをドラッグ＆ドロップしてインストールできる
Aperture、Iris、Optifineほど柔軟ではないが、機能はかなり似ている
Vulkanシェーダーもリソースパックに含められるのか気になる。ただし、ゲーム機能を壊すリスクが大きいため制限されるかもしれない
JavaにVulkanバインディングがあるとは知らなかった。たぶんJNIを使っているのだろう
まだOpenGLを使っていたのは意外だ。Minecraftの現状はよく知らないが、デスクトップ向けの非Java版があることも初めて知った
メモリ管理がはるかにすっきりし、外部関数（Vulkanなど）とのバインディングもずっと簡単になる
最近のJavaでもっとも過小評価されている機能の一つだと思う
なぜ同じゲームを2つのバージョンで維持しているのか気になる
Bedrockは機能面ではほぼ追いついたが、完全な代替には失敗したわけだ
Bedrockは性能と移植性は良いが、コンソールではどうせModdingができない
YouTubeコンテンツの90%がJavaベースなので、Microsoftは機能の同等性確保に注力している
Microsoftにとっては2つのバージョンを維持して売上を最大化するのが合理的だ
Vulkanシェーダーコンパイルの遅延問題をうまく解決していることを願う
複雑なマテリアルシステムではなく、単純なvoxelレンダラーだからだ
問題は、エンジンがあまりに多くのシェーダー組み合わせを生成したり、特定のGPU状態（例: ブレンディング）がシェーダーの再コンパイルを引き起こすときに発生する
最新のVulkanでは大半の状態を動的状態(dynamic state) として扱えるため、この問題を緩和できる
ただし、ブレンディングのような一部の状態は依然として再コンパイルを引き起こすことがある
つまり、開発者がそのような動的状態を避ければ、遅延は簡単に防げる
最近は大手ゲーム会社が技術的最適化をおろそかにすることが多い
マインクラフトはもともとJavaで開発されたゲームですが、MSに買収された後にC++でもう一度作られたんですね。ゲーム1本をまるごと開発言語を変えて再実装するのは簡単なことではなかったはずなのに、どうしてそうなったのか不思議ですね。
モバイル向け最適化を目的にベドロックエディションを作ったのだと思いますが..
Javaを切り捨てるのではないかと思っていましたが、結局どちらもアップデートしていくことになったようですね。