はじめに 　ぼくは混乱状態になってきたので，ここで整理したいと思う。その上で，CloudCompareやMeshLabでのぼくの利用姿勢を正すことができる。 １　２セットの段ボール三箱と神武天皇遙拝所碑のLiDAR撮影 　この章は全く自分用の覚え書きである。3Dデータの欠損をMeshLabを使って穴埋めする　で示したように，MeshLabへのメッシュOBJの読み込みの際に，ファイル名に注意を払うべきことに気付いた。ファイル名内に空白spaceを入れてはならないことである。2バイト文字日本語も入れない方が良いとも考えている。　図１には，二つのファインダーが見える。Wikipediaによれば，「ファインダー（英: finder）は、カメラにおいて撮影前に目で構図を決めたりピントを合わせたりするのに使用する覗き窓など」とある。そういえば，アナログカメラを使っていた時代にこのファインダーは自分の言葉として定着していた。macのファインダーの名称はここから来ているんだなあ。今更の気付きだけど。　このファインダーの左部は，2023年1月11日に撮影したものである。OBJファイルだけは1月25日の日付があるが，これはMeshLabへのOBJ読み込みが出来ず，iPhone 12 ProのScaniverseで名称変更をする必要性があって，出力し直したためである。OBJ以外についてはファインダー上で直接，修正した。　この1月11日の撮影は1月7日にMetascanでの撮影結果に愕然とした結果である。1月7日にMetascanで段ボール三箱と神武天皇遙拝所碑を撮影したが，いずれも線分を表現できず，がっかりして，次点候補だったScaniverseに望みを託したからであった。そしてScaniverseがMetascanと比べると遙かに線分の再現性が高いことを実感した。その結果が左のファインダーなのである。Metascanで取得したものは線分が歪んでいるので，表示対象にしなかったので，Metascanの出力ファイルは無い。　で，右のファインダーのファイルは1月26日に撮影をし直したものである。上記の学習のゆえに，ファイル名は英数字のみにし，スペースも排除している。ただ，Metascanで撮影したファイル名は，metascan_20230126_1536_ぼくの命名，となる。記録する上でこの接頭辞は邪魔ではないが，ぼくの命名自身に含まれている内容なので，ぼくの命名法をMetascanについては変更した方が良いと思われる。その変更結果を図２に示したいと思う。　図１の左のファインダーを見ると，Scaniverseによる出力ファイルは，メッシュ（OBJ, FBX），点群（LAS, PLY）である。LASについては，iPhoneでも使えるようになったLiDARの標準ファイル形式「LAS」ってどんなデータなの？を、PDAL/Laspyを使って調べてみる。で解りやすく説明されているが，ぼくには今のところ不要で図２では削除している。　図１の右のファインダーを見ると，どうもエキスポートしたあとで，ファインダーで各ファイルを個々のフォルダーに整理したようである。図１の左のファインダーでは整理されていないが，実はmouseWindowsでは同様に整理している。CloudCompareでの作業ファイル群の名称が単純で元ファイルとの関係がわからなくなるために，iPhone 12 Proからエキスポートされたファイルを個々のフォルダーに入れる必要があった。その経験を踏まえて，macのファインダーでその作業を実行したのである。図１の右ファインダーでは上から見ると，段ボール三箱では，Metascanによる，メッシュOBJ，点群PLY，Scaniverseによる，メッシュOBJ，点群PLY，神武天皇遙拝所碑では，Scaniverseによる，メッシュOBJ，点群PLYが見える。神武天皇遙拝所碑については，1月7日にMetascanでLiDARと写真測量を丁寧に実施し直線の復元ができなかったので，実施しなかった。このファイルをmacにダウンロードしているかどうか，確認すべく，metascan_2023_01，で検索したがこのファイルは見つからなかったので，iPhone 12 ProのMetascanのライブラリーを見て，本日には，一応ダウンロードすることにした。というのは，Jan. 30, 2023でProが更新日で，回避したいからである。 　さて，今後のファイル名の構成は次の形が適当か。現場での命名のあと，インドアでmacに保存する際に整理すれば良い。現地では難しいが，ローマ字でもいいから英数字で揃えた方が良いだろう。形式１：　[日付230138]+[テーマ3carton]+[3d-app(+LiDARorPhoto)]+[試行回数_4]形式２：　[テーマ3carton]+[日付230138]+[3d-app(+LiDARorPhoto)]+[試行回数_4]　形式１と形式２の何れがいいか。調査地では何らかのテーマがある。同日に異なったテーマでスキャンすることも当然ある。同じテーマで調査日が大きく離れる場合もある。パソコンで分析する場合に，最も有効なファイル名称は何だろうか。ファインダーまたはブラウザーでの操作だけでなく，CloudCompareやMeshLabの読み込みも考えた方が良いだろう。というわけで，形式２を採用したい。なお，一連のファイルを検索する際には上位カテゴリーとして日本語を入れた方が良いだろう。ファイルのパスで２バイト文字が介在する場合，現在の欧米のソフトは文字化けはしないのではないか。CloudCompareとMeshLabについては問題が無いように感じている。そこで，形式２の関連ファイルを，神武天皇遙拝所碑と段ボール三箱に入れ込んだ方が良いだろう。 　で，何とかmacのファインダーでファイルなどの名称を変更したが，特にOBJファイルセットについては動くかどうか心配である。同じ内容のものを一つはMac_Win_Sharedフォルダーに入れ，フォルダー名を直方体撮影ファイル名再構成forMeshLabとした。もう一つはmouseWindows10のmoto > Documents > win_moto_documents > win_3d_scan，にコピーし，フォルダー名を直方体撮影ファイル名再構成forCloudCompareとした。　というのは，CloudCompareで操作過程で生まれたファイルと，MeshLabの操作過程で生まれたファイルを区別するためなのだが，同じファイルをCloudCompareとMeshLabで表示してみて，同時に比較したいということがある。CloudCompareはmouseWindows10で，MeshLabはWindows10 on Parallels Desctop of macで操作する。実際にやってみて，どうなるかはわからないので，今後変更する可能性がある。macのファインダーでの「直方体撮影ファイル名再構成」のファイル群のスクリーンショットを次に示す。 　さて，図２と３では，iPhone 12 ProのスキャンアプリMetascanとScaniverseについてまとめている。そして出力ファイルは，主にメッシュのOBJと点群のPLYファイルに注目している。それをまとめたのが，次の表１である。 　ターゲットは神武天皇遙拝所碑と段ボール三箱である。神武天皇遙拝所碑については表１上段の４組のOBJとPLYがあるが，一般に最大値を示す赤字が見えるのはScaniverseである。ScaniverseのJan. 10とJan. 26の違いは，身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める の「図53b　Mesh Simplificationの説明」に示されている。Scaniverseの描く段ボール箱の平面の点群が少なくて，何らかの省略プロセスがあると考えていたが，まさにこのMesh Simplificationがデフォルトで選択されていた。そのため，これを解除してスキャンをやり直したのが，Jan. 26のデータである。objファイルを見ると，Jan. 10は526kBで，Jan. 26は21.9MBと大きな違いがあった。　段ボール三箱の結果を見ると，objファイルの関係は神武天皇遙拝所碑と同じであるが，plyファイルでは神武天皇遙拝所碑とは違って，逆転して，Jan. 26の5.6MBに対して，Jan. 10は21.6MBとなっている。何故なのか，わからない。 　そこで，点群数などターゲットの再現性を，CloudCompareとMeshLabで閲覧して，確認したいと思う。なお，スキャンの密度などはその時のぼくの心身の感覚も関係するが，とにかく，アプリで表示される像に従っているのであって，およそ恣意的ではないと思う。 以上，Jan. 30, 2023記。 ３　CloudCompareとMeshLabによって3Dスキャンの再現力を見る ３.1　ScaniverseのMesh Simplicationの解除前と解除後の比較 最初にチェックしたいのは，ScaniverseのMesh Simplicationの解除前のJan.10のものと，解除後のJan. 26のものである。点群PLYとメッシュOBJについて求める。 a　段ボール三箱の点群PLY　解除前Jan.10 […]

