技術メモ 3DモデルのGigaMesh Software Framework展開前に行うMeshLab変換の意義

 Technical Note: The Significance of MeshLab Conversion Before Deploying 3D Models to the GigaMesh Software Framework

3D models (Wabefront (.obj)) must be converted to MeshLab before deploying them in the GigaMesh Software Framework. After four years, I finally understand why this is necessary. ChatGPT explained it to me.

3Dモデル（Wabefront(.obj)）をGigaMesh Software Framework展開する前にMeshLab変換が必要です。なぜ必要なのか、4年経ってようやく理解できました。ChatGPTに教えてもらいました。

1　3DモデルのGigaMesh Software Framework展開方法

2021.09.27記事「GigaMesh Software Frameworkの使い方　その1　6面図の作り方」

2021.09.30記事「GigaMesh Software Frameworkの使い方　その2　展開図の作り方」

MeshLabに3Dモデルを読み込んだ様子

2　3DモデルのGigaMesh Software Framework展開前に行うMeshLab変換の意義

【ChatGPTへの質問】

フォトグラメトリソフト（3DF Zephyr Lite）で3Dモデルを作成し、それをGigaMesh Software Frameworkで展開しています。その際、3Dモデル（Wabefront(.obj)）をMeshLabで変換（MeshLabに3Dモデル読み込み→書き出し）しないとGigaMesh Software Frameworkではテクスチャが貼り付きません。従って必ずMeshLabでWabefront(.obj)を変換します。

このMeshLabによる変換とは何を変換しているのか教えてください。MeshLabによる変換の意義を教えてください。

【ChatGPT回答】

良い質問です。結論から言うと、MeshLabでの「変換」とは、OBJファイルの形式・構造を標準的な形に書き直していることです。これは単なる「形式変換」や「保存し直し」に見えますが、実は以下のような意義があります。

1. OBJファイルの仕様の違いを吸収する

OBJ（Wavefront .obj）は非常に古いフォーマットで、拡張仕様や書き方の揺れがあります。

頂点（v）、法線（vn）、テクスチャ座標（vt）の書き出し順序や有無

マテリアルファイル（.mtl）の参照方法

パス表記（相対パス/絶対パス）

エンコードや改行コードの違い

Zephyr Liteが出力するOBJは、GigaMeshが想定している書式とは一部異なり、そのままではテクスチャ情報が正しく読み込めない場合があります。MeshLabで一度読み込み→書き出しを行うと、MeshLabが内部で解釈し、標準的なOBJ/MTLの形式に整理して出力してくれます。

2. マテリアルとテクスチャのリンクを再構成する

OBJには通常、外部ファイル（.mtl）を参照してマテリアルやテクスチャを読み込みますが、以下の問題が起こりやすいです。

.mtlファイル内のテクスチャパスがZephyr独自の書き方になっている

ファイル名にスペースや特殊文字が含まれている

相対パスが不正確でGigaMeshが見つけられない

MeshLabはこれらを適切に書き直し、パスを正規化します。そのため、GigaMeshで正しくテクスチャが貼り付くようになります。

3. データの整合性を保証する

フォトグラメトリ由来のモデルには、次のような「クセ」が含まれている場合があります。

重複頂点や未使用のテクスチャ座標

異常な法線の記録

サポートされないOBJ要素（グループ指定、smoothing groupなど）

MeshLabで「インポートしてエクスポート」する過程で、余計な情報が整理され、純粋な形状＋マテリアル＋テクスチャのセットに変換されます。

まとめ：MeshLab変換の意義

OBJ/MTLの仕様の揺れを吸収し、標準化する

テクスチャリンクを正しく修正する

不要・不正確なデータを整理して、GigaMeshが読み込めるようにする

つまり、MeshLabは「中継フィルタ」として働き、Zephyr出力 → GigaMesh入力 の間で互換性と安定性を保証する変換をしているのです。

👉 確認ですが、ユーザーさんはMeshLabで「単に読み込み→そのままエクスポート」していますか？ それともエクスポート時に何か特定のオプション（例：法線の再計算、テクスチャを埋め込む、など）を設定していますか？

【あなた:】

MeshLabで「単に読み込み→そのままエクスポート」しています。

【ChatGPT:】

なるほど、ありがとうございます 🙆‍♂️

それならまさに 「MeshLabが内部でOBJ/MTLを標準化し直している」 だけで、ユーザー側の操作は不要という状況ですね。

具体的に何が起こっているか

1. OBJの構造整理

Zephyrが出力したOBJは、OBJの「ゆるい仕様」の範囲で独自の順序や書き方をしていることがあります。

MeshLabが読み込むと、一度内部の統一的なデータ構造に変換されます。

その後、MeshLabからエクスポートすると、一般的な書式に従ったOBJ/MTLファイルとして書き直されます。

2. MTLとテクスチャ参照の修正

Zephyrが書き出したMTLファイルには、テクスチャファイルの参照に「相対パスのずれ」や「特殊な記述」が含まれていることがあります。

MeshLabは読み込み時にそれを解釈し、エクスポート時に単純で標準的な相対パスに書き換えます。

その結果、GigaMeshがテクスチャを正しく見つけて読み込めるようになります。

3. データのクリーンアップ

ZephyrのOBJには、未使用のUV座標・法線・マテリアル参照が残っている場合があります。

MeshLabは不要な情報を整理してからエクスポートするため、余分なデータが除去されたクリーンなOBJ/MTLになります。

●意義まとめ

ユーザーがMeshLabで「ただ読み込んで書き出す」だけでも、

ファイル形式のゆれを吸収

MTL/テクスチャ参照を修正

不要なデータを整理

という処理が裏で行われており、結果としてGigaMeshが問題なくテクスチャを扱えるようになっています。

🔎 ちなみに、もしMeshLabを経由せずに直接GigaMeshで使いたい場合は、ZephyrのOBJエクスポート設定（特に「テクスチャの書き出し方法」や「マテリアルパス」）を調整すれば解決できる可能性もあります。

👉 ご希望があれば、「MeshLabを経由せずZephyr→GigaMeshを直結できる設定」についても調べて整理してみますか？

【あなた:】

MeshLabを経由せずZephyr→GigaMeshを直結できる設定について教えてください。

【ChatGPT:】

お待たせしました！MeshLabを経由せずに 3DF Zephyr Lite → GigaMesh Software Framework へ直接つなげるための設定手順について、以下に整理してご案内します。

1. 3DF Zephyr Lite のエクスポート設定

OBJ/MTL 書式の選択

Zephyr Lite では、「Export Textured Mesh」機能を使い、出力形式として OBJ/MTL を選びます

3Dflow

テクスチャ形式とリスケール

テクスチャの形式としては、PNG や JPG が選択可能です。

高解像度テクスチャが必要な場合は、「Rescale Texture to Nearest Power of Two（最も近い2の冪乗サイズへのリスケール）」をONにしておくと、後工程で非対応になる可能性が減ります

3Dflow

パス指定の注意

古いバージョンでは、単一テクスチャエクスポート時に 絶対パス が出力されてしまうバグがありました。これによりスペースを含むフォルダ名でテクスチャが読み込めないことがあったため、必要に応じて .mtl ファイルを手動修正するケースもあります

Steam Community

2. Zephyr 出力ファイルの内容確認

GigaMesh では OBJ/MTL ファイルから以下が正しく読み込まれることが前提となります:

.mtl ファイルが正しくリンクされているか（mtllib と usemtl 記述）

map_Kd に正しい 相対パス or シンプルファイル名が記述されているか

テクスチャ画像ファイル（例: JPG or PNG）が .obj・.mtl と同じフォルダにあるか

これらは Blender や他のツールでも確認できる一般的なチェック項目です

