VRChatはMacの夢を見るか？

最新記事

MacでVRChatを遊ぶ。

一見すると、それほど無茶な願望には聞こえない。

Apple Siliconには高性能なCPUとGPUを備えたモデルがあり、CPUとGPUがユニファイドメモリを共有する設計も採用されている。

さらにmacOSには、Wine系のWindows互換環境、Direct3DをMetalへ変換する技術、そしてPCVRの映像をQuestなどへ送るためのコミュニティ製技術が存在する。

それでも、現在のVRChatにmacOS版クライアントは存在しない。

ここで重要なのは、「Macの性能が足りないからVRChatが存在しない」と単純化しないことだ。

むしろ問題は、Windows向けに作られたVRChatを、macOS、Apple Silicon、Metal、そして別のVRランタイムという異なる環境へ適応させる必要があることにある。

そして、その中の重要な課題の一つがEAC、Easy Anti-Cheatである。

「MacではVRChatが動かない」は、性能だけの問題ではない

現在のVRChatにはmacOS版クライアントが存在しない。

一方、LinuxではWindows版VRChatをProton経由で実行する方法が存在する。

つまり、

「VRChatはWindowsでなければ絶対に動かない」

という話ではない。

より正確には、

「Windows向けに構築されたVRChatの実行環境を、macOS上でどこまで再現・変換できるか」

という問題になる。

Linuxでは、その役割をProtonが担う。

ではmacOSではどうなるのか。

macOS側の「Protonに似た役割」を考える

ここでMetalSharpのようなプロジェクトが興味深くなる。

MetalSharpはApple Silicon Mac上でWineを利用してWindowsアプリケーションを動かし、Direct3DをMetalへ接続するための互換環境を構築している。

現在の構成には、D3D11からDXMTを利用してMetalへ接続する経路や、D3D12からVKD3D-Proton、Vulkan、VKMT/MoltenVKを経由してMetalへ接続する経路が含まれている。

したがって、構造を非常に単純化すると、

という経路を作れる。

ただし、MetalSharpを「macOS版Proton」と呼ぶのは正確ではない。

ProtonはValveがWineを基礎として、WindowsゲームをLinux上で動かすことを目的に構築したソフトウェア環境である。

MetalSharpはそれとは別のプロジェクトだ。

しかし、

「LinuxではProtonが担っているようなWindowsゲーム互換環境を、macOSとMetalを前提として構築する」

という観点から比較することには意味がある。

ここで重要なのは、Direct3DをMetalへ変換できることだ。

これによって、WindowsゲームをmacOS用にソースコードから移植するのではなく、Windows版を互換層経由でApple Silicon上に実行する可能性が生まれる。

ただし、これは「VRChatが動く」という意味ではない。

あくまで、VRChatを動かすために必要となり得るグラフィックス側の基盤の一つである。

VRには、もう一つ別の問題がある

3DゲームをMacで描画できても、それだけではPCVRにはならない。

VRでは、HMDの姿勢、位置トラッキング、コントローラー、ハプティクス、VRランタイム、音声、フレーム転送など、通常のゲームとは異なる多数の要素を処理する必要がある。

ここでMoltenVRが登場する。

MoltenVRはApple Silicon Mac上でWindows向けPCVRゲームをWine経由で実行し、OpenXRを中心としたVR環境を構築するコミュニティプロジェクトである。

プロジェクトの検証結果には、Half-Life: Alyxなどが含まれている。

Half-Life: Alyxについては、DXVKによる描画、OpenCompositeによるSteamVR APIからOpenXRへの変換、MoltenVRのOpenXRランタイム、トラッキング、コントローラー、ハプティクスなどを組み合わせた構成が報告されている。

これは重要な実例だ。

少なくとも、

「Apple Silicon Mac上でWindows PCVRゲームを動かし、VRランタイムを介してHMDへ接続する」

という構成そのものは、単なる理論ではない。

ただし、ここから、

「ではVRChatも動く」

とは言えない。

検証済みのゲームとVRChatは別のソフトウェアだからだ。

ALVRについては注意が必要

ここで一つ、特に混同しやすい部分がある。

ALVRはQuestなどをPCVR用HMDとして利用するための代表的なオープンソースプロジェクトだが、公式ALVRのPC側対応OSとしてmacOSが正式サポートされているわけではない。

一方、MoltenVRではMac側のVR環境とQuest側のALVRクライアントを組み合わせる構成が利用されている。

したがって、

「ALVRはmacOSを正式サポートしている」

と説明するのは不正確だ。

より正確には、

「MoltenVRのようなMac向けVRプロジェクトでは、Quest側のALVRクライアントを利用してVR映像を伝送する構成が検討・実装されている」

となる。

この違いは小さく見えて、技術記事ではかなり重要だ。

Half-Life: Alyxが動くならVRChatも動くのか？

ここで人間は当然こう考える。

「Half-Life: Alyxが動くなら、VRChatもいけるのでは？」

残念ながら、そう簡単にはいかない。

Half-Life: Alyxの動作実績は、

「そのゲームが、その互換環境で動いた」