はじめに 　iPhone 12 ProのLiDAR機能を使って3Dファイルを得て来たが，CloudCompareでまずは体積や面積を求めるというような言わば幾何学的空間分析での基礎的な作業の際に，3Dデータの欠損に基づくエラーには悩まされてきた。そして，単に体積や面積を求めることよりも，3D空間データの位置の信頼性そのものも気にかかるところではあった。　この種の問題を解決してくれるであろうMeshLabに本日出会った。他の用件もあるけど，大きな関心があり，ちょっと触ってみた。 １　始める前に 　MeshLabは，3Dメッシュデータ用ではあるが，点群ファイルにも使うことができるらしい。読み込み対応ファイルのうち，ぼくが使うiPhone 12 ProのアプリはScaniverseとMetascanで，これらのエキスポートファイル形式との関係では，MetascanのメッシュデータではSTLとOBJ，点群データではPLYとXYZ，ScaniverseのメッシュデータではSTLとOBJ，点群データではPLYに限られる。何らかの作業が終わって出力する形式はCloudCompareの利用を考えると，メッシュデータではSTLとOBJ，点群データではPLYに限られる。　MeshLabアプリは，https://www.meshlab.net/ から提供されており，最新のものは MeshLab version: 2022.02　28/Feb/2022であり，mac，Windows64，何れにも対応している。さきほど何れにもインストールし，何の問題も無かった。同梱のRead.meには次の但し書きがある。 Please, when using this tool, cite the following reference: Meshlab: an open-source mesh processing tool.P. Cignoni, M. Callieri, M. Corsini, M. Dellepiane, F. Ganovelli, G. RanzugliaProceedings of the 2008 Eurographics Italian Chapter Conference,ISBN: 978-3-905673-68-5, pp. 129-136, DOI: 10.2312/LocalChapterEvents/ItalChap/ItalianChapConf2008/129-136 　さて，操作マニュアルを調べてみた。MeshLAB Tutorial ここには，はじめに，Cloud Compare:
[…]