Blender Stack Exchange

YouTube

SourceForge

3. GigaMesh 側の対応能力と制約

MTL の読み込み対応

GigaMesh は元来 PLY 形式を推奨している側面が強く、OBJ/MTL の取り扱いは限定的である点に注意が必要です

ウィキペディア

テクスチャ読み込みに関するバグ報告

開発側のリリースノートでは、「複数のテクスチャが欠落しているメッシュのインポートが正しく機能しないバグ」が報告されています

gigamesh.eu

これは、MTL に複数のテクスチャ指定（たとえば複数の map_Kd）がある場合、正しく読み込めない可能性を示唆しています。

4. まとめ：直結できるか？条件は？

項目 推奨設定／確認点

出力フォーマット OBJ/MTL（テクスチャ付き）

テクスチャ形式 PNG or JPG。できれば「Nearest Power of Two」にリスケール

パス指定 .mtl は相対パスかファイル名のみ

.obj 内の記述 正しく mtllib と usemtl があるかチェック

GigaMesh 読み込み 複数テクスチャがないシンプルな構成なら比較的安定

実際に直結できるか？

可能性は高いですが保証はできません

上記の通り形式を整え、シンプルな構成にすれば、多くの場合 MeshLab を挟まずに GigaMesh へとデータを渡すことが可能です

ただし、出力時のバグや GigaMesh 側の不具合のため、事前テストが推奨されます

もしよろしければ、実際にエクスポートした OBJ/MTL + テクスチャを GigaMesh に読み込む際に直面したエラーや挙動を教えていただければ、より詳しく原因を調べてアドバイスできます。お気軽にお知らせくださいね！

3　感想

なぜMeshLab変換が必要なのか、GigaMesh Software Frameworkのマニュアルでは理解できず、実務的経験的にだけ必要性がわかっていたのですが、今回ChatGPTに質問してみて、はじめてその意義を理解することができました。

ChatGPTがなければ、この状況を質問できる人やサイトはなく、永遠にわからなかったかもしれません。

技術メモ べジェ曲線を使った単純モデリング

 Technical memo: Simple modeling using Bezier curves

I made a note of the steps to model simple shapes such as pits. Draw the border line with a Bezier curve, and reuse it to create individual unit terrain surfaces using the add-on Curves To Mesh function.

土坑等の単純形をモデリングする際の手順をメモしました。縁取線をべジェ曲線で描き、それを使いまわしながら、アドオンCurves To Mesh機能により単位地形面を個別に造形します。

1　単位地形面を2本のべジェ曲線で造形する

全ての単位地形面を2本のべジェ曲線の間を面張りすることによって表現することにします。面張りの実務はアドオンCurves To Meshにより行うものとします。

べジェ曲線の平面座標は資料平面図から、高さ座標は資料断面図から補間により獲得します。

2025.07.11記事「縄文遺構実測図の縁取線（地形変換線）の高度線形補間Blenderアドオン」

2　縁取線をべジェ曲線で描く

全ての単位地形面の縁取線をべジェ曲線で描きます。

べジェ曲線による縁取線描画結果

作業の順番は、斜面造形を優先して行うことにします。斜面造形がしやすいようにべジェ曲線描画を工夫します。

べジェ曲線の描画単位

土坑を巡る斜面はべジェ曲線abに、段差斜面はべジェ曲線cdに対応します。

3　単位地形面の造形

造形結果

造形結果（単位地形面）

アドオンCurves To Meshにより、斜面1はべジェ曲線abから、斜面2はべジェ曲線cdから直接造形できます。

平坦面3はべジェ曲線bの一部とべジェ曲線cから造形します。

なお、べジェ曲線を使いまわす際、そのコピーはShift+Dで行います。（コピー元とコピー先にリンク関係が生じないようにするため。）

べジェ曲線の分離は編集モードで分離したい部分を指定してからPで行います。

平坦面4の造形はべジェ曲線d、bの一部（2箇所）、eを2本のべジェ曲線に整理してから、造形します。

ここではべジェ曲線bの一部（2箇所）とeを1本に統合しました。

造形結果

4　感想

斜面と平坦面という単位地形面毎に一つ一つ造形する手間をかけないと、結局望むレベルのモデリングができないことを認識しました。

なお、土坑の中の穴については、Blender合成により対応できます。

2025.07.15記事「土坑SK773A/B（千葉市有吉北貝塚）3Dモデル」

技術メモ 点群から1つのオブジェクトを生成する方法

 Technical Note: How to generate an object from a point cloud

I have confirmed five methods to convert the distribution shape of a point cloud (a group of objects) in Blender3D space into a single object.

Blender3D空間における点群（オブジェクト群）の分布形状を1つのオブジェクトに変換生成する方法を5つ確かめました。

1　元データ

元データ

CUBEが分布する例です。

2　凸包

凸包

CUBE分布の殻を生成します。内部構造は見えなくなります。

3　ポイントクラウドの拡大

ポイントクラウドの拡大

内部構造が見えますが、点群ボリュームが連結するまで拡大するので、分布実体より肥大化します。

4　CUBEの拡大

CUBEの拡大

元データを拡大したもので、内部構造が見えますが、分布実体より肥大化します。

5　バウンディングスフェア

バウンディングスフェア

分布形状を内包する最小球です。

6　バウンディングボックス

バウンディングボックス

分布形状を内包する最小直方体です。

7　メモ

バウンディングスフェア以外はBlenderのgeometry nodesで数個のnodeを連結することで生成しています。

geometry nodesで作業することにより、元データに対して非破壊的です。

バウンディングスフェアは専用nodeがないのでPythonで生成しています。

上記以外にもメタボールを使った方法などがあります。

3D空間で遺物密度の分級を行った際、高密度分布域を強調して表現したい場合などに、この技術を利用します。

技術メモ Blenderにおける非破壊ブーリアン適用方法

 Technical note: How to apply non-destructive booleans in Blender

I found out how to apply Blender's boolean functions "non-destructively" using the geometry node editor, so I'll make a note of it.

Blenderのブーリアン機能をジオメトリノードエディターを使って、「非破壊的」に適用できる方法を知りましたので、メモします。

1　ブーリアン機能の非破壊適用

ブーリアン機能の非破壊適用結果（Blender画面）

画面では円柱と球が重なった部分をブーリアンモディファイア（交差）で抽出しています。ジオメトリノードエディターでオブジェクト情報、ジオメトリトランスフォーム、メッシュブーリアン、グループ出力の各ノードを繋いで実現しています。円柱と球は非破壊です。手作業でブーリアンモディファイアを適用すると円柱と球は破壊されます。

2　感想

非破壊的にブーリアン機能を適用できる技術があることを知り、今後大いに役立ちそうです。

またシェーダーエディターとは別にジオメトリノードエディターの存在を強く意識させられました。とても便利なツールです。Blender世界の奥深さを実感します。

現在有吉北貝塚北斜面貝層の貝層3Dモデル作成に向けてどのような技術を適用できるか、検討中です。

技術メモ JavaScriptでIllustratorを操作する

 Technical memo: Controlling Illustrator with JavaScript

I created a JavaScript that generates a B2-sized document in Illustrator and draws a grid. This is my first time using JavaScript, and it's very useful. I also learned that templates are even more useful as a next step.

立ち上げたIllustratorにB2判ドキュメントを生成し、グリッドを描画するJavaScriptを作成しました。JavaScriptの利用ははじめてで、とても便利です。また、次のステップとしてテンプレートがさらに便利であることを知りました。

1　B2判ドキュメントを生成しグリッドを描画するJavaScript

次の仕様のJavaScriptをChatGPT支援により作成しました。

1　ドキュメントを生成して、B2判アートボードを設定してアクティブにする。

