2026年7月リリース

6月が土台を築く月だったとすれば、7月は各部屋の内装を仕上げて完成させる月でした。

30日間のうちに19回ものリリースを実施し（2回のメジャーバージョンアップを含む）、8月に突入してわずか2日後には20回目となる v3.4.0 もリリースされました。Turian Studio は「単に動くエディタ」から、「丸一日作業していても心地よいエディタ」へと大きな進化を遂げました。

しかし、7月の進化の物語は単なる機能リストではありません。すべてはある「1つのシーン」から始まりました。

月中旬のこと、私たちは Turian に「Amazon Lumberyard Bistro」シーンを読み込ませてみました。280万ポリゴン（トライアングル）、1,591個のサブメッシュ、132種類のマテリアル、633枚の圧縮テクスチャ、総容量1.4 GBにおよぶ膨大なソースアセットです。結果、最初の描画テストで Turian はわずか32個のサーフェスを描画しただけで音を上げてしまいました。そこから始まった試行錯誤——フォーマットの改修、カリングの実装、シャドウの再構築、プロファイリング基盤の整備、そして2回のメジャーバージョンアップのうち1回——そのすべてが、このシーンを問題なく読み込み、レンダリングし、自由自在にカメラで飛び回れるようにするための努力から生まれたのです。

• ずっと作業していたくなる Studio へ
• ゲームの「顔」を作る：インゲーム GUI
• 飛躍的な進化を遂げたレンダラー
• Bistro 攻略記
• インポート機能強化：glTF だけにとどまらない
• クロスプラットフォーム対応：Windows 版の登場
• 混乱のないバージョンアップ
• 将来に向けた土台構築
• 今後の展望

ずっと作業していたくなる Studio へ

6月のエディタは機能的でした。7月のエディタは快適です。

ドッキングパネル

Ticket #90

Studio のワークフローにおける最大の変更点：パネルの位置が固定されなくなりました。Hierarchy、Scene View、Game View、Inspector、Asset Browser、Profiler、Log の全パネルを自由自在にドラッグ、ドッキング、ドッキング解除、分割、再配置し、各プロジェクトに最適なレイアウトを組み上げることができます。

レイアウトはセッション間で保持されるため、一度設定すれば完了です。初期状態に戻したい場合は、「Reset Layout」をワンクリックするだけでデフォルト状態を復元できます。組み込みのプリセット（Default、4 Split、2x3、Tall、Wide）を使えば、シーン編集、UI デバッグ、パフォーマンス検証など、用途に応じた最適な配置からすぐに作業を開始できます。

内部構造としては、新しい Panel API の導入により、プラグインやパッケージから独自のカスタムパネルを登録できるようになりました。エディタのコンポジションシステムはハードコードを脱却し、将来追加されるあらゆるツールやビジュアライザをファーストクラスのドッキングウィンドウとして統合可能です。

ウェルカムパネル

Tickets #153, #149

これまでプロジェクトを開かずに Studio を起動すると、空の Hierarchy と真っ白なビューポートが表示されるだけでした。今アップデートからは「Welcome」パネルが出迎えます。最近開いたプロジェクト一覧と各パス、分かりやすい「New Project」「Open Project」ボタン、エンジンバージョンの表示に加え、公式ドキュメント、ブログ、チェンジログ、Discord、Matrix、イシュートラッカーへのダイレクトリンクが用意されています。

このパネルも他のパネルと同様にドッキングや消去が可能ですが、プロジェクトがロードされていない時のデフォルト画面として機能し、プロジェクトを開くとスムーズに脇へ移動します。

トップバーのプロジェクト切替ドロップダウンも強化されました。最近使ったプロジェクトに「新しいウィンドウで開く」アクションが追加され、2つのプロジェクトを並べて表示できるようになりました。また、未保存の変更がある状態でプロジェクトを切り替えようとすると警告が表示されます。この変更検知（dirty-check）はウィンドウ閉鎖処理への個別実装ではなく、共有の内部 API として構築されているため、アプリケーション終了、プロジェクト切替、別ウィンドウ起動といった、作業内容が失われる可能性のあるすべての経路で共通して機能します。

テーマ機能

Tickets #87, #104, #122

Dark、Light、Dark High Contrast、Darcula、Catppuccin —— 5種類の組み込みテーマを標準搭載。View メニューからリアルタイムで切り替え可能です。テーマ名にカーソルを合わせるだけで即座にプレビューされ、クリックで決定・保存されます。

基盤となる .uitheme アセット形式により、テーマはファーストクラスの編集可能リソースとなりました。既存テーマを複製し、色、角の丸み、パネル境界線の幅などを変更するだけで、独自のカスタムテーマを作成できます（Inspector 上でリアルタイムプレビューを見ながら調整可能）。