はじめに 　元伊勢大饗石のLiDAR測量 に続いて，このページを作成する。大饗石のCloudCompareの体積計算の妥当性を検証したいのである。　その方法として容易に考え得るのは，スケールで計測可能な直方体の体積を，LiDARまたは写真測量，そしてCloudCompareで求めて，この手法の再現性を確かめるということである。　近所で直方体を探したが，なかなか見つからない。墓石は近所に見られるが，避けたいところである。で，近所の為那都比古（いなつひこ）神社では，由緒も何も無い神武天皇遙拝所なるものを計測した。出直すつもりで，疲れて自宅に戻ったが，屋外は期待薄なので，狡（ずる）して室内で段ボール三個をまとめて計測することにした。　以上の材料を使って，このページを作成してゆく。 １　為那都比古神社の神武天皇遙拝所碑 　さすが，式内社だけにトベラの大木がある（図１，２）と思ったが，この境内は必ずしも古い地ではないようだ。一般に，神社の境内は掃き清められていて，古さを感じないこともあるが，それにしても，この境内では神々しい感じがしない。なお，図１のトベラの葉の塊の中段付近には垂直方向に伸びるトベラの徒長枝（とちょうし）である。 　なんともわからないが，かつては医王岩（図４，看板が右下に小さく見える　ソース不明でネットから拝借）に係わって為那都比古神社の前身があったようだが。一度参拝したいと思う。自宅から徒歩で1時間ほどか。図３に見えるが，山麓線からバス路線「ルミナス箕面の森」への道に入ってすぐ右手の「あかつき特別養護老人ホーム」の看板がある交差点から入って，大宮寺観世音菩薩を過ぎると，医王岩参道入り口があって，そこから北に登ることになる。 以上，Jan. 7, 2023記。 追記　May 17, 2023： 　奥さんの見舞いに娘がMay 15に来たので，懸案だった医王岩に出かけた。そして埼玉に戻ったMay 17にも医王岩に再訪した。というのは，15日に撮影した医王岩が一枚岩では無くて，落石が基盤岩に載った構造のように見えたからである。ジョイントには惑わされるので，層理面についても，走向傾斜を求めた。ノートを忘れたので，読みは録音した。 追記図1, 2：　図１で右手の道路に進むと特養あかつき荘へ。図２は図１の左手の道を進むと辿り着くちょっとした広場である。右手の垂直面が医王岩になる。 追記図3, 4：　全部で４区分でき，足下，下半身，上半身，そして，首（顔），とも見える。首（顔）＝最上部には天狗の鼻のようなものも見える。しかし，これは冠か何かにして，上半身としたのが顔で，横一文字の割れ目から下が上半身と下半身になるのであろう。横一文字の割れ目を境に，下方は左上から右下に層理のようなものが見えて，上方では左下から右上に層理のようなものが見える，ようにも見える。全体が一枚岩か，それとも複数の岩体なのか。それが気になって，May 17に出かけたのである。自宅から20分余りで到着した。 以上。 追記　May 18, 2023： 　May 17の調査では紙を忘れてiPhoneの録音機能を使ったが，問題があって，駄目だった。アップルのボイスメモを押してすぐにしゃべると，最初の音声が録音されていなかった。なぜか，ずーとオンのままで，聞くに耐えない。録音の時刻が自動に記録されると思ったが誤りだった。タイムスタンプが無い。いいソフトを探そう。 追記図5〜7：　追記図5とのジョイントは，N38ºE, 62ºE, N33ºE, 58ºE。図6のそれは，N38ºE, 52ºE。だいたい，この医王岩最下部の走向傾斜はこんなものか。 追記図8, 9：　層理面を確認した。走向傾斜は計測したがボイスメモに問題。層理の傾斜はほぼ垂直に近い。 追記図10, 11：　層理面を確認した。走向傾斜は計測したがボイスメモに問題。層理の傾斜はほぼ垂直に近い。 追記図12, 13：　両写真の最下部が，胴と顔の境界のジョイントになるのだろう。ジョイント面の山側には顔のブロックが消失している。 追記図14, 15：　消失している部分の面の走向と傾斜を測ったが，N62ºW, 20ºSか。再確認の必要あり。 追記図16, 17：　層理が明瞭だ。胴より上の顔の残骸の一部だろう。N10ºE，83ºEか？　要確認のこと。 　再調査，必要。層理面の走向傾斜が医王岩の<胴体最下部>でも，<胴体最上部>でも，<顔ブロック>でも，類似しておれば，同一岩体となる。要走向傾斜計測。今度は紙を忘れないように。蚊がもう出てきて，顔ブロック周辺の走向傾斜計測中には目の前で，嚼まれてしまった。 以上。 　為那都比古神社の違和感についつい，拘ってしまった。図５に神武天皇遙拝所碑を示す。この正面に立って拝む場合の方位はどうなっているのか。磁石としては最も信頼できるコンパスSUUNTOを使ってまずは土台に載せてみた（図６）。ほぼ北東を指す。ぼくのこの地の方向感覚からすると奇妙なので，この土台からコンパスを離すと（図７），正しく，東を向く。図７右部には，コンパスのエッジと碑の土台とはほぼ平行になっている。この花崗岩は，磁鉄鉱系列の山陰起源の可能性が高い。　遙拝先として考えられているのは畝傍山の麓に明治になって造営された神武天皇陵なのか，伊勢神宮なのか，わからない。磁北から90ºの東方向に向かって遙拝する形なので，天皇陵にも伊勢神宮にも向いていない。 ２　神武天皇遙拝所碑のスケール実測3D 　 　図8の立面図と平面図はイラストレータで1/10スケールで作成した。為那都比古神社の設計思想はわからない。花崗岩の切り出しの精度は5mmほどであり，およその平均にあたる値を使って図を作成した。　計算式として注意すべきは，四角錐の面積と，直方体土台部分の面積であろう。この両者はエクセルでの計算式も示している。前者については，四つの二等辺三角形をなす側面の面積の計算式であり，後者については，図８の平面図で中央の柱の部分を差し引くことを忘れないことだろう。追記 Jan. 24, 2023：　このポスティング作成過程で，値に疑問を持ち，強風と雪の中，再度，現場を訪れた。直方体部分の高さを149cmから144.5cmに修正した。この図8を含めて，特に表の修正を今後する必要がある。 ３　LiDARおよび写真測量で得られたイメージの限界 　今回の実験で，LiDARも写真も，かなり欠陥があることがわかった。真っ直ぐの稜線の復元に大きな歪みが生じる。室内で段ボール箱３個を並べたもののスチール写真 still photo（図9, […]