2　横650ｍｍ、縦450ｍｍの四角をアートボード中心に描く。

3　線幅は0.25pxとする。

4　四角を行9、列13のグリッドに分割する。

5　全てのグリッドをグループにまとめる。

6　カラーモードをRGBモードに設定する。

7　線の色は#0a009dとする。塗りはしない。

// ptをmmに変換する係数
var ptToMm = 2.83464567;

// 新規ドキュメントの作成と設定
if (app.documents.length === 0) {
    var doc = app.documents.add(DocumentColorSpace.RGB);
} else {
    var doc = app.activeDocument;
}

// B2アートボードの設定（B2: 728mm x 515mm）
var artboardWidthMm = 728; // mm
var artboardHeightMm = 515; // mm
var artboardWidthPt = artboardWidthMm * ptToMm; // ptに変換
var artboardHeightPt = artboardHeightMm * ptToMm; // ptに変換

doc.artboards[0].artboardRect = [
    0,                  // 左
    artboardHeightPt,   // 上
    artboardWidthPt,    // 右
    0                   // 下
];

// アートボードの中心座標
var centerX = artboardWidthPt / 2;
var centerY = artboardHeightPt / 2;

// 四角形を描画
var rectWidthMm = 650; // mm
var rectHeightMm = 450; // mm
var rectWidthPt = rectWidthMm * ptToMm; // ptに変換
var rectHeightPt = rectHeightMm * ptToMm; // ptに変換

var rect = doc.pathItems.rectangle(
    centerY + rectHeightPt / 2, // 四角の上
    centerX - rectWidthPt / 2,  // 四角の左
    rectWidthPt,                // 四角の幅
    rectHeightPt                // 四角の高さ
);
rect.stroked = true;
rect.strokeWidth = 0.25; // 線幅を0.25px
rect.strokeColor = new RGBColor();
rect.strokeColor.red = 10;
rect.strokeColor.green = 0;
rect.strokeColor.blue = 157;
rect.filled = false; // 塗りなし

// 四角形をグリッドに分割
var rows = 9; // 行
var columns = 13; // 列
var gridGroup = doc.groupItems.add();
for (var i = 0; i < rows; i++) {
    for (var j = 0; j < columns; j++) {
        var cellWidthPt = rectWidthPt / columns;
        var cellHeightPt = rectHeightPt / rows;
        var cell = gridGroup.pathItems.rectangle(
            rect.top - (cellHeightPt * i),       // セルの上
            rect.left + (cellWidthPt * j),       // セルの左
            cellWidthPt,                         // セルの幅
            cellHeightPt                         // セルの高さ
        );
        cell.stroked = true;
        cell.strokeWidth = 0.25;
        cell.strokeColor = rect.strokeColor;
        cell.filled = false;
    }
}

// グリッド全体をグループ化
gridGroup.move(doc.activeLayer, ElementPlacement.PLACEATEND);

// RGBカラーモードを設定
doc.documentColorSpace = DocumentColorSpace.RGB;

alert("スクリプトの実行が完了しました！（単位はmm対応）");

2　JavaScriptにより生成したドキュメント

JavaScriptにより生成したドキュメント（Illustrator画面）

JavaScriptにより生成したドキュメントの利用（Illustrator画面）

このドキュメントは有吉北貝塚北斜面貝層のセクション図を集成して1枚の貝層断面図にまとめるための「台紙」として使う目的で作成したものです。JavaScriptの変数を調整すれば、アートボードサイズやグリッド設定や線色を変更できますから、便利です。JavaScriptは規定の場所に置いて使っています。

3　テンプレート

セクション図集成作業ではグリッド番号や標高を記入する必要があるので、それらの数値例や時々必要となるゲージ（目盛）をアートボード内外に置いてあるファイルをテンプレートファイルとして作成し、活用しています。

テンプレート画面（Illustrator画面）

4　感想

JavaScriptの利用がとても便利であることをはじめて知りました。さらにそれ以上にテンプレート利用が便利であること知りました。テンプレートファイルは規定の場所に置くことは手間がかかるようなので、作業フォルダーに置いて使っています。

技術メモ 同一写真の複数回投入による3Dモデル改善効果

 Technical memo: 3D model improvement effect of multiple inputs of the same photo

I investigated the reason why multiple inputs of the same photo improve 3D models. It seems that "emphasis by reusing feature points" and "noise reduction by adding redundant data" are possible reasons. It seems to be a "good (?)" characteristic of the software, not a bug.

同一写真の複数回投入による3Dモデル改善効果の理由を調べてみました。「特徴点の再利用による強調」や「冗長データの追加によるノイズ低減」が考えられるようです。ソフトのバグではなく、ソフトの「良き（？）」特性のようです。

1　ChatGPT質問

フォトグラメトリソフト3DF Zephyrに3枚の空中写真を投入して、垂直写真仕様で地形3Dモデルを作成しました。平坦面が大きく波打った3Dモデルとなり、現実離れしたものになりました。

次に3枚の写真の複製を含めて6枚の写真で地形3Dモデルを作成しました。大きく改善され、見かけ上は通常の地形に見えるようになりました。

他の事例でも、同じ写真を2枚投入すると3Dモデル造形とテクスチャが改善されます。

この改善の理由について、考えられる要因を教えてください。

2　ChatGPT回答

同じ写真を複数回投入したことで3Dモデルの造形やテクスチャが改善された理由として、いくつかの要因が考えられます。以下にその理由を説明します。

2-1 特徴点の再利用による強調

フォトグラメトリでは、入力された写真から共通する特徴点を抽出して3Dモデルを構築します。同じ写真を複数回投入することで、ソフトウェアが同じ特徴点を何度も認識し、その位置情報が強調されます。この結果、特徴点のマッチング精度が向上し、平坦な地形の波打ちなどの誤差が軽減される可能性があります。

2-2 冗長データの追加によるノイズ低減

同じ写真が複数回投入されると、冗長なデータが増えます。この冗長性が、ノイズや計算誤差を統計的に平滑化する効果を生むことがあります。これにより、より滑らかで現実的な3Dモデルが生成される可能性があります。

2-3 アルゴリズムの内部補正効果

3DF Zephyrなどのフォトグラメトリソフトウェアでは、入力データが不足する場合や配置が不均一な場合、モデルに誤差が生じやすくなります。同じ写真を複数回投入することで、ソフトウェアのアルゴリズムが「補完」として認識し、元のデータの不足を補う動きをする場合があります。

2-4 テクスチャのリファイン効果

テクスチャマッピングでは、複数の写真から同じ領域を参照することで高品質なテクスチャが生成されます。同じ写真が複数回使用されることで、テクスチャ情報が「再評価」され、結果としてモデルの見た目が改善される可能性があります。

2-5 カメラパラメータの調整精度向上

カメラの内部パラメータ（焦点距離、歪み係数など）や外部パラメータ（位置や角度）の推定は、写真間の対応点に基づいています。同じ写真を追加することで、これらの推定が安定し、全体の精度が向上する場合があります。

2-6 平坦面の処理における情報補完

平坦な地形では特徴点が少ないため、モデルが波打つような誤差が生じやすいです。同じ写真を追加すると、平坦面の情報が補完され、これが改善につながることがあります。

2-7 注意点

この現象が起きるのは、フォトグラメトリソフトウェアのアルゴリズムや入力データの特性に依存します。3Dモデルの精度を向上させるには、以下の方法も検討できます：

・より多角度から撮影した写真を追加する。

・解像度の高い写真を使用する。

・特徴点が豊富に含まれる領域を撮影する。

・同じ写真を複数投入するのは改善効果がある場合もありますが、本来の最適な方法とは言えないため、データ収集や撮影方法を見直すことが推奨されます。

3　感想