テーマはファイルとしてインポート・エクスポートできるため、チーム内で共通のデザインスタイルを簡単に共有できます。同じインフラにより、フォントサイズ、UI のズーム倍率、システムフォントの上書き設定なども管理されており、View メニューからのセッション一時調整や、Settings からの永続設定が可能です。

スライダーをドラッグして、同じエディタレイアウト上での Dark テーマと Light テーマを比較してみてください：

Output / Log パネル

Ticket #23

どんなゲームエンジンでも stdout へのログ出力は行いますが、プロ仕様のエディタに必要なのは「目当ての情報をすぐ見つけられる環境」です。

新しい Log パネルは、エンジンおよびエディタの全メッセージをドッキング可能なコンソールに集約します。ログレベル（Debug, Info, Warning, Error）フィルタ、カテゴリのドロップダウン、フリーテキスト検索を備えています。同じ内容の連続ログは、繰り返しカウンタ付きの1行に折りたたまれるため、ループ処理のデバッグ時にもログが埋もれません。エラー発生時のスタックトレースは自動的にシンボル化・折りたたみ展開され、クリック可能な ファイルパス:行番号 参照が提供されます。

これにより、レイアウト下部に Log パネルを常時ドッキングしておいても作業の邪魔にならず、トラブル発生時にノイズの中から真に必要なシグナルを素早く検出できます。

統合設定エディタ (Settings Editor)

Ticket #88

これまで Studio の設定は、JSON ファイルや各パネルの固有メニュー、文書化されていないデフォルト値など、バラバラな場所に分散していました。7月リリースでは、本格的な Settings エディタが独立タブとして実装されました。検索可能なサイドバー、整理されたカテゴリ（General, Editor Camera, Asset Browser, UI, Performance, Shortcuts）、および未保存の変更を示す dirty インジケータを備えています。

このエディタは Inspector と共通のリフレクションおよびプロパティウィジェット基盤を再利用しているため、全設定項目においてアセットプロパティと同様の型対応エディタ、値の検証、変更追跡が適用されます。

アセットブラウザとアセットプレビュー

Tickets #79, #80, #83, #81, #68, #85, #72, #84, #19, #25

アセットブラウザには今月、3つのナビゲーションモードが追加されました。Grid（サムネイル表示）、Grid+Tree（フォルダツリー付きサムネイル）、Tree Only（ファイル構造ツリー表示）の3種で、ツールバーのアイコンからワンクリックで切替可能です。パンくずリスト（Breadcrumb）もクリック可能になり、上位階層への移動がスムーズになったほか、「Create」メニューもフラットな一覧からカテゴリ別のサブメニュー構造に刷新されました。

グリッド表示のセルは固定幅化され、600枚のテクスチャが入ったフォルダでも、ファイル名の長さに影響されない整然としたモザイク状に整列します。長すぎるファイル名はホバー時にフル表示され、拡張子の非表示切り替えやズームレベルに応じた拡大縮小にも対応。1つのインポートモデルから生成されたサブアセット（メッシュ、マテリアル、プレハブなど）は、親タイルの + アイコンからインライン展開できます。

これらに合わせてアセットのプレビューサムネイル機能も登場。アセットを選択すると Inspector 上にビジュアルプレビューが表示され、テクスチャ、3Dモデル、マテリアルなどを直接確認できます。プレビュー機構もプラグインアーキテクチャで拡張可能なため、独自アセット型にカスタムプレビューレンダラーを実装することも容易です。

ショートカットバインドとコマンドレジストリ

Ticket #14

キーボードショートカット機能が本格的なシステムとして刷新されました。中央コマンドレジストリが、エディタの全アクション（Undo, Redo, Save, Play/Stop, Build Game, Next Tab など）をデフォルトキーにマッピング。Settings 内の専用エディタから自由に再割り当てしたり、セカンダリキーの設定、ショートカットの解除が行えます。さらに自動衝突検出も備えており、2つのコマンドに同じキーが割り当てられそうになると即座に警告が表示されます。

アクティブなショートカットは各メニュー項目の横にも表示されるため、キー割り当てをわざわざ暗記する必要もありません。

シーンビュー方向ギズモ (Orientation Gizmo)

Ticket #126

Scene View の右上隅にジャイロスコープ型の方向ギズモを追加しました。Blender や Unity、Unreal Engine でおなじみの軸操作ウィジェットです。カメラのワールド空間における回転と常に連動するため、複雑なシーンを長時間操作していても、どちらが「上」なのかを一目で把握できます。

