WinUI 3でFBXビューアをMicrosoft Storeへ——FBX QuickView開発の全記録

2026年6月24日 | ツール開発 / WinUI 3 / C#

UnityやUnrealにFBXをインポートする前に、「中身、ちゃんと出てる？」と確認したくなる瞬間は誰にでもある。Blenderで書き出した直後、Mixamoから落としたキャラ、Mayaの納品データ——毎回DCCを起動するのは重い。そこで作ったのが、Windows向けの軽量FBXビューア『FBX QuickView』だ。本記事では、WinUI 3を選んだ理由から、巨大モデルで画面が真っグレーになる地獄、Microsoft Store向けMSIXビルドまで、開発のリアルをまとめる。

なぜWinUI 3なのか——「軽く、Storeに載せたい」

3Dプレビューアの選択肢は多い。Electron + three.js、WPF + SharpGL、Unityをビューアとして起動する……。今回の要件はシンプルだった。

ネイティブに近い起動速度——常駐ツールとしてサッと開きたい
Microsoft Store配布——インストールの敷居を下げたい
完全オフライン——ファイルを外部に送らない
FBXに特化——汎用DCCビューアほどの機能は不要

この条件だとWinUI 3 + Windows App SDKが最もバランスがよかった。WPFよりモダンなUIが組みやすく、UWPほど制約がきつくない。さらにMSIXパッケージングがプロジェクトに直結するため、Store提出までの導線が短い。

3D描画はHelix Toolkit for WinUI、FBXパースはAssimpNetを採用した。どちらも実績があり、C#だけで完結する。ネイティブDLL地獄を避けつつ、DirectXベースの描画パイプラインを借りられるのが大きい。

アプリの骨格——ドラッグ＆ドロップで即プレビュー

FBX QuickViewの基本動線は意図的に単純にしている。

開く——［Open］ボタン、ドラッグ＆ドロップ、エクスプローラーでの .fbx ダブルクリック（ファイル関連付け）
見る——右ドラッグで回転、中ドラッグでパン、ホイールでズーム。RMB長押し＋WASDでフライスルー
調べる——シーンツリーでノード選択、プロパティパネルで位置・回転・スケールを編集
表示切替——ソリッド / テクスチャ / ワイヤーフレーム（キー 1 / 2 / 3）

MayaやUnityに近いカメラ操作に寄せたのは、ターゲットユーザーが3D制作者であることが多いからだ。「操作方法を覚え直すビューア」は使われない。ツールバーには Highlight（選択強調）と Grid（床グリッド、Gキー）、Helpアイコンの Controls（操作説明ダイアログ）を配置。About からオープンソースライセンスも確認できる。

UI言語は8種類（日本語・英語・ドイツ語・フランス語・スペイン語・ポルトガル語・中国語・韓国語）に対応。Store向けアプリとして、説明文だけ英語、UIは母国語、というギャップを埋めるための投資だった。

開発で一番ハマった壁——「真っグレーになる車モデル」

小さなテスト用FBXでは問題なく動いていた。ところが、CC0のコンセプトカーFBX（FC_03.fbx）を読み込んだ瞬間、画面が真っグレー、モデルは見えない、カメラがどこを向いているかわからない——という最悪の組み合わせが起きた。

原因を追うと、Assimpが返すシーン境界（バウンディングボックス）の半径が約60,000という異常値だった。Blender側で100倍スケールのまま書き出されていたのが根本だ。カメラのクリップ平面やフィット距離がそのスケールに引きずられ、深度バッファが実質破綻していた。

解決策：スキニング後の実頂点から境界を再計算し、巨大シーンを正規化

対策は2段階。

RecomputeScene Bounds——Assimpのメタデータではなく、スキニング適用後の実メッシュ頂点から境界を計算し直す
NormalizeOversizedScene——半径が閾値（80）を超えるシーンを、半径約8相当にスケールダウンする