同一写真の複数回投入による3Dモデル改善効果の理由をChatGPTで調べてみました。「特徴点の再利用による強調」や「冗長データの追加によるノイズ低減」が考えられるようです。ソフトのバグではなく、ソフトの「良き（？）」特性のようです。

3Dモデル造形が部分的に破綻したり、やテクスチャが部分的に乱れた時、正常な写真を複数回投入して、それを改善することが「手法」としてあることを知りました。人形塚古墳3枚写真による3Dモデル作成はとてもラッキーな体験となりました。

同一写真の複数回投入による3Dモデル改善効果の理由を、web検索で即時に調べることは、自分の現状知識や気力ではほとんど不可能です。しかし、ChatGPTならそれがいとも簡単にできました。ChatGPTの内部化を意識して進めることにします。

同一写真複数回投入による3Dモデル改善効果

技術メモ 少枚数写真から3Dモデルをつくる際の姑息で有効な方法

 Technical memo: A tricky but effective way to create a 3D model from a small number of photos

It would be very meaningful if a few photos of a lost feature remained and a 3D model could be made from them. In such a situation, I discovered a tricky but effective method, so I made a note of it.

失われた地物の写真が数枚残存していて、それから3Dモデルができれば、とても意義のあることです。そのような状況で、姑息で有効な方法を発見したのでメモしました。

フォトグラメトリで3Dモデルをつくる場合、できるだけ多数写真を四周から撮影することが基本となります。しかし、既に失われた地物について、3Dモデルをつくりたいことがあります。そんな場合、過去撮影写真がたまたま数枚ある場合、3Dモデルができる可能性があります。数枚の写真から、もし3Dモデルができれば、それはとても意義のあることです。そのような状況で3Dモデルを作成して、姑息でしかし有効な方法を見つけましたので、メモしておきます。

1　人形塚古墳発掘時空中写真3枚から作成した3Dモデル

1-1　使用写真

人形塚古墳発掘時空中写真3枚

千葉県教育委員会所蔵（申請により使用許可済）

1-2　勘違いで3枚写真と内1枚を重複して合計4枚写真を使用した3Dモデル

勘違いで3枚写真と内1枚を重複して合計4枚写真を使用した3Dモデル（画像）

フォトグラメトリソフト3DF Zephyr Liteにより4枚写真による通常操作（垂直写真仕様）で生成した3Dモデル

造形破綻（極端な突起など）がありますが、全体では何かそれなりの3Dモデルになっています。

1-3　3枚写真使用による3Dモデル

フォトグラメトリソフト3DF Zephyr Liteにより3枚写真による通常操作（垂直写真仕様）で生成した3Dモデル（画像）

勘違いを修正して、3枚だけの写真で3Dモデルをつくりました。極端な造形破綻があり、とても人前に示せるレベルではありません。

この結果から、勘違いで生まれた重複写真が3Dモデル造形で効果ありと感じました。そこで、次に3枚写真全部を重複させて6枚写真でのフォトグラメトリを試してみました。

1-4　3枚写真と重複3枚合計6枚使用による3Dモデル

フォトグラメトリソフト3DF Zephyr Liteにより6枚写真による通常操作（垂直写真仕様）で生成した3Dモデル（画像）

極端な造形破綻が無くなっています。見かけは地物の立体性を矛盾なく観察できます。撮影写真を増やすのではなく、同じ写真を重複利用することによってフォトグラメトリ造形機能を強化できることが判明しました。

自分にとっての私的小発見です。おそらく低密度点群作成時のランダム性に起因して、ソフトが別写真だと誤判断しているのだと思います。厳密に言えば一種のバグかもしれません。しかしバグかどうかの議論はさておき、何はともあれ、3枚の写真から、造形破綻が感じられない3Dモデルが出来たことは大いに喜ぶべきことです。38年前撮影で残された貴重な3枚の写真から3Dモデルができたのですから。

2　メモ

2-1　他事例による効果検証

他事例数件で、写真重複を行ったところ全てで3Dモデル造形改善が見られました。造形が乱れた3Dモデルでは写真を複製して増やすと必ず一定の効果が見られます。偶然から発見した、姑息ではありますが、貴重なノウハウになります。

2-2　小枚数写真による3Dモデルの意義

数枚とか十数枚の写真が残存する事例の場合、3Dモデルができれば、大いに意義があります。地割線空中写真の場合11枚の空中写真から、この方法により複製11枚を加えて22枚の空中写真に水増しして、とても立派な3Dモデルを造形することができました。

今回の3枚の空中写真から作成した3Dモデルはさすがに精度が悪いです。眺める程度にしか使えません。この場合は、等高線地図が存在していたので、等高線から3Dモデルを作成し、発掘時空中写真をテクスチャとして被せて、分析的3Dモデルを作成しました。

2024.11.24記事「千葉市人形塚古墳　発掘時形状3Dモデル」

技術メモ 等高線の3Dモデル

 Technical memo: 3D contour model

It seems that contour shape files created with QGIS cannot be made into contour 3D models in QGIS.

So I checked how to import contour shape files into BlenderGIS and make them into 3D models. I decided to enjoy looking at contour 3D models of problematic terrains such as archaeological phenomena.

QGISで作成した等高線shapeファイルは、QGISでは等高線3Dモデルにできないようです。

そこで、等高線shapeファイルをBlenderGISにインポートして、3Dモデルにする方法を確認しました。考古事象などで問題意識のある地形について、等高線3Dモデルを眺めて楽しむことにします。

1　等高線の3Dモデル

等高線の3Dモデル by arakiminoru on Sketchfab

等高線の3Dモデル

作成方法：QGISで等高線shapeファイル作成→BlenderGISでオブジェクトファイルに整形してエクスポート

垂直比率：×1.0

3DF Zephyr v7.531でアップロード

等高線の3Dモデル画像

等高線の3Dモデル動画

2　作成方法メモ

2-1　QGISで等高線shapeファイル作成

・QGISで等高線をトレース、標高付与してshapeファイルで保存する。

2-2　BlenderGISへインポート

・等高線shapeファイルをBlenderGIS（アドオンBlenderGISが有効となっているBlender）にインポートする。その際、標高がフィールドのどの項目であるか設定する。同時にCRSを設定する。この例ではEPSG:6677-JGD2011 / Japan Plane Rectangular CS IX。（クエリーにEPSG:6677を入力すると、JGD2011 / Japan Plane Rectangular CS IXが応答してくる。）

2-3　オブジェクトファイルにするための整形作業

・取り込んだオブジェクト（メッシュ）をカーブに変換して、ベベル機能でチューブ状に整形し、さらにメッシュに変換する。

・メッシュにマテリアルを貼り付ける。

2-4　オブジェクトファイルのエクスポート

・整形したメッシュをWabefront(.obj)ファイルなどでエクスポートする。

3　メモ

QGISで作成した等高線shapeファイルを3Dモデルにして眺めたい（利用したい）のですが、QGISでは等高線3Dモデルを作成することはできないようです。（もしできるようでしたら、どなたか教えてください。）

そこで、等高線shapeファイルをBlenderGISに取り込み、3Dモデルにする方法を確認しました。考古事象などで問題意識のある地形について、等高線3Dモデルを眺めて楽しむことにします。

4　参考　QGISで作成したDEM、テクスチャのBlenderGISインポート

（紙等高線地図からv.surf.rstツールを活用して）QGISで作成したDEM、テクスチャもBlenderGISに取り込み、テクスチャが貼り付いた地形3Dモデルを作成することができます。

従って、QGISのQgis2threejsで3Dモデルを作成しなくても、DEMとテクスチャをQGISからエクスポートすれば、BlenderGISで3Dモデル作成ができます。Qgis2threejsで作成した3Dモデル（gltf）は必ず不必要な余白が含まれてしまい、扱いにくいので、BlenderGISで3Dモデルにした方が作業が効率的です。