ことを示す。

VRChatについて、

「同じ構成で動く」

ことを証明するものではない。

VRChatには独自の認証、ネットワーク、ユーザー生成コンテンツ、アバター、ワールド、シェーダー、VR入力など、多数の要素が存在する。

そしてEACもある。

EACという大きな壁

VRChatはEasy Anti-Cheatを使用している。

Linux＋Protonについては、VRChatがValveおよびProtonチームと協力してEACを動作させるためのテストを行ったことが公式に説明されている。

しかし、そこから、

とはならない。

LinuxとmacOSではOSのカーネル、システムAPI、ドライバモデル、実行環境などが異なる。

さらにWine系互換環境では、Windowsアプリケーションが期待する環境を別のOS上で再構築する必要がある。

したがって、Mac版VRChatを実現する場合、EACとの互換性は大きな技術的課題の一つになる。

ただし、

「EACがMac版VRChat最大の問題である」

と断定することもできない。

VRChat側がmacOS版を実際に開発していない以上、どの部分が最も大きな開発コストになるのかは外部から確定できないからだ。

EACを解決しても、まだ終わらない

仮にEACの問題が解決したとしても、それでMac版VRChatが完成するわけではない。

VR入力、VRランタイム、音声、Steam関連機能、グラフィックスAPI、アバター、シェーダー、PhysBone、ワールド、ユーザー生成コンテンツなど、さまざまなWindows依存部分について互換性を確保する必要がある。

特にVRChatの場合、ユーザー生成コンテンツが非常に重要だ。

一般的なゲームなら、開発者が想定したステージとアセットが動けばよい。

VRChatでは、ユーザーがアップロードしたアバターやワールドがサービスそのものの大部分を構成している。

そのため、

「VRChat.exeが起動した」

だけでは、

「VRChat for Macが完成した」

とは言えない。

必要なのは、巨大なユーザー生成コンテンツのエコシステムまで含めて、十分な互換性を確保することだ。

それでも、アルファ版なら話は変わる

ここからは事実ではなく、将来的な設計についての考察になる。

もしVRChat開発チームがMac版を作るとすれば、最初からWindows版と完全に同じ機能を実装する必要はない。

例えば初期アルファ版なら、デスクトップモード、ログイン、基本的なワールド描画、アバター表示、基本的なソーシャル機能から始めることが考えられる。

その後、

OpenXRによるVR対応
↓
HMDの6DoF
↓
コントローラー
↓
ハプティクス
↓
Questへのストリーミング

という形で機能を拡張していく。

このアプローチなら、最初から「完全なWindows版VRChat互換」を達成する必要はない。

そして、必要となる技術の一部はすでに存在している。

WineはWindows API互換層として利用できる。

MetalSharpのようなプロジェクトはWindowsゲームとMetalを接続するための技術を提供している。

MoltenVRはApple Silicon Mac上でWindows PCVRゲームを実行するためのVRランタイム環境を研究している。

OpenXRはアプリケーションとVRランタイムの間を接続する標準APIとして利用できる。

ただし、これらを組み合わせても、それだけでVRChat for Macになるわけではない。

「部品が存在する」と「製品が完成する」の間には、いつものように巨大な谷がある。

SteamVR for Macを復活させる必要はあるのか

もう一つ考えられるのが、SteamVRそのものをmacOSへ移植する方法だ。

しかし、これは必須ではない。

VRChatが必要とするVR APIをMac側で提供できれば、SteamVRそのものをmacOSへ完全移植する必要はない可能性がある。

例えばWindows側のOpenVR呼び出しをOpenCompositeによってOpenXRへ変換し、そのOpenXR呼び出しをMac側のVRランタイムで処理する。

MoltenVRは、まさにこの方向の技術構成を実証している。

つまり、

「SteamVR for Macを復活させる」

というより、

「Windows VRアプリケーションが必要とするVR APIをMac上で実装する」

という発想である。

これは技術的にはかなり合理的だ。

Apple Siliconが面白い理由

この構想が以前より現実味を持つ理由の一つがApple Siliconである。

Apple Siliconはx86-64 Windows PCではない。

そのためWindows用x86-64アプリケーションを、そのままCPU上で実行することはできない。

しかし、CPU命令変換とWindows API互換層を組み合わせれば、WindowsアプリケーションをApple Silicon上で実行できる。

GPU側では、

Direct3D
↓
DXMT / D3DMetal / VKD3D-Protonなど
↓
VulkanまたはMetal
↓
Apple GPU

という変換経路を構築できる。

ここで重要なのは、Windows PCそのものをMacの中に仮想的に再現することではない。

Windowsアプリケーションが要求する処理を、Apple Siliconが処理できる形へ変換することである。

そのため、仮想マシンとは異なるアプローチになる。

もちろん、これは「ネイティブと同じ性能になる」という意味ではない。

CPU命令変換、Windows API変換、Direct3D変換、シェーダー変換、VRフレーム処理、映像エンコードなど、それぞれにオーバーヘッドが発生する。

したがって最終的な性能は、実際のアプリケーションと互換層の実装によって大きく変わる。