単なる表示器にとどまらず、ラベル付きの面をクリックすると、現在の注視点を維持したままその軸からの平行視線へカメラが即座にアラインメントされます。正面図・側面図・上面図への切り替えが、手動のドラッグ操作なしでワンクリックで完了します。投影モード切替（パースペクティブ / 平行投影）もギズモ直下に配置されています。

バックグラウンドタスクと FPS セマフォ

Tickets #151, #124

Bistro のような大規模プロジェクトをインポートすると、1,000件を超える個別のインポートタスクが発生します。以前のタスクバーはすべてのタスクをそのまま並べて表示していたため、技術的には正確でも実用上は極めて使いづらいものでした。

新たなバックグラウンドタスクシステムでは、親子関係のあるタスク群を単一の集計プログレスバー（全体の進捗率、経過時間、Cancel ボタン）としてスマートに折りたたむように刷新。個々のサブタスクは内部で追跡され、必要に応じて展開や個別キャンセルが可能です。

併せて、ステータスバーにはシグナル表示（緑：60 FPS以上、黄：30 FPS以上、赤：30 FPS未満）付きの常時 FPS カウンタが追加されました（閾値は Settings で変更可能）。重要なポイントとして、このカウンタは UI の再描画タイミングではなく、実際のフレームプレゼンテーション（画面表示）周波数をサンプリングするため、エディタがアイドル状態であっても正しくリアルタイムの FPS を報知し続けます。

ローカライゼーション（多言語対応）

Tickets #36, #123

Studio が多言語に対応しました。完全なローカライゼーションシステムを搭載し、初期状態で英語とブラジルポルトガル語をサポート。今後の拡張を見据えた柔軟な設計となっています。

単なる文字列置換にとどまらず、複文ルール（CLDR規格準拠）、メッセージフォーマットの補間、文脈に応じた翻訳の打ち分け、ロケールごとのフォント自動切り替え（CJK文字、アラビア文字、デーヴァナーガリー文字等に必須）までカバー。ソースコードから翻訳対象文字列を自動抽出してバイナリテーブルにコンパイルするビルドツールも統合されているため、新しい言語の追加はコード修正なしでデータ更新のみで完結します。

言語切替はシームレスで、Settings で切り替えた瞬間に Studio を再起動することなく UI 全体が更新されます。

ゲームの「顔」を作る：インゲーム GUI

Tickets #92–#103, #107

メニュー画面すら描画できないエンジンでゲームを出荷することはできません。7月初旬、この課題を一気に解決する12件のチケットが消化されました。

Turian で制作するゲームに、UIDoc アセットをベースとした本格的なインゲーム GUI システムが導入されました。Studio 上で宣言的に UI ドキュメントを作成し、実行時にインスタンス化して使用します。ナインパッチ（Ninepatch）パネルによる角の歪まない画像拡大・縮小、ラベルによるテキスト表示、型安全なイベントをゲームコードへ直接送出するボタンコンポーネントなどを完備。UIDoc は独立したアセットであるため、タイトル画面の調整などはプログラマーの再コンパイルを必要とせず、デザイナーがアセットを編集してリロードするだけで完了します。

UI エディタは独自ノードツリーと各種レイアウト・スタイル調整用 Inspector（expand, gravity, margin, tint, corner radius, font, font size 等）を備えた WYSIWYG キャンバスです。基準解像度に対するレターボックススケーリング機能により、異なるアスペクト比の画面でも意図したレイアウトが維持されます。

月後半には、GameEvent チャネルアセットも実装されました。コンポーネント間に直接の依存関係を持たせることなく、ドアの開閉、会話の開始、効果音の再生といったゲームロジックをデータ駆動型で接続できる仕組みです。UIDoc 上のボタン操作がチャネルを発行し、それを購読する各要素が反応します。Inspector 上で Unity の UnityEvent のように視覚的にイベント接続を行えます。

さらに、スクリーンショット検証機能も同時にリリースされ、インゲーム UI の自動ビジュアルリグレッションテストが可能となりました。ヘッドレス環境で UI フレームを描画し、期待される参照画像と自動比較できます。

飛躍的な進化を遂げたレンダラー

7月のアップデートにより、Turian のレンダリング機能は「単に描画できる」レベルから「息をのむほど美しい」レベルへと昇華しました。

イメージベースドライティング (IBL) とスカイボックス

Tickets #135, #144

3D アーティストに尋ねれば誰もが「ライティングこそがシーンの成否を分ける」と答えるでしょう。これまで Turian は点光源・スポットライト・平行光源といった解析的ライト（Analytic Lights）しかサポートしておらず、屋外シーンはどうしても平坦で人工的な印象になりがちでした。