5　関連記事

2024.09.14記事「千葉市人形塚古墳付近の開発前地形3Dモデル」

2024.09.15記事「紙等高線地図から地形3Dモデルを作成する方法」

技術メモ：postgreSQLによるテーブル結合 遺物台帳テーブルと土錘テーブル

 Technical memo: Table join with PostgreSQL: Relic ledger table and soil weight table

I analyzed the correspondence between the relic ledger and soil weight list of the shell layer on the north slope of the Ariyoshi Kita Shell Mound using a table join with PostgreSQL. This was my first data analysis with PostgreSQL. I realized that the relic ledger names are nothing more than collection bag labels.

有吉北貝塚北斜面貝層の遺物台帳と土錘リストを対象に、postgreSQLによるテーブル結合でその対応関係を分析しました。自分にとって、postgreSQLによるはじめてのデータ分析です。遺物台帳名称が採集袋ラベルに過ぎないことがよくわかりました。

1　postgreSQLによる遺物台帳テーブルと土錘テーブルの結合

1-1　遺物台帳テーブル

現在（2024.07.30）の遺物台帳テーブルの項目（カラム）は次の通りです。データ数は64097です。

（わかりやすくするために日本語で表記しています。データベースでは英字略記で表記しています。）

・グリッド（文字表記）

・遺物番号（グリッド内の通し番号）

・遺物コード（グリッド-遺物番号の文字連続表記）

・グリッドコード2（数値表記）

・遺物コード2（数値表記）

・名称（文字表記）

・標高（小数点表記）

・貝層（文字表記）

・注記（文字表記）

・はみ出し移動前（文字表記）

・はみ出し移動後（文字表記）

・移動コード（数値表記）

・遺物分類コード（数値表記）

1-2　土錘テーブル

土錘テーブルの項目は次の通りです。データ数は960です。

・遺物コード2（数値表記）

・土錘数（数値表記）

発掘調査報告書掲載土錘リストは個別土錘リスト（1090）です。このリストから遺物コード2で土錘数を集計した資料がこの土錘テーブルです。

1-3　postgreSQLによる遺物台帳テーブルと土錘テーブルの内部結合

postgreSQLのクエリで遺物台帳テーブルと土錘テーブルの内部結合主キー「遺物コード2」で行い、「遺物台帳対応土錘テーブル」を派生させました。

●「遺物台帳対応土錘テーブル」

・遺物コード2（数値表記）

・名称（文字表記）

・土錘数（数値表記）

pgAdmin4画面（テーブル結合の様子）

pgAdmin4はpostgreSQLのGUIです。

2　派生テーブル「遺物台帳対応土錘テーブル」の検討

2-1　データ数の減少

土錘テーブルのデータ数は960でしたが、テーブル結合した後の「遺物台帳対応土錘テーブル」のデータ数は940に減少しました。

このデータ減少を詳しく検討したところ、次の要因によるものであることがわかりました。

1　土錘テーブル（発掘調査報告書土錘リスト由来データ）の遺物コード2には、出土グリッドは判明しているが、遺物番号が無いものがあり、それに遺物コード2仮番を付けていたものがあるため。（8件）

2　発掘調査報告書土錘リストから生成される遺物コードに実在しないものが含まれているため（おそらく錯誤による作業ミス）。（12件）

結果として、土錘テーブル（全960件）のうち940件（97.92％）が遺物台帳との対応で使えることがわかりました。

2-2　土錘と遺物台帳名称との対応

土錘と遺物台帳名称との対応の概要は次のようになりました。

土錘（現物）がリンクしている遺物台帳名称

現場で土錘として取り上げられた件数（遺物番号の数）は437件で46.5％、土器として取り上げられたものが471件で50.1％、その他の名称で取り上げられたもの32件で3.4％ということになります。

土器として取り上げられたものとは、ほとんどの場合土器片多数を一括で取り上げ、1つの遺物番号をつけた採集袋の中にいれられた状況があり、後日その採集袋の土器片を分析するなかで土錘も見つかったと考えることができます。

石器、骨、貝、鱗、貝サンプルも同じく、それらの名称に該当する品が納められた採集袋の中から、後日土錘が見つかったという状況が考えられます。

2-3　標高データのあるものは64.4％

遺物台帳では「〇〇一括」と書かれたものは標高データがありません。その件数を「遺物台帳対応土錘テーブル」で集計すると335件となります。従って940-335＝605件が標高のあるデータで、全体の64.4％に該当します。標高データのあるものは、今後遺物分布図から平面座標を取得できますから、精細な3Dモデル座標も取得できます。

3　メモ

postgreSQLによる遺物台帳テーブルと土錘テーブルの内部結合により派生した「遺物台帳対応土錘テーブル」の分析から、遺物台帳の性格がよくわかりました。遺物台帳名称はあくまでも採集袋のラベルであり、採集袋の中にはラベルとは異なる遺物も一緒に納められいる場合がかなりあるということです。この状況を理解できたことで、今後の分析活動に柔軟性が求められることが判明しました。

4　感想

postgreSQLによる北斜面貝層遺物データベース作成活用がいよいよ本格化しました。現状ではヨチヨチ歩きですがどんな活動でも幼少期通過は必要であり、我慢して実務作業を継続することにします。さいわいなことに、postgreSQLによるデータ分析の不足分はPythonによる分析で穴埋めできています。

今後、postgreSQLのクエリ記述でChatGPT支援を受けて、データ分析の高度化を図りたいとおもいます。

なお、Pythonスクリプト作成、BlenderPythonスクリプト作成ではChatGPT支援を日常的に受けています。postgreSQL、Python、Blenderなどの連携活動がChatGPT支援で自由にできると感じるので、楽しい状況になっています。

技術メモ 遺物台帳データと発掘調査報告書掲載データ

 Technical memo: Relic ledger data and excavation report data

I compared the relic ledger data and excavation report data using the clay weights from the shell layer on the north slope of the Ariyoshi Kita shell mound as an example.

有吉北貝塚北斜面貝層の土錘を例に遺物台帳データと発掘調査報告書掲載データを比較してみました。遺物台帳データは現場で遺物を取り上げた際の情報で、遺物を吟味した結果の情報が発掘調査報告書掲載データです。発掘活動のイキイキとした様子が伝わってきます。

1　遺物台帳データと発掘調査報告書掲載データ

遺物台帳データと発掘調査報告書掲載データ by arakiminoru on Sketchfab

遺物台帳データと発掘調査報告書掲載データ

有吉北貝塚北斜面貝層　グリッド別土錘出土数

遺物台帳データ（現場で遺物を取り上げた際の情報）

発掘調査報告書掲載データ（遺物を吟味した結果の情報）

3DF Zephyr v7.531でアップロード

3Dモデルの画像

3Dモデルの動画

2　メモ

2-1　データ比較

遺物台帳データ…土錘出土件数736、出土グリッド数91

発掘調査報告書掲載データ…土錘出土数1090個、出土グリッド数108

遺物台帳データは現場で土錘と認識されて取り上げられた件数です。一方、出土土器や土製品を全て観察して、土錘として認識されたものは1090個になります。現場で土錘と認識されたものより354増えています。

現場で遺物を取り出す様子、取り出した膨大な遺物を吟味調査してリストにする様子が遺物台帳データと発掘調査報告書掲載データの違いから伝わってきます。発掘活動のイキイキとした様子が伝わってきます。

なお、発掘時に遺物台帳データに記載された種別（名称）は遺物吟味で後日変化しても遡って訂正はされないとのことです。遺物番号は最後まで継承されます。

2-2　遺物台帳データ補正

