Unityの光をスプライトとメッシュで比較：Webで逆転した更新時間

鏡を回して灯台へ光を届けるパズル「灯路」をCodexで作りました。描画方式を変える効果を確かめるため、線分スプライトと接続メッシュを同じ盤面で比べました。

結果は単純ではありませんでした。メッシュはWebでの更新処理が遅くなりました。 それでも採用したのは、曲がり角や交差の明るさを揃えられたからです。

線分ごとの加算描画では、接続部分が明るくなる

最初は光路をセル間の辺に分け、各辺へ太い光と細い芯を置きました。セルの中心には小さな光点を足しています。加算合成なので、重なる場所は明るくなります。

実装は扱いやすかったものの、同じ光なのに、つなぎ目だけ粒のように目立つ状態でした。

セル中心を1回だけ描くメッシュを作った

新しい方式では、セル中心の小さな四角を1回だけ描きます。隣のセルへ伸びる長方形は、その四角の境界で止めました。辺と中心の面積が重ならないため、交差にも同じ考え方を使えます。

1. 1

   経路の辺を重複排除する

   同じ2セルをつなぐ辺は、往復しても1本として扱う。
2. 2

   中心と辺の領域を分ける

   辺の両端を半幅ずつ短くし、使用するセルの中心に四角を1つ置く。
3. 3

   太い光と細い芯を別のメッシュにする

   2層の幅・色・透明度を線分方式と揃えて比較する。

終端には半幅ぶんの四角いキャップが付き、旧方式の光点はなくなります。単に同じ絵を少ないオブジェクトで描いた変更ではありません。 接続部分の絵も変えています。

Editorで短くなった更新時間が、Webでは増えた

最終面の同じ配置を、同じカメラと解像度で比較しました。Webでは線分→メッシュ→メッシュ→線分→線分→メッシュの順に実行。各回、新しいブラウザプロファイルで起動し、HTTPキャッシュも無効にしています。

更新処理は30回ウォームアップ後、20回の平均を50組記録しました。Editorは各方式1試行、Webは各3試行の中央値です。Webの描画は表示中の6秒間を計測し、全試行のフレームP95は16.8msでした。

Renderer数だけを見ると大きく減っています。しかし、実際のdraw呼び出しは1回減っただけでした。Webで更新時間が増えた内訳までは切り分けていないため、メッシュの転送だけが原因だとは断定できません。

比較が成立するまでに、3か所直した

接続の見た目を優先し、操作時の小さな負荷を受け入れた

接続メッシュのWeb更新時間は、バッチ平均のP95でも最大0.325msでした。この処理は鏡の操作時にだけ走ります。待機中は光路を再計算せず、1,000回の回転とUndoに対して評価も1,000回であることを確認しています。

今回は「速くなったから」ではなく、光が均一につながる見た目を理由に採用した。

検査では上下左右の接続15通りについて、辺の隙間と面積の重なりを確認しました。ゲーム全体のUnityテストは74件。PCとスマホ幅で、通常設定と音なし・動き少なめの設定の全12面を通しています。

同じ変更でも、Editorの数字だけでWebの結果を予想できませんでした。今後もRenderer数、実際の描画命令、更新時間、画面の見た目を分けて判断するための比較として、この記録を残します。

光路計算から試したい場合は、反射・分岐・循環の作り方とC#サンプルへ進めます。