イメージベースドライティング (IBL) がその状況を一変させます。HDR 環境マップ（.hdr / Radiance 形式）をインポートするだけで、それがそのまま背景のスカイボックスとなり、同時にシーン全体の主要な光源として機能します。エンジンは環境マップを 2 次の球面調和関数 (Spherical Harmonics) に投影して拡散照射 (Diffuse Irradiance) を計算し、プリフィルタリングされた鏡面環境マップから反射 (Specular Reflection) をサンプリングして、PBR シェーダーへ供給します。

この鏡面反射計算には月中旬にさらなる改良が加えられました。初期実装では正距円筒テクスチャの Mip チェーンを代用していましたが、極付近で過度なボケが発生したり、浅い入射角（Grazing angle）で反射ローブの形状が歪む問題がありました。そこで、本格的な Render-to-Cubemap 変換と Mip レベルごとの GGX 重点サンプリングによるプリフィルタリング（業界標準の Split-Sum アプローチ）へと刷新。低ラフネスではシャープに、中ラフネスでは正しい形状で反射が表現され、極部分のアーティファクトも解消されました。ユーザー向けの EnvironmentComponent API はそのままに、内部のサンプリングクオリティのみが大幅向上しています。

結果として、リアルな HDRI で照らされた屋外シーンは、手動で大量のライトを配置することなく極めて自然な陰影を獲得できます。たった1つの環境マップで、本来なら数十個のライト調整を要するアンビエント・ディレクショナル・リフレクションの全情報を網羅できます。

スライダーをドラッグして、解析ライティングのみ（前）とイメージベースドライティング（後）の同じシーンを比較してください：

カラーマネジメント：sRGB と ACES トーンマッピング

Ticket #27

従来の PBR ライティング計算はガンマ空間で行われており、アルベドテクスチャの sRGB→リニア変換がなく、出力段でのトーンマッピングも未実装でした。7月リリースではこの両方を徹底改善。

カラーテクスチャ（アルベド・エミッシブ）は sRGB としてサンプリングされ、ライティング計算前に自動的にリニア空間へ変換されます。ノーマルマップやメタリック/ラフネス、オクルージョンは本来あるべきリニア空間のまま処理されます。すべてのライティング計算がリニア空間で行われ、最終出力はガンマ補正前に、映画産業の標準である ACES Filmic トーンマップを通過します。

これにより、現実のカメラやディスプレイの物理特性に合致した正確なライティングが実現。金属は真の金属の質感を持ち、暗部はディテールを保ち、ハイライトは白飛びせず滑らかにロールオフします。

HDR ポストプロセス

Ticket #136

正確なライティングが「リアルな画像」を生み出すとすれば、ポストプロセスはそれを「写真」へと昇華させます。

Turian にモジュール式の HDR ポストプロセススタックが搭載されました。ライティングパスの後に実行され、ブルーム（閾値・強度・ブラー半径を調整可能。高輝度面が本物のレンズのように発光）、カラーグレーディング（ASC CDL 規格の Lift / Gamma / Gain コントロール）、ビネット（強度・半径・ぼかし具合）を適用できます。

特筆すべきはその制御手法です。全画面一律の設定ではなく、PostProcessVolumeComponent としてボリューム制御が可能です。ボリュームはシーン全体に適用されるグローバルと、特定のバウンディングボックス/スフィア内に限定されるローカルを選択可能。重複するボリューム間は優先度と距離に応じた加重平均でスムーズにブレンドされ、各エフェクトカテゴリごとに個別オン/オフフラグを持つため、「ブルームは維持したまま特定のエリアだけカラーグレーディングを変更する」といった演出も容易です。

これにより、プレイヤーがオーニング（日よけ）の下を歩く時は温かみのあるほのかなブルームを効かせ、路地裏に入ると冷たく彩度の低いトーンへ変化させるといった演出を、一切のスクリプト記述なしで実現できます。全パラメータは Inspector のスライダーでリアルタイム確認しながら調整可能です。

ドラッグして、ポストプロセスボリュームを無効にした（前）場合と有効にした（後）場合のビストロのテラスを比較してください：

ブレンドモード・カリング・アルファマスク

Ticket #26

マテリアルが Alpha Blend および Additive（加算合成）モード、設定可能なフェイスカリング（Front, Back, None）、および Alpha Mask（Cutout）レンダリングに対応しました。透明オブジェクト、パーティクルエフェクト、植物の葉、ガラス表現などをトリッキーな回避策なしに直感的に制作できます。

Bistro 攻略記

Epic #132

どのようなゲームエンジンにも、自らの限界を突きつけて打ち砕くための「究極のテストシーン」が必要です。