発掘調査報告書掲載データには出土グリッド、遺物番号が記載されています。従って、発掘調査報告書掲載データを正として遺物台帳データを補正することが可能です。

遺物台帳データの補正は遺物台帳データを「訂正」するのではなく、遺物台帳データと発掘調査報告書掲載データから新しい遺物データベースを生成することにより実現します。SQL活用で実現する予定です。

2-3　データレベル

遺物を扱うデータレベルが現時点で3つあります。それぞれのデータ整備を行うつもりです。

1　個別遺物レベル

発掘調査報告書掲載土錘データがこれにあたります。発掘調査報告書では土錘の短軸と長軸の長さ、重量、部位、欠損有無が記載されていて、統計的解析が可能です。個別遺物データレベルは次の遺物台帳番号データレベルより優先して扱います。

2　遺物台帳番号レベル

遺物台帳番号は遺物1点の場合もあれば、遺物複数の場合もあります。同じ種別の遺物を一括して取り上げて1つの番号にしたものがかなりあります。この遺物台帳番号に対応して遺物分布図がつくられていて、出土3D座標がわかるのは遺物台帳番号レベルになります。従って、遺物台帳番号データレベルが今後検討の基本になります。

3　平面グリッド別レベル

遺物データを平面グリッド別に集計整理して分布図等で示すことによって、北斜面貝層の概要を知ることができます。平面グリッド別データレベルは概要把握のために活用します。立体グリッド（2ｍ×2ｍ×2ｍ）別データ整理についても、それがより的確に北斜面貝層概要を示すものならば、採用することにします。

技術メモ 異なる指標の分布を比較する一つの方法

 Technical memo: A method to compare the distribution of different indicators

I tried a method to compare the distribution characteristics of the number of pottery and earthen weights excavated by grid in the shell layer on the north slope of the Ariyoshi Kita Shell Mound.

By comparing the pottery distribution and the earthen weight distribution, I was able to extract grids where the pottery distribution was weak and the earthen weight distribution was strong. This will be a hint for considering the difference in the principles of pottery dumping and earthen weight dumping.

有吉北貝塚北斜面貝層の土器と土錘のグリッド別出土数分布特性を比較する一つの方法を試してみました。

土器分布と土錘分布をくらべて土器分布が弱く、土錘分布が強いグリッドを抽出することができました。土器投棄と土錘投棄の原理の違いを考えるヒント材料になります。

1　有吉北貝塚北斜面貝層　グリッド別土器出土数（標準化表示）

有吉北貝塚北斜面貝層 グリッド別土器出土数（標準化表示） by arakiminoru on Sketchfab

有吉北貝塚北斜面貝層　グリッド別土器出土数（標準化表示）

グリッド別土器出土数を平均値で除した指数1を2ｍの棒で表示

3DF Zephyr v7.531でアップロード

3Dモデル画像

この3D棒グラフはグリッド別土器出土数分布を標準化表示したものです。

2　有吉北貝塚北斜面貝層　グリッド別土錘出土数（標準化表示）

有吉北貝塚北斜面貝層 グリッド別土錘出土数（標準化表示） by arakiminoru on Sketchfab

有吉北貝塚北斜面貝層　グリッド別土錘出土数（標準化表示）

グリッド別土錘出土数を平均値で除した指数1を2ｍの棒で表示

3DF Zephyr v7.531でアップロード

3Dモデル画像

この3D棒グラフはグリッド別土錘出土数分布を標準化表示したものです。

3　有吉北貝塚北斜面貝層    土器分布と土錘分布を比較する資料

有吉北貝塚北斜面貝層 土器分布と土錘分布を比較する資料 by arakiminoru on Sketchfab

有吉北貝塚北斜面貝層    土器分布と土錘分布を比較する資料

土器と土錘の分布特性指標の差を色分けしている

赤色は土器分布特性指標が優越するグリッド

黄色は土錘分布特性指標が優越するグリッド

※分布特性指標＝グリッド出土数をグリッド平均値で割って得た数値

3DF Zephyr v7.531でアップロード

3Dモデル画像

土器出土数は土錘出土数の27倍近くあるので、実数として両者を比較するのは困難です。しかし、1と2の3D棒グラフは標準化してあるので、比較可能になっています。

3のグラフは標準化指数の差を表現していて、赤色は土器分布と土錘分布をくらべて土器分布が強く、土錘分布が弱いグリッドを、黄色は逆に土器分布が弱く、土錘分布が強いグリッドを抽出しています。

指数の差の値に厳密な意味を求めることは困難ですが、グラフは土器分布と土錘分布の関連を考察する時の一つの材料になると考えます。

4　考察

大局的観察では土器集中分布域と土錘集中分布域が異なります。

この分布の違いを3の方法（標準化指数の差）で比較分析すると土器と土錘の双方の分布の関連を考察できる新しい情報を得ることができます。

土器分布と土錘分布を比較する資料

技術メモ 有吉北貝塚北斜面貝層 3D棒グラフ表現の標準化

 Technical memo: Standardization of 3D bar graph representation for shell layers on the north slope of the Ariyoshi Kita shell mound

I often use 3D bar graphs to represent the data of the shell layers on the north slope of the Ariyoshi Kita shell mound. In this case, in order to make it easier to compare the distribution of indicator data with different characteristics, I decided to standardize the representation by making the length of the 3D bar of the data average constant.

有吉北貝塚北斜面貝層のデータを3D棒グラフで表現することを多用しています。この場合、性格の異なる指標データの分布比較をわかりやすくするために、データ平均値の3D棒の長さを一定にして、表現を標準化することにしました。

1　3D棒グラフ表現の標準化検討

現在、有吉北貝塚北斜面貝層のグリッド別各種データを3D棒グラフで表現しています。その際、単位の異なるデータの分布比較をするためには3D棒の長さをある程度同じにする必要があります。つまり、表現を標準化する必要があります。そのため、グリッド別データの平均値の3D棒の長さを一定にすることによって、この標準化を実現することにします。

2　グリッド別データ平均値の見やすい3D棒の長さの検討

2-1　テスト表示　グリッド平均値を1ｍの3D棒で表現

テスト表示 グリッド平均値を1ｍの3D棒で表現 by arakiminoru on Sketchfab

テスト表示　グリッド平均値を1ｍの3D棒で表現

有吉北貝塚北斜面貝層　グリッド別朱塗土器出土件数

3DF Zephyr v7.531でアップロード

3Dモデル画像

2-2　テスト表示　グリッド平均値を2ｍの3D棒で表現

テスト表示 グリッド平均値を2ｍの3D棒で表現 by arakiminoru on Sketchfab

テスト表示　グリッド平均値を2ｍの3D棒で表現

有吉北貝塚北斜面貝層　グリッド別朱塗土器出土件数

3DF Zephyr v7.531でアップロード

3Dモデル画像

2-3　テスト表示　グリッド平均値を4ｍの3D棒で表現

テスト表示 グリッド平均値を4ｍの3D棒で表現 by arakiminoru on Sketchfab

テスト表示　グリッド平均値を4ｍの3D棒で表現

有吉北貝塚北斜面貝層　グリッド別朱塗土器出土件数

3DF Zephyr v7.531でアップロード

3Dモデル画像

2-4　検討1

この例の場合、グリッド平均値を2ｍの3D棒で表現すると分布の様相が把握しやすく見やすいことがわかりました。

グリッド平均値を1ｍの3D棒で表現すると全体が平べったい形状になり、分布の凸凹を把握することが苦痛です。一方4ｍにすると分布の凸凹が極端になり、これも分布全体像を知りにくくなります。

次に、別指標でグリッド平均値を2ｍの3D棒で表現するとどうなるか、比較してみました。