Apple Siliconなら全部同じ、ではない

もう一つ考える必要があるのがハードウェアだ。

Apple Siliconという名前は共通していても、世代やモデルによってCPU・GPU性能、GPUコア数、メモリ容量、メモリ帯域幅、冷却能力などが異なる。

MacBook AirとMacBook Pro、Mac mini、Mac Studioでも、長時間の高負荷時に維持できる性能は異なる。

VRは継続的に高いフレームレートを維持する必要があるため、この違いは重要になる。

さらにVRChatでは、ユーザーがアップロードしたアバターやワールドによって負荷が大きく変化する。

したがって仮にMac版VRChatを設計するなら、

「Apple Siliconなら全部同じ」

ではなく、

「モデルやメモリ容量に応じて推奨設定を変える」

という設計が現実的だろう。

例えばメモリ容量が少ないモデルでは、表示するアバター数やテクスチャ品質などを抑え、上位モデルではより高い設定を許可する、といった方法が考えられる。

これは現時点のVRChat for Macに存在する仕様ではない。

あくまで、Mac版を設計するなら考えられるアプローチである。

では、Mac版VRChatは技術的に可能なのか？

ここで重要なのは、「可能」という言葉を三つに分けることだ。

第一に、個々の技術要素はすでに存在する。

LinuxではProtonによってWindows版VRChatを動かす道が存在し、EACについても公式にProton環境でのテストが行われている。

Apple Silicon Macでは、MetalSharpのようなWindowsゲーム互換環境が存在する。

さらにMoltenVRでは、Apple Silicon Mac上で複数のWindows PCVRゲームを動かす実証が行われている。

第二に、これらを組み合わせた「Mac版VRChat」が実証されているわけではない。

少なくとも今回確認した公開資料からは、

「MetalSharp＋MoltenVR＋VRChat」

という構成でVRChatが動作したという公式な実証は確認できない。

第三に、したがって「技術的に絶対不可能」とも言えない。

むしろ現在存在する技術を見る限り、研究・開発対象としては十分に成立する。

ただし、それを製品レベルまで完成させるには、EAC、Windows API互換性、グラフィックス、VR入力、音声、認証、ユーザー生成コンテンツ、性能、安定性など、多数の問題を解決する必要がある。

VRChatはMacの夢を見るか？

現時点では、VRChatがMacを公式にサポートする予定があるとは言えない。

しかし、Mac側の技術環境は以前とは違う。

Wineがある。

MetalSharpがある。

DXMTがある。

VKD3D-Protonがある。

MoltenVRがある。

OpenXRがある。

OpenCompositeがある。

そしてQuest側には、PCVRストリーミングという別の道もある。

重要なのは、これらが「VRChatをMacで動かした実績」を意味するわけではないことだ。

それぞれが、Mac版VRChatを仮に実現するとした場合に必要となり得る技術の一部を示している。

その意味で、問題はもはや単純な、

「Macの性能でVRChatは動くのか？」

だけではない。

むしろ、

「Windows向けに構築されたVRChatという巨大なプラットフォームを、Apple SiliconとmacOSを前提とした別の実行環境へ、どこまで移植・変換できるのか？」

という問題になる。

そして、その問いに対する技術的な材料は、すでに少しずつ揃い始めている。

MetalSharpはWindowsゲームとMetalをつなぐ。

MoltenVRはApple Silicon上のPCVRという難題に取り組む。

OpenXRはVRアプリケーションとランタイムを分離する。

OpenCompositeはOpenVRとOpenXRの間をつなぐ。

そしてLinux＋Proton＋VRChatは、「Windows版VRChatをWindows以外のOSで動かす」という前例をすでに作っている。

しかし、最後のピースはまだない。

「VRChat for macOS」という実際の製品である。

だから現在の結論は、

Mac版VRChatは「実現済み」ではない。
しかし「原理的に不可能」と断定できる段階でもない。

現在存在する互換技術を組み合わせれば、研究対象としては十分に現実的な構想になっている。

というところだろう。

もし将来、本当にMac版VRChatが登場するとしたら、それは必ずしも「SteamVR for Macを復活させ、Windows版VRChatをそのまま移植する」という形になるとは限らない。

むしろ、

というグラフィックス経路と、

というVR経路を組み合わせた、Apple Silicon時代ならではの実装になる可能性がある。

そこまで行けば、それは単なる「MacにWindowsゲームを移植したもの」ではない。

Windows向けに作られたVRChatを、Apple Siliconの上で別の実行環境へ翻訳して成立させる、もう一つのVRChatプラットフォームになる。

Macは、まだVRChatを走らせてはいない。

しかし少なくとも現在は、そのための技術的な道筋を考えられる程度には、道路が舗装されてきた。

人類は一度「MacでVRは難しい」という結論を出した。

その後、Wine、Metal、OpenXR、互換レイヤー、ストリーミング技術を別々の人間たちが開発し、結果として別のルートが少しずつ繋がり始めた。

技術史というものは、どうしてこうも迂回路だらけなのだろう。

（この記事は、AI生成されたものを一部編集したものです。）