[Three.js] ベクトルの正規化（Normalize）、なぜわざわざ長さを1にするのか？

Three.jsを勉強していると、ベクトルの後に儀式のように付いている .normalize() をよく目にします。講義では「便利だから」という言葉だけで片付けられがちですが、むしろそれが気になって仕方がありませんでした。

なぜ、まともなベクトルをあえて長さ1にするのか？ いつ必要で、いつは不要なのか？

考えてみると、これは初めて出会う概念ではありませんでした。私は普段 Blender をよく使いますが、スケールを調整した後には必ず Apply Scale をしろと言われてきました。理由はいつも「後で不具合が出るから」でしたが、なぜ 不具合が出るのかを理解しないまま、習慣のように押してきました。

Three.jsの正規化を深掘りしてみると、Blenderでのあの行動が、実は 同じ問題を別の方法で解決していた ことが見えてきました。

正規化（Normalize）を私が理解した方式

正規化とは、ベクトルの 方向は維持したまま、長さだけを1にする作業 です。

• 「どれだけ遠くに行くか」は捨て

• 「どの方向を指しているか」だけを残す

そのため、正規化されたベクトルは通常このように使われます。

• 方向 (Direction)
• 視線 (View)
• 法線 (Normal)
• 移動入力ベクトル

これらには共通点があります。 👉 大きさより「方向」が重要な情報 だという点です。

格子状（Grid）のゲームではなぜ問題にならないのか？

まず、チェスや昔のポケモンのような格子ゲームを思い出してみました。これらの世界は、事実上 連続空間ではありません。

• 左に一マス
• 右に一マス
• 斜めに一マス

斜め移動は数学的に見れば √2 ≈ 1.41 ですが、ゲームのルール上は単なる 「一回の移動」 です。

📌 重要なのは正確な距離の値ではなくルール なので、「斜めの方が速くないか？」といった問題は最初から発生しません。

Three.js / WebGL 空間ではなぜ問題が生じるのか？

Three.jsで扱う空間は全く異なります。

• 座標は (x, y, z)
• 値はすべて実数 (Float)
• 移動は「マス」ではなく 距離計算

ここで正規化を行わないと、問題がすぐに露呈します。

⚠️ 正規化しない斜め移動

入力 W + D → (1, 1)。このベクトルの長さは √2 ≈ 1.41 です。
つまり、同じフレームの間：

• 直線移動 → 1
• 斜め移動 → 1.41

この差は単なる体感速度の問題ではありません。 実際の座標値がより多く移動してしまうのです。

発生する問題：

• 🧱 衝突判定のバグ: 薄い壁やコーナーを斜め移動中に一フレームで突き抜けてしまう現象。
• ⏱ 到着時間の不均衡: 同じ目的地なのに、斜め移動のキャラクターが常に先に到着する（速度の問題ではなく距離の利点）。

だから正規化を使う（自由移動システム）

自由移動のゲームでは、通常このような流れをたどります。

1. 入力を 方向の意図 として解釈（例：(1, 1) = 「斜めに行きたい」）。

👀 見た目には斜めに行きますが、 📐 座標値基準では常に同じ距離だけ移動 します。

Blenderで Apply Scale をしなければならなかった本当の理由

ここで Blender が繋がります。Blenderの 法線ベクトル (Normal Vector) は、ライティング計算で「面の方向」を表します。そして、この法線は 常に長さ1であるという前提 で計算されます。

しかし、スケールを変更して Apply Scale をしないと：

• 内部のベクトル長も一緒に伸びる。
• 法線がもはや「方向だけの値」ではなくなる。

なぜ照明が壊れるのか？（内積計算の観点）

照明計算は通常 内積 (Dot Product) を使います。

正常な場合：

• 面の法線の長さ = 1
• 光の方向の長さ = 1
  → 結果は 0 ~ 1（私たちが期待する明るさ）。

正規化が壊れた場合：

• 面の法線の長さ = 100
• 光の方向の長さ = 50
  → 結果 = 5000

この値は：

• 画面が白飛びしたり、
• 色が異常に跳ねたり、
• シェーディングが壊れたように見せたりします。

👉 Apply Scale は結局、 「これらのベクトルをもう一度長さ1基準に合わせろ」 という意味だったのです。

⚠️ Three.jsでの注意点

.normalize() は 元のベクトルを直接書き換えます。

もし位置や力の大きさを維持する必要があるなら、 必ずコピー（クローン）して使いましょう。

const direction =

Three.js ではいつ使う？

すべての場所に付ける必要はない。
しかし、「方向」という言葉が浮かんだ瞬間、ほぼ間違いなく使用する。

1. カスタム移動ロジック

OrbitControls などを使えば内部で処理されますが、自分で作る場合は：

• 不要な場合: mesh.position.x += 1; (単純な座標移動)。
• 必須な場合: 速度 (velocity) を与える移動。

ここで正規化をしないと、 距離によって速度が変わってしまいます。

2. マウスインタラクション (Raycaster)

Ray は 方向ベクトル です。

raycaster.setFromCamera(mouse, camera);
 

内部では方向ベクトルが正規化されている前提で計算されます。

3. シェーダー / マテリアル

内蔵マテリアルなら自動で処理されますが、以下のような場合は介入が必要です。

• ShaderMaterial を使う時: GLSLでは vec3 lightDir = normalize(lightPos - vPos); が必須です。
• のような状態。

まとめ

正規化は単なる数学的なトリックではありません。

• 移動においては 公平な距離の基準
• 照明においては 明るさの基準
• 方向と大きさを 意図的に分離

.normalize() を使う理由が、これで明確になりました。