2-5　別指標　テスト表示　グリッド平均値を2ｍの3D棒で表現

別指標 テスト表示 グリッド平均値を2ｍの3D棒で表現 by arakiminoru on Sketchfab

別指標　テスト表示　グリッド平均値を2ｍの3D棒で表現

有吉北貝塚北斜面貝層　グリッド別朱塗土器件数率

3DF Zephyr v7.531でアップロード

3Dモデル画像

2-6　検討2

別指標でもグリッド平均値を2ｍの3D棒で表現すると見やすいです。性格の異なる指標の分布を比較する場合、グリッド平均値を2ｍの3D棒で表現して標準化すると、データ分析に有利であることを確認できました。今後の作業はこの標準化を踏まえて進めることにします。

技術メモ 遺物台帳電子化データの効率的分類作業

 Technical memo: Efficient classification of digitized artifact ledger data

I am working on classifying the digitized Ariyoshi Kita Kaizuka north slope shell layer artifact ledger.

I have achieved the task of "matching" and classifying the name column of the artifact ledger using a Python script, and automatically writing the classification code using a Python script. I have achieved the task of "leaving the tedious work to Python."

電子化した有吉北貝塚北斜面貝層遺物台帳の分類作業に取組んでいます。

遺物台帳の名称欄をPythonスクリプトで「名寄せ」して分類し、その分類コードをPythonスクリプトで自動で書き込む作業が実現しました。「面倒な作業はPythonに任せる」が実現しました。

1　遺物台帳名称欄を「名寄せ」するPythonスクリプト

有吉北貝塚北斜面貝層の遺物台帳にうち、土器・土製品に関するデータは20923件あります。この土器・土製品に関するデータを分類するために、遺物台帳名称欄の文字記述を名寄せして分類しました。

遺物台帳名称欄（データ総計20923件）

名寄せした結果（データ総計212件）

参考　名寄せPythonスクリプトをChatGPTに依頼した質問文

「Excelファイル"E:\test\ggg.xlsx"のD列（左から4番目）には文字列が書き込まれています。この文字列の種別リストと種別数を求め、その結果をExcelファイル"E:\test\jjj.xlsx"に書き込むPythonスクリプトを教えてください。

"E:\test\jjj.xlsx"には、A列（左から1番目）に種別リストを、B列（左から2番目）にその数を書き込みます。」

参考　名寄せPythonスクリプト（ChatGPT回答）

import pandas as pd

# 入力ファイルと出力ファイルのパス
input_file = r"E:\test\ggg.xlsx"
output_file = r"E:\test\jjj.xlsx"

# Excelファイルからデータを読み込む
df = pd.read_excel(input_file, sheet_name=0)

# D列のデータを取得（0インデックスなので、3はD列）
d_column_data = df.iloc[:, 3]

# 種別リストと種別数を計算
category_counts = d_column_data.value_counts()

# データフレームに変換
result_df = pd.DataFrame({
    '種別リスト': category_counts.index,
    '種別数': category_counts.values
})

# 結果を新しいExcelファイルに書き込む
result_df.to_excel(output_file, index=False, header=['種別リスト', '種別数'])

2　遺物台帳「名称欄」名寄せ結果に基づく分類

遺物台帳「名称欄」の分類は「土器か土製品か」「土器部位、土製品種別」「朱塗」の3視点から行いました。そのうち「土器部位、土製品種別」の視点から行った分類は次の通りです。

●分類コード番号2

1…（土器）土器

2…（土器）口縁部

3…（土器）底部

4…（土器）把手

11…（土製品）土錘

12…（土製品）円盤

13…（土製品）耳飾

14…（土製品）11、12、13以外の土製品

この分類コードを遺物台帳「名称欄」名寄せ結果（212件）に手作業で確認しながら当てはめました。

遺物台帳「名称欄」名寄せ結果を分類した様子（分類コード番号2）

「名称-分類コード」の対応表（辞書）を作成したことになります。

3　「名称-分類コード」対応表を使った、遺物台帳への分類コード記入

「名称-分類コード」対応表（212件の辞書）を使って、遺物台帳（20923件）へ分類コードを記入しました。この記入は次のPythonスクリプトでほんの数秒でできました。手作業なら1週間の仕事になりそうです。

遺物台帳分類コード記入結果（データ総計20923件）

参考　「名称-分類コード」対応表をつかった分類コード記入PythonスクリプトをChatGPTに依頼した質問文

Excelファイル"E:\test\hhh.xlsx"のD列（左から4番目）には名称が文字列で記入されています。この文字列に対応する分類コード番号2をM列（左から13番目）に書き込むPythonスクリプトを教えてください。

名称と分類コード番号の対応はExcelファイル"E:\test\lll.xlsx"のA列（左から1番目）が名称、C列（左から3番目）が分類コード番号2になります。

参考　「名称-分類コード」対応表をつかった分類コード記入Pythonスクリプト

import pandas as pd

# 入力ファイルと対応表ファイルのパス
input_file = r"E:\test\hhh.xlsx"
mapping_file = r"E:\test\lll.xlsx"

# 入力ファイルからデータを読み込む
input_df = pd.read_excel(input_file, sheet_name=0)

# 対応表ファイルからデータを読み込む
mapping_df = pd.read_excel(mapping_file, sheet_name=0)

# 対応表を辞書に変換（名称 -> 分類コード番号2）
mapping_dict = pd.Series(mapping_df.iloc[:, 2].values, index=mapping_df.iloc[:, 0]).to_dict()

# D列のデータを名称として取得し、対応する分類コード番号2をM列に書き込む
input_df['分類コード番号2'] = input_df.iloc[:, 3].map(mapping_dict)

# 結果を新しいExcelファイルに書き込む（上書き保存）
input_df.to_excel(input_file, index=False)

print("分類コード番号2の書き込みが完了しました。")

4　感想

データ数が数百程度なら、あるいは1000～2000なら、以上の作業はExcel機能を使って全部手作業で行えます。これまでは実際に類似作業を手作業で行って、その作業を楽しんでいました。しかし、データ数が万の単位になると手作業は現実的ではありません。今回Pythonを利用して「面倒な作業はPythonに任せる」が実現したことは、自分にとって感動的です。

また、Pythonスクリプトをつくる際のChatGPT質問文の作り方にも慣れてきて、ChatGPTとのやりとりがとても円滑になっています。（あるいはChatGPTが高性能化しているのかもしれません。）

遺物台帳データの整備が進んだ段階でExcelファイルからデータベースファイルに移行して、SQLで分析作業を行うことを予定しています。SQLを使えば各種分類分析作業がより効率的になりそうです。

技術メモ Blenderにおける複数マテリアル（テクスチャ画像）のベイクによる統合

 Technical note: Integrating multiple materials (texture images) in Blender by baking

In Blender, if multiple materials (texture images) are attached to an object, I confirmed how to integrate them by baking. Having one material (texture image) makes it easier to overlay with another texture image, which is convenient.

Blenderで、オブジェクトに複数マテリアル（テクスチャ画像）が貼り付いている場合、それをベイクで統合する方法を確認しました。マテリアル（テクスチャ画像）が1つになると、別のテクスチャ画像とのオーバーレイ操作などがしやすくなり、便利です。

1　1つのオブジェクトに複数マテリアル（テクスチャ画像）が貼り付いている例

米軍空中写真7枚を3DF Zephyr Liteに投入してできた3DモデルをWabefront(.obj)ファイルで書き出すとテクスチャ画像が3枚付いてきました。

米軍空中写真3Dモデル（Wabefront(.obj)ファイル）のファイル構成

3DF Zephyr Liteで周回撮影写真から3Dモデルを作成する場合、Wabefront(.obj)ファイルに書き出すと、5回に1回くらいの割合でテクスチャ画像が複数枚になります。