はじめに 　冗長をさけるために，一つのテーマを分割した。このページは次のページに続くものである。 Cloudから抽出された連続プロファイルの利用１　utilization of many vertical profiles extracted from a point cloud Part１ 　上記ページ（Part 1）では，be氏によって撮影されたドローンの3Dスキャンデータから，CloudCompareを使って海食崖の断面図を作成した。そして，fbx 3D画像を観察しつつ，断面図の妥当性を評価した。 　このページでは，その結果から，海岸地形のうち，旧汀線に関連がある傾斜変換点を把握し，その高度変化を，海岸線の岬と湾の分布から捉えたいと思っている。 １　Profile #58の評価 　Part 1では，いわば適当に，#48から断面図評価を始めた。ここでは断面の評価と現地での観察記録のあるProfile #58 から始めたいと思う。　作業してきたExractedProfiles.binファイルは終了して，最終的なExractedProfiles12.binを開いた。Microsoft Wordなどのアプリと異なり，開いているファイルと保存するファイルは異なる。開いているファイルはいわば作業ファイルで，保存する場合は，ファイル名を次から次とシリアルに名称を変えて行くのがいいと思われる。経験的に得たことである。ファイルを終了するのも特にそのメニューは用意されておらず，DB Treeから削除という形で終了することになる。そして新たに，ExractedProfiles12.binを開いたのである。 　この図１の上部の線分群はExtractedSections.binで，いわば平たい藁葺きの屋根のように見える。そして，Profile#58を選択しているので，黄色の直方体が断面を包んでいる。削除前のProfile域が残っている。で，次の図２のようにfbx 3D画像を表現したのが図２である。 　図２では，断面図が3D画像にピッタリと載っている。次の図３はprofile面の方向を知るために，回転した結果である。赤いprofile面が黄色の直方体の対角線に一致している。3D画像との関係を見ると，ほぼ海食崖線に対して垂直方向の断面であることがわかる。 　この地形の意味を知るには，地形変換点と潮位との関係を知る必要がある。地形変換点の座標値は記録してゆくべきである。その手法は次のページに説明した。iPhone 12 Pro撮影の3Dスキャン画像の座標を捉える　この説明の中の，４.2　Point list picking，が使える。以上，Mar. 25, 2022記。 ２　Point list pickingの有効性 　Point list picking機能は，ぼくのような3Dスキャン画像から3D位置情報を得たいものにとって，CloudCompareの大きな魅力の一つである。大変感謝している。profilesにはこの機能は通用しない。図４では，最上段のアイコン群の左から４番目の”Point list picking”ツールが使える体制になっている。それは，DB Treeで見られるように，fbxファイルのModelを選んでいるためである。 　で，このツールをクリックした結果が図５である。これまで作成したPointリストが作成されている。海食崖地形のキーとなる傾斜変換点を適当にピッキングした結果の一部が図５に見えている。 　DB Treeには，Picked points listが見えていて，これにラベルを付けて保存した上で，表計算ソフトを使用することで，種々の解析が可能になる。 　今後，この種の作業をして，全域の傾斜変換点の高度分布を求めて行く。今後の作業はペーパーの内容の一部を構成することになるので，共同研究者のnob氏とbe氏だけが閲覧できるページ Parts-3以降 を作成して行くつもりである。 　なお，picking listの保存は，次のようになる。左のペーンのDB Tree内のPicked […]