「Amazon Lumberyard Bistro」はグラフィックス業界における標準のストレステストです。外部シーンだけで280万ポリゴン、1,591個のサブメッシュ、132種類のマテリアル、合計1.4 GBにおよぶ633枚の DDS テクスチャが極めて高密度に密集しています。実際のゲーム制作現場からそのまま切り出してきたような巨大アセットであり、Turian がこれまで見過ごしてきた内部的なボトルネックをすべて露呈させました。

壁への衝突

最初のインポート処理自体は「成功」と表示されたものの、画面に描画されたのは 1,591 サブメッシュ中わずか 32 サーフェス だけでした。

原因はインポーターではなく、レンダラー内部に硬直的に組み込まれていた MAX_SUBMESH_MATERIALS = 32 という上限値にありました。この制限を解除するにはマテリアルのバインド方式そのものを根本から変更する必要があり、シーンフォーマットの破壊的変更を伴う v3.0.0 へのメジャーバージョンアップ（後述）へと繋がりました。マテリアルバインドを「サブメッシュインデックス単位」から「マテリアルスロット単位」に変更したことで、132種類のマテリアルを共有する 1,591 個のサブメッシュを持つモデルでも、必要なスロット数は 1,591 ではなく 132 個で済むようになりました。上限値は 160 に拡張され、GPU 上のサブメッシュ制限は完全撤廃されました。

これにより街並み全体が一気に表示されるようになりましたが、同時にパフォーマンスは壊滅的（実用に耐えない重さ）となりました。

データ軽量化

Ticket #141

描画パスの最適化に取り組む前に、まず扱うデータ自体を削減する必要がありました。FBX のクック処理に頂点結合（Vertex Welding）パスを追加し、同一座標の頂点を共有・インデックス化。272 MB あった頂点バッファ容量を大幅に削減し、インポート速度も向上させました。VRAM 使用量の削減、GPU キャッシュ効率の改善、イテレーション速度の向上という一石三鳥の効果が得られました。

3度にわたるカリングの刷新

Ticket #143

視界外を描画スキップする視体積カリング（Frustum Culling）は、プロファイリング結果に基づく 3 世代のアーキテクチャ刷新を経て完成しました。

第1世代（CPU オブジェクト単位カリング）：カメラ視体積の外側にあるメッシュ全体をスキップ。しかし Bistro は実質的に 1つの巨大なメッシュ で構成されていたため、効果は皆無でした。

第2世代（CPU サブメッシュ単位カリング）：毎フレーム CPU 上で 1,591 個すべてのサブメッシュ境界を判定。一定の効果は出たものの、毎フレームの CPU 判定コスト自体が新たなボトルネックとなりました。

第3世代（現行・GPU 駆動カリング (GPU-Driven Culling)）：Compute Shader が各サブメッシュのバウンディングボックスを視体積に対して高速判定し、間接描画コマンド（Indirect Draw Command）を GPU バッファへ直接書き込みます。レンダーパスはマテリアルグループごとに1つの DrawIndirect コールを発行するだけで完結。CPU によるサブメッシュ反復処理は完全に撤廃されました。サブメッシュはマテリアル順にソートされ、パイプラインやバインドの切替オーバーヘッドも最小化されています。

併せて、シーン光源データを GPU Storage Buffer へ移行し、1シーンあたりの最大光源数を 8 個から 256 個 へと大幅拡張しました。

推測ではなく「計測」による最適化

Tickets #147, #146

カリングを 3 回書き直した後も依然として十分なフレームレートが得られず、正直なところ「処理時間の真のボトルネックがどこにあるのか誰にも分からない」状態に直面しました。オクルージョンカリング、Hi-Z、メッシュレット、LOD など候補は山ほどありましたが、勘で手をつければ「4回目の当て推量」になってしまいます。

そこで 4 回目の最適化を行う前に、包括的な計測基盤を導入しました。各レンダーパス（Shadow, Cull Compute, Main, Transparent）の前後にフェンス同期付きの GPU タイムスタンプクエリ を挟み込み、Compute フェーズを含む CPU ゾーン計測結果とともに Studio の Profiler パネルにパス単位でリアルタイム表示できるようにしました。プロファイラの gpu_time_ms は従来の CPU 推定値から、真の GPU ハードウェアタイマー値へと生まれ変わりました。

この計測結果はすぐさま威力を発揮しました。なんと「インポート済みプロジェクトを開く際、起動のたびに全ソースアセット（1.7 GB 分のテクスチャデータ等）を再読み込みしてハッシュ計算していた」という衝撃の事実が発覚。ファイル更新日時（mtime）とサイズの高速判定パスを追加したことで、起動時の超重厚なハッシュ処理が一瞬の stat チェックへと激変しました。