このWabefront(.obj)ファイルをBlenderに読み込むとマテリアル（テクスチャ画像）が3スロット貼り付きます。

Blenderでマテリアル（テクスチャ画像）が3スロット貼り付いている様子

このマテリアル3スロットを1スロットに統合する手順を以下メモします。

2　新たなUVマップの作成とUV展開

プロパティ→データ→UVマップに移動して新しいUVマップを作成します。

新しいUVマップを作成した様子

新しいUVマップが選択されている状態を確認した上で、編集モード→オブジェクト全選択→UV→展開します。

3　新しいマテリアルの追加と画像テクスチャの追加

新しいマテリアルを追加して、シェーダーエディターで画像テクスチャノードを追加します。画像テクスチャノードの画像名をクリックして画像ファイルを生成します。

追加した新マテリアルに画像テクスチャノード（画像ファイル生成済）を配置した様子（シェーダーエディター画面）

画像テクスチャノードはプリンシプルBSDFとリンクしません。

4　既存マテリアルに画像テクスチャノードの配置

新しいマテリアルに追加した画像テクスチャノード（画像ファイル生成済）をコピーして、あるいは画像テクスチャ-マッピング-テクスチャ座標の3つコピーして、既存マテリアル全てにそれぞれ貼り付けます。（シェーダーエディター画面で操作する。）

5　ベイク

新しいマテリアルのシェーダーエディター画面に戻り、画像テクスチャノード（画像ファイル生成済）が選択されていることを確認してベイクします。

ベイクはプロパティー→レンダー→レンダーエンジン（CYCLES）→ベイクに移動して、ベイクタイプをディフューズに、影響寄与で直接照明と間接照明のチェックを外します。余白のサイズを小さくします（自分は1px）。ベイクボタンを押して、ベイクします。

6　ベイク画像の保存

UV Editing画面でベイク画像を保存します。

7　ベイク画像のリンクと既存マテリアルの削除

新しいマテリアルのシェーダーエディター画面で画像テクスチャノード（画像ファイル＝ベイク画像）をプリンシプルBSDFとリンクします。既存マテリアル全てを削除します。この時3Dビューポートのモデルはテクスチャ画像が乱れています。

テクスチャ画像が乱れた3Dモデル

8　UVマップを新しいマップに変更して可視化する

UVマップを新しいマップに変更して可視化（カメラマークチェック）すると、3Dビューポートでベイク画像がテクスチャ画像となっていることが確認できます。

UVマップ変更の様子

3つのマテリアル（画像テクスチャ）を1つのマテリアル（画像テクスチャ）に統合できました。

9　メモ

2～3のマテリアル統合方法はテクスチャ画像のないもの（ディフューズ色のマテリアルのみ複数あるもの）でも確認できました。

10　若干の疑問

web検索で見かけるページで説明されている複数マテリアルの統合手順は、自分が見たページは全て次の点がこの記事説明と違います。

私が見かけたwebページで説明されているベイク方法

「既存マテリアル毎にベイクを繰り返し、ベイク画像を順次オバーレイ加刷して完成させる。」

このような煩雑な方法を取らなくても、今回、ベイクは1回の操作でできました。

恐らく最近のバージョンアップでBlenderのベイク機能が向上し、そのベイク機能向上の説明がweb情報としては時間的に間に合っていないのだと考えます。

11　複数マテリアル（テクスチャ画像）統合の価値

自分にとっての複数マテリアル（テクスチャ画像）統合の価値は次の2点です。

1　マテリアルのミックス調整が容易になる。

複数に分割されたマテリアルが無くなることで、他のマテリアルやテクスチャ画像とノードを通じてミックス調整することが格段に容易になります。

2　人が理解できるテクスチャ画像の取得

フォトグラメトリソフトで作成した3Dモデルのテクスチャ画像は一般に人が理解できない（機械だけが理解できる）まだら模様等の複雑な画像となっています。

3DF Zephyr Liteのフォトグラメトリ機能で3Dモデルを作成した場合、3DF Zephyr Lite→Wabefront(.obj)ファイル書き出し→BlenderでUV展開→Wabefront(.obj)書き出し→3DF Zephyr Lite読み込み（UVマップ付メッシュを入力）→Wabefront(.obj)書き出しというプロセスを通じて、Photoshop等で編集できる（人が見て理解できる）テクスチャ画像を得ることができます。

このプロセスはテクスチャ画像が複数枚ある場合は機能しませんが、上記方法を導入すれば、テクスチャ画像を1枚にまとめることができ、人が見て理解できるテクスチャ画像を取得できます。

技術メモ 遺物の3D密集度の直観的表現

 Technical note: Intuitive representation of 3D density of relics

I considered a method to intuitively express the density of relics distributed in 3D space. A buffer was set for the artifacts, the number of artifacts in the buffer was counted and classified, and this was expressed using color gradation and object size. High-density areas become embossed.

3D空間に分布している遺物の密集度を直観的に表現する方法について検討しました。遺物にバッファーを設定し、そのバッファー内の遺物数をカウントして分級し、それを色グラデーションとオブジェクト大きさで表現しました。高密度域が浮彫になります。

1　遺物密集度分級とその表現例

遺物密集度分級とその表現例 by arakiminoru on Sketchfab

遺物密集度分級とその表現例

遺物密集度分級とその表現例（考え方）

左…素遺物3D分布モデル

中…表現例1

右…表現例2

立方体は2ｍ×2ｍ×2ｍ

素遺物3D分布モデル及び表現例1の遺物は半径2.5㎝球で表示

表示例2の球は半径2.5㎝、3㎝、3.5㎝、4㎝、4.5㎝。

有吉北貝塚北斜面貝層Ⅱ-27グリッド遺物3D分布モデルの一部を利用して作成。

3Dモデル画像

3Dモデル画像　オルソ投影　正面から

3Dモデル画像　オルソ投影　上から

3Dモデル動画

2　感想

3D空間に分布している点群の密集度を表現する方法を検討しています。平面に点群が分布している場合、その密集度をヒートマップ（カーネル密度推定）で表現する方法があります。しかし、3D空間点群分布をヒートマップのように表現する方法をまだ見つけていません。そこで、初歩的ですが、ヒートマップ類似の結果がでるような例を自力で検討してみました。

表現例2では高密度分布域が浮き彫りになり、直観的に理解できます。

技術メモ Sketchfabへのアップロード能力比較 Blenderと3DF Zephyr

 Technical note: Comparison of upload capabilities to Sketchfab: Blender and 3DF Zephyr

I experienced the difference in the ability to upload to Sketchfab between Blender and 3DF Zephyr, so I took notes. 3DF Zephyr Lite has more upload capability than Blender.

Blenderと3DF Zephyrについて、Sketchfabへのアップロード能力の違いを体感しましたので、メモしました。Blenderより3DF Zephyr Liteの方がアップロード能力があります。

1　BlenderによるSketchfabへのアップロード結果

最初アップロード結果　Sketchfab画像

2回目以降アップロード結果　Sketchfab画像

BlenderによるSketchfabへのアップロードではテクスチャ（画像）が完全に貼り付きません。数回試したのですが、改善できませんでした。

2　3DF Zephyr LiteによるSketchfabへのアップロード結果

アップロード結果　Sketchfab画像

遺物3D分布図における遺物バッファー表現

問題なくアップロードできました。

3　メモ

3Dモデルのオブジェクト総数は約4700で、マテリアル数はマテリアルコピーを多用しているので全部で21です。

Blenderの方がSketchfabへのアップロード能力が優れているような印象をこれまでなんとなく抱いていたのですが、それは間違いで、3DF Zephyr Liteの方がアップロード能力が優れていることを確認しました。