奥会津只見 イラスト美術館 このシリーズでは、只見町の駅周辺を題材に、絵はがきを使った WebAR の制作を進めています。制作の途中で考えたことや、試した内容を、Blenderでの3Dモデリングやアニメーション、Web関連の学習記録として残しています。
気長にお楽しみください。
今回のテーマ
今回は、前回に引き続き、これまでに進めてきたモデリング作業の途中経過をまとめます。
- モデリング
– 蒲生岳
– カタクリ
– ひめさゆり
🎈今回までやったこと（モデリング）
🏔️蒲生岳
🏔️現状
手前側は、会津蒲生駅のある蒲生岳の特徴的な岩肌をよく表している部分です。
富士山のように単独で完結する山としてまとめようと、背後の山脈部分を切り落とすところまで作業を進めました。
ただ、実際の蒲生岳は周囲の山並みと連続しているため、地形のつながりを断ち切ったことで、孤立感が強すぎて、かえって蒲生岳らしさが失われてしまった気がします。
WebARで表示する際に、山脈部分をどう残すかを悩んでいるところです。
🏔️ここまでの道のり
山の制作チュートリアル自体は多く見つかるものの、実在する山の形をどう作るかについては、なかなか手探りでした。
結局、等高線データを元に、蒲生岳の形状を再現する方法で進めました。
アドバイスも頂きつつ、頂点を結んでいくことで、少しずつ山らしい形を作っていきます。
このような作り方は、初めて聞いたと言われることもありましたが、言われてみれば、そもそも実際の山を趣味的に作る機会自体が、あまり多くないのかもしれません。
後ろ側（左側）の山脈部分をある程度残した状態で、どこまでを蒲生岳として切り取るかを迷いながら進めているところ。
まだ左側（奥側）の山脈部分を残していた状態。
右側が、会津蒲生駅のある特徴の岩肌の方で、左手奥には、実際には山脈が続いています。
ここに来るまでに、さまざまな試行錯誤がありました。
2次元感覚で操作していたため、まっすぐなはずの線が大きくずれていたり、意図せず多くのゴミ頂点を作ってしまったり、蒲生岳の麓を Z=0 に合わせたいのに数値どおりに移動できなかったりと、後から見返して初めて気づく問題も多くありました。
これらについては、この後の技術メモで紹介します。
失敗の一例：山頂側から（Top View）見ているときはまったく気づかなかったのですが、視点を横（Side View）に切り替えた瞬間、まっすぐなはずの線がこんなにも曲がっていたことを目の当たりにした衝撃の写真。
🌸カタクリ
🌸現状
段々と参考写真のような形に近づいてきました。
カタクリは、花びらが大きく反り返り、中央のおしべ・めしべが前方に突き出るような、独特の形をしています。全体のシルエットとしては、その特徴が少しずつ出てきたところです。
🌸参考にしたチュートリアル動画
🌸ここまでの道のり
花ひとつをとっても、形にはかなりのバリエーションがあり、チュートリアル動画を漁っていると、同じ形の花でも、作り方はいくつもあることを改めて感じます。
今回は、まず一枚の花びらを作り、配列モディファイア（Array） を使って花びらを増やす方法で進めました。
ノードを使った作り方は、いずれ試してみたいです。
配列モディファイア（Array）で花びらを複製した後、エンプティ（Empty）を Object Offset として指定することで、花びらを放射状に配置します。
この作業は、見た目から「花びらが Empty の点を軸に回っている」のだと思っていたのですが、実際には、Empty そのものが回転していて、その動きを Array が参照している仕組みのようです。
「Empty の回転量が Array によって複製ごとに加算され、その結果として花びらが放射状に並んでいく、という挙動になります。（ChatGPT調べ）」
🌸参考にしたチュートリアル動画
当時の参考動画を探し出せず、作ってから見つけた、リンクしておきたい動画２点。
花びらの形ができた段階で、いったん花びらを非表示にし、おしべ・めしべのモデリングを進めました。
花びら・おしべ・めしべの位置を合わせたあと、俯瞰して見ながら、何かが違うと思ったら、上下の向きを取り違えて、実際のカタクリとは逆の向きに💦
当初、写真のように、おしべ・めしべを真っすぐな形で作ってしまっていたので、おしべはカーブを使ってイチから作り直しました。
🌸参考にしたチュートリアル動画
カーブについての解説動画
🌷ひめさゆり
🌷現状
繰り返すようですが、花の形も多種多様なように、Blenderで花を作る方法も多種多様。
花びらを放射状に配置した形を一気に作れることから、「対称的な花のモデリング」の記事を参考に、ひめさゆりの形状は、円錐から作ることにしました。
まだ、モディファイアで滑らかにする前の段階です。
カタクリのときと同様に、ひめさゆりでも花の中心部をいったん直線的な形で作ってしまったため、この部分はカーブを使って作り直す予定です。
🌷ここまでの道のり
円錐（Cone）をベースに作っていくという発想は、自分ではまず思いつかない。
🌷参考にしたチュートリアル動画
🔨技術メモ
数値を入れて標高を下げているのに、期待通りに下がらなかった理由（概要）
蒲生岳のモデルは、等高線に記載された標高をもとに、Blender の Z 軸 = 実際の標高 × 0.002（1/500縮尺）で作成していました。この場合、標高 0m が Blender の Z=0 に対応し、山の麓（川の位置）は標高およそ 350m にあたるため、Blender 上では Z ≒ 0.7 付近に浮いている状態になります。
そこで、地形モデル全体を Z 方向に-350m 相当移動して、Blender 上の地面（Z=0）に、蒲生岳の標高350mの部分を持ってこようと思いました。
計算上は、350m × 0.002 = 0.7となるため、 G → Z → -0.7（数値入力） とすれば、そのまま原点まで下がるはずだと思っていました。
しかし実際には、モデルはほんのわずかしか下がらず、 Z=0 にはまったく届きませんでした。
結論から言うと、この問題は、オブジェクトモードと編集モードの役割の違いを十分に理解しないまま、スケールが正規化されていない状態で作業を進めてしまったことが原因でした。
この技術メモでは、今回の現象を手掛かりに、Blender における作業モードの違い、座標の考え方、スケールの扱いを整理しながら、なぜ数値どおりに動かないように見えたのか、そして、本来どのように操作すべきだったのかを振り返っていきます。
この現象に関係していた Blender の仕組み
今回の問題には、主に次の 4つの Blender の仕組みが関係していました。これらは実際の作業では同時に作用するため、それぞれを自分の中でうまく整理できておらず、結果として原因が分かりにくくなっていました。
- オブジェクトモードと編集モードの役割の違い
- Scale（スケール）と Dimensions（寸法）の違い
- グローバル座標とローカル座標の扱いの違い
- スケールが正規化されていない状態での編集
オブジェクトモード（Object Mode）：写真左 と 編集モード（Edit Mode）：写真右
以下では、これらを 今回のケースに即して 整理します。
📢オブジェクトモードと編集モードの役割の違い
前回の只見線車両のモデリングでも出てきた、Blender の基本となる2つの作業モード が、今回のケースでも関係していました。モデリングを並行して進めていたこともあり、結果として同じような問題を繰り返してしまいました。
ポイントは、オブジェクトモードでスケールを変更しても、画面上の見た目が変わるだけで、実際の形（ジオメトリ）は変わっていないという点です。
- オブジェクトモード
・オブジェクト全体の位置・回転・スケールを扱うモード
・シーン全体の中で、配置や大きさのバランスを調整するために使う
・ 見た目は変わるが、頂点そのものの位置は変わらない
→「どう置くか」「どれくらいの大きさに見せるか」を決めるモード - 編集モード
・頂点・辺・面など、形そのものを編集するモード
・メッシュの実体（ジオメトリ）を作り込むために使う
・頂点を動かすことで、本当の形状が変化する
→「どんな形をしているか」を作るモード
📢Scale（スケール）と Dimensions（寸法）の違い
Blender では、「見た目の倍率」と「実際の形状サイズ」が別々に管理されています。この2つは似ているようで、内部的にはまったく別の概念です。
- Scale（スケール）：オブジェクトモード側の概念（見た目の倍率）
・オブジェクトモードで Sキー による拡大・縮小で変化する
・オブジェクトにかかっている倍率情報
・見た目を変えているだけで、メッシュ（頂点の座標値）には影響しない
・Transform（位置・回転・スケール）の一部として管理される
→「どれくらいの倍率で表示・変換されているか」を表す値 - Dimensions（寸法）：編集モードで作られた形状の結果（実体のサイズ）
・編集モードで 頂点・辺・面を動かすと変化する
・メッシュが占めている 実際の大きさ
・頂点が作る バウンディングボックス（最大範囲） のサイズ
・Transformではなく、現在のメッシュ状態から計算される結果値
→「どれくらいの大きさの形を作ったか」を表す値
📢グローバル座標とローカル座標の違い
ここで、Blender の座標系が関わってきます。「標高を下げて、Z=0 に合わせたい」という目的自体は、シーン全体を基準にしたグローバル座標の話です。
一方で、実際に行っていた操作は、編集モードでの数値入力で、これは常にローカル座標基準で解釈されます。さらに、オブジェクトにスケールや回転が残っている状態では、入力した数値は、その影響を受けた状態で計算されます。
- グローバル座標（World / Global）：シーン全体で共通の座標系
・すべてのオブジェクトが共有する基準
・原点（0,0,0）はワールドの基準点
・Z=0 は、地面や基準の高さとして扱われる
→シーン全体として、どこにあるか - ローカル座標（Local）：各オブジェクトが個別に持つ座標系
・編集モードでの数値入力は常にローカル座標基準
・原点（0,0,0）は そのオブジェクト自身の基準点（原点）
・このオブジェクトの原点からどれだけ離れているか（地面という概念はない）
→そのオブジェクトの中で、どこにあるか
📢スケールが正規化されていない状態での編集
スケールが正規化されていない状態とは、オブジェクトモードで拡大・縮小を行ったあと、Scale を (1,1,1) に戻さないまま編集モードに入っている状態を指します。
この状態では、これまでに整理した下記の要素が同時に作用します。
・オブジェクトモードと編集モードの役割の違い
・Scale と Dimensions の違い
・グローバル座標とローカル座標の扱いの違い
編集モードで入力する数値は、常にローカル座標基準で解釈されます。しかしオブジェクトに Scale（倍率）が残っている場合、そのローカルでの移動量は、スケール倍率を通した結果としてグローバル座標に反映されます。
そのため、数値入力自体は正しく行われていても、ワールド空間で見たときの移動量が直感と一致しない、という状況が発生します。
Scale が残っていて、見た目だけ拡大されている状態（Scale = 11.818）
なぜ「数値どおりに動かない」ように見えたのか（今回のケース）
今回の蒲生岳のモデルでは、オブジェクトモードで拡大された Scale が残ったまま、編集モードで数値移動（G → Z → 数値入力）を行っていました。
編集モードで入力した数値はローカル座標基準で解釈されますが、オブジェクトに Scale が残っている場合、その移動量は倍率変換された結果としてグローバル座標に反映されます。
例えば、Scale = 11.8 の状態で、G → Z → -0.7（数値入力）
・ローカル座標では 0.7m 移動している
・グローバル座標では 0.7 ÷ 11.8 ≒ 0.06m しか動かない
そのため、数値を入れているにもかかわらず、「ほとんど動いていない」「思ったほど下がらない」という感覚が生まれていました。
解決策：今回のケースで正しかった手順
今回のように、数値を入力して正確に位置を合わせたい作業では、スケールの状態を整理してから編集モードで数値操作を行う必要がありました。
具体的には、次の手順が正解でした。
- オブジェクトモードで
Ctrl + A → Scaleを実行する - Scale を (1,1,1) に正規化する
- 編集モードに切り替え
G → Zで数値移動を行う
この手順を踏むことで、下記がすべて一致し、数値どおりに動く状態になります。
- 入力した数値
- 実際の移動量
- 画面上の見た目
Blenderの仕組みに当てはめてみる
この解決策を Blender の内部構造として整理すると、次のようになります。
この結果、数値で動かした分だけ、ちゃんと下がるという直感どおりの挙動になります。
- オブジェクトモードで
Ctrl + A → Scaleを行う
→ ローカル座標とグローバル座標の倍率差を解消する - Scale = 1 の状態で編集モードに入る
→ 編集モードの数値が、そのままワールドに反映される - 編集モードで数値移動を行う
→ ローカル移動量 ＝ グローバル移動量 になる
只見線車両モデルの問題との比較：同じ原因が別の形で現れた
同じ「Scale未正規化」でも、モデルによって現れる症状が変わりました。
只見線車両では形状の歪みとして、蒲生岳では座標・移動量のズレとして表面化しました。
- 只見線車両のモデリング
形状そのものが歪んだ（車輪の縦横比が崩れた）
→ XYZ で不一致な Scale が、そのまま形の歪みとして表面化 - 蒲生岳のモデリング
数値どおりに動かない（移動量が極端に小さい）
→ Scale が倍率として残り、ローカル移動量 ≠ グローバル移動量 になっていた
下の写真は、只見線車両のケースです。左は作業していた時の状態で、見た目上は大きな違和感がありません。
その後、モディファイアなどの作業を進めようとした際に挙動がおかしいことに気づき、XYZ 各軸でスケールが揃っていない状態であることが判明しました。
オブジェクトのスケールを適用（Ctrl + A → Scale：見た目の倍率を形状データに確定）したところ、見た目では分かりにくかった歪みが確定し、車輪の実体が縦方向に引き伸ばされた形で作られていたことが分かりました（写真右）。
写真左：スケール不整合を抱えたまま編集していた状態（見た目では分かりにくい）
写真右：スケールを適用＝内部データを可視化した結果、実体が歪んでいたことが露呈
今回のまとめ
- 数値操作が効かないと感じたら、まず Scale を疑う
- 編集モードで正確な距離を扱いたい場合は → Scale = 1 が前提
- 見た目が合っていても、内部的に正しいとは限らない
補足①：ところで「Median Z = 0.7m」とは何を意味しているのか
Median Z = 0.7mは、編集モードで選択されている頂点群の Z座標の中央値（Median） を示しています。
ここでは、蒲生岳の裾付近のメッシュ（頂点の集まり）を Edit Mode で複数選択していて、その選択範囲のMidian Zが 0.7m と表示されています。
ポイントは、この値が 地形全体の高さ（ワールド座標の絶対位置） ではなく、ローカル座標で見た選択範囲の中央値 だという点です。
Median Z / Vertex Z / ワールドZ（標高換算）の比較（0.7mが何を指すか）
| 項目 | 写真のMedian Z = 0.7m | 写真の Vertex Z = 0.7m | Blender の Z軸 （実標高 × 0.002） |
| 座標系 | ローカル座標 | ローカル座標 | グローバル座標 |
| 基準 | オブジェクトの原点 | オブジェクトの原点 | 地面（Z=0） |
| 種類 | 選択頂点の中央値 | 選択中の1頂点 （または各頂点） | 地形全体の絶対的な高さ |
| 何を表す？ | 選択範囲の“代表値” | その頂点の“現在位置” | 地形をワールドに置く高さ |
| 0.7m の意味 | 選択範囲の中央値が 0.7m | その頂点が Z=0.7m にある | 実標高 約350m 相当 |
補足②：ところで「Vertex Z = 0.7m」とは何を意味しているのか
Vertex Z = 0.7m は、選択中の1頂点（または各頂点）のローカル座標でのZ値です。
Median が、選択範囲の代表値だったのに対し、Vertex は、その点そのものの現在位置を表します。
補足③：スケールと原点が数値移動に与える影響
スケールが正しく正規化されていれば、ローカル座標とグローバル座標の数値感覚は一致します。Scale が (1,1,1) の状態では、編集モードで入力した数値は、ローカル座標・グローバル座標ともに同じ移動量として反映されます。
一方、Scale が残っている場合、編集モードで入力した数値は、ローカル座標基準で解釈され、ワールド座標では拡大・縮小された量として反映されます。
なお、オブジェクト原点の位置がズレていても「移動量」そのものは正しく反映されますが、どこに合わせて移動しているかを判断する基準としては、原点の位置が重要になります。
次回やること
次回は、蒲生岳と列車のモデリングの際にはまった下記の内容について、技術メモの続きを書く予定です。また、作業としては、MindARを少し触っていこうと思います。
- 点から始めるモデリング
- ゴミがたまってしまった原因
おわりに
このシリーズでは、
- 途中の試行錯誤を残すこと
- 完璧を求めて作業を滞らせない
を目的にしています。