なお、パスごとの GPU タイミング計測は意図的にオプトイン（選択式）としています。タイムスタンプの取得には GPU 同期が発生するため、ボトルネック調査時以外はオフにしておく方が効率的だからです。Profiler パネルのチェックボックスから V-Sync やフレームレート上限設定と合わせて切り替え可能で、Play モード開始時に自動記録されます。

フレーム描画コストの最適化

プロファイリングの知見により、地味ながら決定的な改善が次々と適用されました。マテリアル解釈結果のキャッシュ化（描画ごとの再評価を撤廃）、シャドウパスへのカスケード別 Frustum Culling 導入（全シーンを 4 回描画する無駄を削減）、対応デバイスでの 4x マルチサンプリング (MSAA) レンダリング導入など、スーパーサンプリングよりはるかに低い負荷でシャープなエッジ表現を実現しました。

リファレンスに迫るビジュアル表現

Ticket #157

シーンが快適に動くようになった後、ORCA の公式リファレンスレンダリング と比較した際の最後の壁は「オクルージョン（陰影の深み）」に関する視覚的差でした。従来の IBL アンビエント光は全周の環境光を無限遠として扱うため、物陰やオーニングの下などの奥まった隙間にも空からの光が満遍なく届いてしまっていたのです。リファレンス画像の重厚感は、まさに接地面や隙間の「接地シャドウ（Contact Darkening）」によって作られていました。

この差を埋めるため、以下の 2 つの重要機能を導入しました。

カスケードシャドウマップ (Cascaded Shadow Maps)：平行光源の影を 4 つのカスケードに分割し、単一のシャドウアトラスを共有。対数/一様混合分割スキームを採用し、カスケードごとに個別の Bias と GPU カリング処理を適用。手前のカスケードではクッキリとした接地影を表現しつつ、遠方のカスケードで遠くの街並みまでカバーします。

スクリーンスペースアンビエントオクルージョン (SSAO)：深度と法線を描画するプリパスを追加し、幾何形状が遮蔽される箇所で IBL/アンビエント項を暗く減衰させる SSAO パス（ブラー処理付き）を構築。建物の角、ドア枠、テーブルの下などが、浮いた感じにならずしっかりと世界に接地して見えるようになりました。

なお補足として、Bistro のアセット自体は本来「街灯と室内光がメインの夜間シーン」として制作されていますが、ORCA リファレンスは明るい昼間の屋外設定です。SSAO は設計上アンビエント項のみを減衰させるため、夜間シーンでの効果は確かながら昼間ほど強烈には目立ちません。バウンスライティング（間接光）やローカル反射については #157 にて引き続き開発を進めています。

インポート機能強化：glTF だけにとどまらない

FBX インポート

Tickets #133, #142, #141

glTF が現代の業界標準となった一方で、Maya や 3ds Max といった主要 DCC ツールや市販のアセットライブラリでは、依然として FBX が広く使われています。

Turian は FBX ファイル（バイナリ / ASCII 両対応）の直接インポートに対応しました。メッシュ、マテリアル（PBR メタリック/ラフネスモデルへの高精度マッピング）、埋め込み/外部テクスチャ、および完全なノード階層構造を自動抽出して Turian アセットへ変換します。FBX のシーンツリーは、全サブアセットを保持したプレハブとして保存され、そのままシーンへ配置可能です。

glTF 階層インポート

Ticket #8

従来の glTF インポーターはメッシュとマテリアルをインポートするもののシーン階層を破棄していました。7月リリースにより glTF / GLB ファイルのノード階層がプレハブとして完全保持されるようになり、各メッシュの親子構造が正しく再現されます。多数のパーツで構成される複雑なモデルも、バラバラのメッシュ一覧ではなく整理されたプレハブとして取り込めます。

DDS テクスチャインポート

Ticket #134

GPU 用に事前圧縮された DDS (DirectDraw Surface) ファイルの直接インポートに対応しました。BC1 から BC7 までの全ブロック圧縮フォーマットをサポートし、適切な sRGB タグ付けやノーマルマップの Y 軸反転（Y-flip）も自動処理されます。事前圧縮済み DDS を含むアセットパックを無変換でそのまま利用できます。

Git に優しいメタデータ構造

Tickets #148, #37, #145

地味ながら重要な改善点として、各アセットの .meta ファイルが抱えていた問題の解決があります。従来は GUID、アセット型、インポート設定といった「バージョン管理（Git）に含めるべき永続情報」と、ソースハッシュ、ファイルサイズ、更新日時 (mtime)、インポーターバージョンといった「一時的なキャッシュ情報」が同じ .meta に混在していました。

