ゲームの重い場所を、エディタ上の 3D 性能ヒートマップで確認する

ビルド比較で分かるのは、フレームタイムなどの指標がどれだけ悪化したかです。 原因を調べるには、その変化がマップのどこで観測されたかという手掛かりも必要です。

Framedash のヒートマップは、その「どこで」をダッシュボードのマップ画像上に表示してきました。 2026-07-24 の Unity、Unreal Engine 5、Godot (C#) 向け SDK 更新では、同じ集計セルをエディタ内にも表示できるようになりました。 レベルを開いたまま、性能データを半透明の 3D ボクセルとして実際のレベル構造に重ねられます。

集計した性能データを、レベル上に 3D 表示する

ボクセルの一つひとつが、サーバーで集計されたセルです。 テレメトリが記録したワールド座標に、そのまま置かれます。 エディタは XYZ で集計したデータを取得するため、計測された z を持つセルは、床に貼りついた平面ではなく、その高さを中心とした半透明の箱として描かれます。

この違いが、3D 表示の要点です。 平面のグリッドでは、上下に重なる空間が一つにまとめられます。 たとえば、バルコニーとその下の吹き抜けで記録された値が同じ 1 マスに入り、平均されて目立たなくなることがあります。 高さ方向の情報が残っていれば、どの階で値が高かったかを見分けられます。 z を持たない古い API レスポンスは、マップの基準面に平面セルとして今までどおり表示されるので、移行の途中で見えなくなることもありません。

三つのエディタは、青から赤への 5 段階のパレットを共有しています。 色はレスポンス中の最大セルを基準に正規化されるため、赤が意味するのは「取得した範囲での最悪のセル」であって、固定のしきい値ではありません。 Unity のオーバーレイコントロールと Godot のドックは、凡例の横にセル数と最大値を出します。 本当に重いのか、静かなマップの中の相対的な赤にすぎないのかは、この数字で見分けます。 1 回の取得で返るセルは、API の上限である 10,000 件までです。

エンジンごとの開き方

どのエディタも、analytics:read スコープを持つ読み取り用 API キーとプロジェクト ID でデータを読みます。 これは、ゲームがイベント送信に使う書き込み専用 API キーとは別のものです。 エディタには集計結果を読む権限だけを渡し、誤送信で比較用データを汚さないためです。 キーをプロジェクトに保存したくない場合は、エディタを起動する前に FRAMEDASH_ANALYTICS_API_KEY を設定します。 三つの SDK は、明示的なキーが設定されていない場合にこの環境変数を使います。 値はそのエディタプロセスの中だけで使われ、保存されません。

Unity：SceneView のオーバーレイ

Window > Framedash Heatmap を開き、読み取り用 API キーとプロジェクト ID を設定し、マップ一覧を更新してマップを選び、Fetch を押します。 Play モードに入る必要はありません。

以降、SceneView には Show、Frame、Controls の三つのアクションを持つ Framedash Heatmap オーバーレイが並びます。 Frame は読み込んだデータの範囲に SceneView を合わせるので、広いレベルで探し回らずに済みます。 コントロールのウィンドウを閉じても、オーバーレイ自体は消えません。 選択中のマップとオーバーレイの設定はプロジェクトごとに保存される値です。 コントロールを開いたままスクリプトがリロードされたときも、マップ一覧の復元と再取得が走ります。 Play モードの間は表示が止まり、終了後にトグルが有効なままなら戻ります。

座標は Unity の Vector3 の値をそのまま使います。 テレメトリの X/Y/Z が SceneView の X/Y/Z に対応し、地面軸の入れ替えは行いません。 Z Offset は意図して表示をずらしたいときだけ使うもので、クラウド側の座標を書き換えるものではありません。

このオーバーレイ自体は 2026-07-17 の Unity SDK 0.1.4 に平面のクアッドとして入り、2026-07-24 の 0.1.7 でボクセルになりました。

Unreal Engine 5：ビューポートごとの表示フラグ

UE5 SDK 0.1.13 では、取得と表示が分かれています。 Window > Framedash > Framedash Heatmap が取得用のパネルで、PIE の外で取得します。 表示はレベルビューポートごとの Show > Framedash Heatmap フラグが受け持ち、既定は無効、ビューポートのレイアウトをまたいでも独立しています。 片方のビューポートは作業用にきれいなまま、もう片方をヒートマップ付きにする、といった使い分けが可能です。 取得用のパネルを閉じても、表示中のヒートマップは消えません。

エディタシーンのメインレンダーパスを通して描かれるため、通常の F9 と高解像度のビューポートスクリーンショットにヒートマップが写ります。 F9 を押すだけで、チケットに添付する画像を作れます。 Play In Editor の間は表示が止まり、再生が終わるとそれまでのビューポートの選択が戻ります。

クラウドのボクセルは色ごとにバッチ化され、寒色から暖色の順に描かれるので、負荷の高いセルが埋もれません。 セルごとのコリジョントレースは行いません。 API の URL、プロジェクト ID、読み取りキー、不透明度、アラインメント、Z オフセットの置き場所は Project Settings > Plugins > Framedash Heatmap です。

Godot (C#)：エディタのドック

Godot SDK 0.1.8 でエディタに増えるのは、プラグインを有効にすると現れる Framedash Heatmap ドックです。 読み取りキー、プロジェクト ID、API のベース URL を入力し、期間とセルサイズを選んで Refresh Maps を押します。 マップを選んで Fetch Heatmap、Show を有効にし、Frame Heatmap で 3D エディタのカメラをデータに向けます。

最大 10,000 件のセルは、セルごとのノードや物理トレースではなく、キャッシュされた 1 つの半透明ボクセルメッシュとして描かれます。 Show と Frame のほかに用意されているのは、不透明度、Z オフセット、イベントと期間とセルのフィルタ、凡例、セル数、最大値のコントロールです。 設定は project.godot ではなくプロジェクトごとのエディタメタデータ（.godot/editor/editor_layout.cfg）に保存されるので、.godot/ はバージョン管理から外しておきます。 エディタは読み取りキーを転送する前にリダイレクトを遮断し、ゲームの実行中はオーバーレイを隠し、再生が終わったら戻します。 ヒートマップのコードはすべて TOOLS でガードされているため、読み取りキーごとエクスポート後のゲームには入りません。

すでに送っているテレメトリで動く

このために計測を仕込み直す必要はありません。 セルの元になるのは位置付きのイベント、つまり空でない map_id を付けて送ったイベントです。 そのマップがダッシュボードに登録済みであることだけが前提になります。 自動の perf_heartbeat は map_id が空で位置も持たないため、それ単体では空間グリッドに乗りません。

マップに載せられる指標は、FPS、フレームタイム、GPU 時間、メモリ使用量です。 メモリがセル単位で見えるのは、SDK がメモリ系の指標をハートビートだけでなく位置付きイベントにも付けているからです。 2026-07-17 の Unity 0.1.4 が mem.vram と mem.heap を追加したのは、まさにそのためでした。 カメラ回転の記録は既定で有効なので、各イベントにヨーとピッチも乗り、セル詳細ではホットスポットを「どちらを向いていたか」で分解できます。

二つの表示は、答える問いが違います。 ビルドやプラットフォームを見比べるのはダッシュボード、性能が悪化した場所をレベル構造と照らし合わせるのはエディタです。 ただし、ボクセルが示すのは値が観測された場所であり、原因そのものではありません。 周辺の描画負荷、スクリプト、アセットを調べるための出発点として使います。 リリース前に、そのビルドで変更した範囲のヒートマップを確認する作業も、レベルを開いたまま進められます。

始め方

すでにマップ ID 付きでテレメトリを送っているなら、SDK を更新して読み取り用のキーを一つ作るだけです。 まだなら、SDK の統合は 5 分ほど。最初のヒートマップは Free プランのまま確認できます。

• 概念とダッシュボード側の絞り込みはパフォーマンスヒートマップにまとまっています。
• エンジンごとの設定は Unity、Unreal、Godot の各 SDK ガイドにあります。