読み込みフローは UpdateSkinnedMeshes → RecomputeScene Bounds → NormalizeOversizedScene → 再Recompute → FitView とした。これで「書き出しスケールが狂っているFBX」でも、とりあえず画面内に収まる。DCC側の設定ミスをビューア側で一定程度吸収できる——プレビューツールとしての実用ラインはここで決まる。

UIの細部——アイコン、グリッド、Store掲載文の整合

WinUI 3の CommandBar でラベル位置をいじろうとしたら、存在しない列挙値でXAMLコンパイルが落ちた。最終的にはHighlight / Grid / Controls すべてアイコン＋短いラベルに統一。見た目のずれも解消された。

ViewCubeの「F」ヒントやキーボードアクセラレータのオーバーレイは、画面を汚すので非表示に。Fキー（全体フィット）とGキー（グリッド切替）自体は、ビューポートの KeyDown とルートGridの KeyDown の両方で拾うようにして、フォーカスがどこにあっても効くようにした。

Microsoft Storeの掲載文も、アプリの実態と揃えた。例えばアニメーション再生は現バージョンでは提供していないため、Product features から該当行は外した。審査で「説明と動作が違う」と突っ込まれるのを避けるため、Store文案は機能リストと1対1で対応させている。

Microsoft Store提出——MSIX、runFullTrust、デバイスファミリー

Release構成では WindowsPackageType=MSIX、WindowsAppSDK SelfContained=true で Windows App Runtime を同梱。審査端末で「ランタイムがないから起動しない」を防ぐためだ。

アーキテクチャは x86 / x64 / ARM64 の3本。ビルドスクリプト Build-StoreUpload.ps1 で各Platformを順に dotnet build し、AppPackages 直下のMSIXを拾う。以前は win-x64\AppPackages の古い成果物を参照してしまい、PublisherDisplayName 不一致でPartner Centerが怒る——という初歩的な罠も踏んだ。パスを固定し、マニフェストの PublisherDisplayName を YamamuraFactory に揃えたところで解消。

認定の注意書きには最低限これを書いた。

runFullTrust の理由——Assimp / DirectX / ユーザー操作によるローカルFBXアクセス
ネットワーク不使用——オフライン完結、診断ログは %LocalAppData%\FbxQuickView\Logs\ のみ
テスト手順——FBXをドラッグ、カメラ操作、シーンツリー選択、Controlsダイアログ確認

デバイスファミリーはWindows 10/11 Desktop のみに絞った。Mobile / Xbox / Mixed Reality にチェックを入れると、非対応端末に表示されて低評価を招く。マニフェストに Windows.Universal が含まれていても、Store側の提供設定はDesktop一本に寄せるのが安全だ。

技術スタックまとめ

UI——WinUI 3 / Windows App SDK 1.7
3D——Helix Toolkit WinUI 2.27
FBX読込——AssimpNet 4.1
ターゲット——.NET 8 / Windows 10 1809+
配布——MSIX（x86 / x64 / ARM64）
プライバシー——完全ローカル処理、ネットワーク capability なし

こんな人に使ってほしい

Blender / Maya / 3ds Max / Mixamo から書き出したFBXを、エンジンに入れる前にサッと確認したい人
UnityやUnrealを起動せず、メッシュ・マテリアル・階層だけ見たい人
オフラインで完結する軽量3DビューアをWindows Storeから入れたい人

まとめ——「プレビュー専用」だからこそ速い

FBX QuickViewは、DCCでもゲームエンジンでもない。「FBXを開いて、形と構造を確認して、閉じる」——その一点に機能を絞った結果、起動が軽く、操作が直感的で、Store配布も現実的になった。

個人開発でWinUI 3アプリをStoreまで持っていくなら、機能追加より先にMSIXのパス検証・掲載文と実機能の一致・runFullTrustの説明を固める方が、リリース速度に効く。3Dの中身は、巨大FBXのスケール問題のように、実データを当てないと絶対に見つからない。テスト用の「普通のモデル」だけでは足りない。

FBX QuickViewは Microsoft Store（YamamuraFactory）での公開を進めている。同じように「軽量ビューアをWindowsネイティブで作りたい」人の参考になれば幸いだ。