Git はファイルの mtime を保持しないため、リポジトリを git clone して最初にプロジェクトを開いた際、全ファイルの .meta が差分として書き換えられてしまう問題が発生していました。さらにインポーターのバグなどで誤った書き換えが起きると、チーム全員の git status が汚染されてしまっていました。

今回の改修により、キャッシュ情報は Git 管理外（.gitignore 指定済み）の .cache/ ディレクトリへ GUID キーで完全分離されました。これにより、プロジェクトのクローンや開閉で無駄な .meta 差分が発生しなくなり、インポーター更新時にも追跡対象ファイルが汚染される心配がなくなりました。

併せて、Inspector 上でシーンオブジェクトの「Active」チェックボックスを切り替えた際にシーンが Dirty（未保存）状態としてマークされず変更が消えてしまう不具合も修正されました。

クロスプラットフォーム対応：Windows 版の登場

Tickets #119, #120

Turian Studio が Windows 上でコンパイル・動作するようになり、Vulkan に加えて Direct3D 12 (D3D12) をフォールバック GPU バックエンドとしてサポートしました。今月最も大規模なインフラ改修であり、SDK 検出処理の修正、プラットフォーム依存のリンク・パス解決、クロスプラットフォーム動的ライブラリローダーの実装（Zig 0.16 の std.DynLib が Windows 未対応だったため）、ウィンドウ生成および入力処理の検証などを完遂。CI 上で Windows 版 Studio の完全なコンパイルチェックが走り、公式リリースパッケージには CLI と Studio の両方が含まれます。

8月頭には、Play モードのコンパイル＆ロードサイクル（zig サブプロセスを通じて libturian_play.dll をビルドし動的ロードする仕組み）やスクリプトリフレクション・コード生成処理に含まれていた POSIX パス依存の排除など、実行時安定化の強化が実施されました。

マルチプラットフォーム対応とは単に各種 OS で動くだけでなく、各環境の最適なグラフィックス API（Linux/Windows では Vulkan、Windows フォールバックで D3D12、将来的な macOS での Metal 支持基盤）を的確にターゲットすることを意味します。

混乱のないバージョンアップ

7月には v2.0.0 と v3.0.0 という 2 つのメジャーバージョンアップが実施されました。どちらも必要な破壊的変更に伴うものでしたが、ユーザー側の移行作業はわずか数分で完了するシンプルなものでした。

v2.0.0：サブメッシュごとのマテリアル

Tickets #45, #8

従来の glTF/GLB インポーターは最初のメッシュの最初のプリミティブのみを処理していました。v2.0.0 ではサブメッシュ単位のマテリアル管理システムを導入し、TMSH メッシュフォーマットへのサブメッシュテーブル追加、MeshRendererComponent の material フィールドから materials 配列への変更、シーンファイルのフォーマット更新を実施しました。詳細と背景は v2.0.0 リリースアナウンス を参照してください。

v3.0.0：マテリアルスロット単位のバインド

Ticket #140

v2 ではサブメッシュインデックス単位でバインドしていたマテリアルを、v3.0.0 ではマテリアルスロット単位へ移行。数千のサブメッシュが数種類のマテリアルを共有するようなモデルにおいて、必要なスロット数だけを効率的に保持できるようになりました。マテリアル上限は 32 から 160 に拡張され、GPU サブメッシュ制限は撤廃されました。

移行手順は極めて簡単で、turian-cli migrate <プロジェクト名> を実行してシーンファイルを自動書き換えし、レンダラーマテリアルにアクセスするコードのインデックスをサブメッシュ番号からマテリアルスロット番号へ更新するだけです。詳細は v3.0.0 移行ガイド をご覧ください。

次回のアップデートを「退屈」にするためのマイグレーション構造

Ticket #137

1ヶ月に 2 度の破壊的変更を経験したことで、1 つの課題が明確になりました。project.json に記録されている turian_version を誰もチェックしておらず、移行処理がその場凌ぎで作成されていた点です。

7月リリースでは、本格的なバージョンチェック＆自動マイグレーション機構を構築しました。Studio でプロジェクトを開いた際、エンジンが保持するバージョンとプロジェクトの記録バージョンを自動比較（メジャー不一致時は必須通知、マイナー差分は Settings 設定依存）。移行処理は1バージョンアップにつき1ファイルの独立したレジストリとして管理され、べき等性（Idempotency）メタデータを保持します。v2 の material_guid → material_guids 修正も本フレームワークの最初の移行定義として取り込まれました。