はじめに 　クラウドから地形断面図を作成 から続くページである。Extraction sectionsプロセスを経て作成した，sectionsそしてprofilesの利用法をこのページで考えたい。cloudファイルを呼び出すとやはり，作成したsectionsもprofilesも含まれていない。先のページで考えたように，それぞれのグループを保存する必要があったのである。 　図１のDB TreeでのExported.binは92kBでsectionsのファイルで，Extracted.binは2951kBでprofilesのファイルである。先のページで述べたように，CloudCompareでは，次のように記述されているが，all section cloud(s) are stored in a default group named Extracted sectionsall section profiles(s) are stored in a default group named Extracted profiles名称のバグと言える。敢えて，ファイル名をエキスプローラーで変更してもいいか，やってみた。Exported.binをExtractedSections.binに，Extracted.binをExtractedProfiles.binに。全然問題が無いので，今後，同様に変更することにする。 　さて，図２のように，断面が多すぎて何も把握できない。 　profiles no. つまり，Section contour #の分布を見ると，どうも南からナンバーリングされているようで，DB Treeで，Section contour #31を選択した結果が図３である。黄色の直方体が見えている。他のプロファイルも選んで見るとかなり大きな直方体を示すものがあり，地形研究者としては違和感がある。つまり，point cloudでの詳細な3D値から断面図が作成されていることがわかるのである。先のページでは，「Sections thicknessは，セクション位置で利用する点群の幅であろうと考え，ここでは1.0mとした。その入力したものが次の図28である。セクション間隔は2.0mであるので，セクション位置の前後併せて1m幅の点群を使ってプロファイルを作成すると考えたのである」としているので，かなり平均的な地形からプロファイルの方向が決定されたはずではあるが。 　ここでの問題は，予想できたものであったと言える。Extract sectionsのオプションのtypeの選択の問題もあるだろう。 type：　図ではLowerが見えるが，他にUpperとBothがある。初期値としてはZ軸に平行な閉輪郭であり，その等高線の上方か，下方か，両方を取るか，ということになる。（全く未だ理解できない）　 さて，さて。 以上，Mar. 15, 2022記。 　図２の結果を漫然と見たり，何らかの統計処理をしても意味は無いことは，初めから理解していた。で，現地調査で得た認識こそ重要と考え，幾つかの断面測量について，かく漫然と見てきたが，結局，2019年春調査した断面が最も有効と考えた。それが次のものである。 １　海食崖のgapを読むための基準を提示する　省略 　ここで，旧汀線地形の記述していたが，省略する。図４，図５も削除した。他の公開しない共同研究者限定ページに移動した。 以上，Mar. 28, 2022記。 ２　プロファイルの利用法を考える 　多量の断面をすべて生かすことはできない。何を基準に選べばいいのか。その基準の基礎を前章で示したのであるが，気になるのは，CloudCompareで得たプロファイルの意味を確認したい。図６のように，描いたシングルパスpolylines（白色表示している）沿いに発生させられたsectionsは，これに直交している。ラインはEdit/colors/Set unique，で塗色を設定できる。シングルパスを編集画面で左クリックすると，シングルパス全体を包む形で，黄色の選択枠が表示されるが，それを白色にしたのである。この黄色の下辺の枠外に出ている黄色の線分（赤線で囲んでいる）は#1-48のsectionである。 […]