まず CLI ツールが対応し、turian-cli migrate <プロジェクト名> [--yes|--no] [--dry-run] により CI 環境での自動実行や、ファイル更新前に保留中の移行手順を一覧確認できるドライラン機能を備えています。Studio 起動時のダイアログ表示機能も準備中です。設計思想の詳細は ADR-0012 をご参照ください。

将来に向けた土台構築

すべての変更が見出しになる機能とは限りません。いくつかは、将来の機能が依存する目に見えないインフラストラクチャです。

プラグイン＆パッケージシステム

Tickets #4, #20, #56

Turian にマニフェスト、モジュール、実行時登録機構を備えたプラグイン＆パッケージシステムが実装されました。プラグインからカスタムメニュー、ドッキングパネル、Inspector のプロパティドロワーを追加可能です。パッケージマニフェストで依存関係と権限を定義し、プロジェクトフォルダから自動検出・ロードされます。エンジン本体のコードを汚すことなくコミュニティ製プラグインやアセットパックを追加できるエコシステムの第一歩です。

アーキテクチャの軽量化 (A Thinner Studio)

Ticket #152

Studio 内に混在していた GUI 非依存のモジュール（プロジェクト操作、セッション状態、Undo、クリップボード、インポート処理等）を services/ から editor/ モジュールへ移設し、機能別（project/, session/, assets/, build/, tasks/, shortcuts/, i18n/）に再整理しました。

これにより editor/ は完全な GUI フリーとなり、ウィンドウなしで単体テストが可能に。studio/ は earnings その上の UI 殻層という明確な境界が成立しました。この分離こそが、CLI や CI チェック、MCP サーバーといったヘッドレスツール群がエディタロジックを完全再利用できる秘密です（ADR-0015 参照）。

アーキテクチャ決定記録 (ADR)

今月の主要な技術選定の背景と理由が、コミットログではなくドキュメントとして明文化されました。パッケージシステム、DI（依存性注入）、ギズモ、Play モード、ライティング・シャドウ、GPU カリング、バージョニング、Editor/Studio 境界などをカバーする 15 件の ADR を公開しています。

フォントのアセット化

Ticket #109

フォントファイルが 3D モデルやテクスチャと同様にインポートパイプラインのファーストクラスアセットとして扱われるようになりました。ロケールごとのフォント上書き（CJK文字描画に必須）に対応し、多言語システムと連動して動的にフォントが切り替わります。

ビルド出力・アイコン・CI 改修

Tickets #131, #86, #89

ビルドパイプラインの出力先が設定可能な .public フォルダに変更され、生成された実行ファイルのウィンドウやタスクバーに表示されるカスタムアイコンを設定可能になりました。Studio 自体にもファビコンとバージョン情報 (About) ダイアログが追加されています。CI 側ではリリースパイプラインを YAML 直書きから Zig 製リリースツールのサブコマンドへ移行し、ローカルと CI で同一コードを実行可能な 2 ステージ構造にシンプル化しました。

MPL 2.0 へのライセンス変更

Turian のライセンスを GPLv3 から Mozilla Public License 2.0 (MPL 2.0) へ変更しました。ファイルレベルのコピーレフトライセンスとなったことで、エンジン本体への改善コードはオープンソースとして共有しつつ、Turian 上で商用のプロプライエタリゲームを開発・配信することが可能となりました。コミュニティからの要望に応えた変更であり、経緯は GPLv3 から MPL 2.0 への移行 をご覧ください。

今後の展望

7月のアップデートにより、Turian は「将来が楽しみな試作品」から「実際に触っていて楽しく生産的な開発環境」へと確かな脱皮を遂げました。ドッキングパネル、テーマカスタマイズ、ショートカット、本格的な Log パネル、多言語対応を備えた Studio は本物のプロ向けツールの質感を備えています。レンダラーは美しく説得力のある映像を出力し、主要 3D フォーマットを網羅し、かつて 32 サーフェスで撃沈していたエディタが今や街並み全体を快適にストリーミング描写します。

Bistro 攻略の旅はまだ終わりではありません。間接光（バウンスライティング）やローカル反射、オクルージョンカリングなど課題は残っていますが、この挑戦こそが技術を大きく前進させてくれました。一切誤魔化しのきかない本物の巨大シーンと向き立ったことこそが、あらゆるベンチマークテスト以上の素晴らしい教師となったのです。

8月もさらなるレンダリング機能強化、アニメーション、オーディオ、Studio 側のマイグレーションダイアログ実装などが控えています。今後の進捗は ロードマップ をご参照ください。

ぜひ最新リリースをダウンロードし、公式ドキュメントをチェックして、Discord や Matrix のコミュニティにご参加ください。

エディタでお会いしましょう！