はじめに 　iPhone 12 ProとMetascan Proを使って，フィールドで3Dスキャンする予定であるが，Extract sections，つまり連続的な断面図を得る必要がある。つまり，点群 point cloudでなければならない。Metascan ProのExportファイルの形式は，Metascan support によれば次のものである。 USDZ is an open standard, supported natively on iOS and macOS.FBX is a closed format, created by Autodesk and widely supported by 3D software applications and game engines.OBJ is a simple text-based format which is supported by almost all 3D software. Metascan stores the […]

はじめに 　これまで，iPhone 12 Proを使って3DスキャニングしてCloudCompareで何らかの作業をしてきたが，実は，もともとは，このページにこれから示す内容に到達するための準備であった。ぼくはこの作業は初めてなので，うまく行くかどうか，わからない。既存研究はない。 　ここまでのポスティングが扱ってきた最も大きなファイルは白姫大明神裏でのLiDARマージbinファイルで119MBである。ここで扱うFBXファイルは，550MB前後もある。CloudCompareで動かすのにかなり骨が折れる。これはbe氏が，写真画像幾何学に基づいて撮影したものである。 　平面直角座標系のもので取り込む際には，計算や表示の簡便性からXY値を平行移動して小さくすることが多い。Z値，つまり海抜高度に変更はない。計算処理後，座標値は元の大きな数字に戻るように，デフォルトであるが，左下の□にチェックが入っている。平面直角座標系はnorthing がX軸，eastingがY軸になっていて左手座標系であり，CloudCompareが扱う右手座標系とは異なる。しかしながら，編集画面での表示や計算過程としては，ぼくが関心を持つ幾何学的分析については問題がないようである。 　図２の編集画面の左手には激しい波の飛沫が見えている。このシーンのほぼ中央の海食崖下部のズームインを図３に示す。 　要するに，図３の海食地形の高度分布を捉えたいのである。段彩図や等高線を作成することは可能ではあるが，それでは微地形の高度変化を捉えにくい。海食崖のおよその走向に対する垂直断面図を連ねて，いわばブロックダイアグラムを作成することが最も妥当ではないか，と思っている。計算が重くて失敗するかもしれない。どの程度の數や距離がこなせるのか，わからない。何回かに分ける必要があるかも知れず，必要な部分をsegmentするのが一番いいとも考えている。とはいえ，まずは，丸々やってみようかと思っている。そういう試行錯誤的実験を繰り返して，精密な成果を得たいと思っている。 　以下には，まずは，CloudCompareの Extract Sections の手法の手順を整理したい。 以上，Mar. 4, 2022記。 　追加　Mar. 6, 2022: 新たに挿入する。このページの主題である “Extract Sections”に対応するファイル形式はテキストファイルだけであることがわかった。ここまで示したmeshファイル形式の一つFBXファイルでは，この機能が使えないことが判明した。3Dスキャナからの3次元データを格納するために設計されたPolygon File Format（ply）形式も対応していない。 　対応ファイル形式は点群ファイルであるが，xyz 各行が [x, y, z]（x, y, zは３D座標），xyzn 各行が [x, y, z, nx, ny, nz]（nx, ny, nzは法線），xyzrgb 各行が [x, y, z, r, g, b]（r, g, bは [0, 1]の範囲の浮動小数点数）などがあるが，当方のテキストファイルは図4に示したもので [x, y, z, r, […]