LiDARスキャンオブジェクトの底を塞ぐ closing the bottom hole of a LiDAR scanned object
はじめに
iPhone 12 ProのLiDARで3DスキャンしてPLY, OBJ, FBXファイルで出力して， メッシュファイルを使って体積を求めるべく，CloudCompareで開いて，Edit > Mesh > Measure Volumeを実行すると，計算値が出るが，必ず，”The above volume might be invalid (mesh has holes)”のメッセージが現れる。
これをぼくは作成した3Dスキャン像に隙間や穴ができているためだと考えて，実際埋める作業をしてきた。実際埋まるのであるが，相変わらずこのinvalidメッセージが出る。MeshLabでの作業を学んでいて，昨晩，やっと気付いたのである。オブジェクトの下が抜けているのである。オブジェクトが載る床や地面に「接する」底はスキャンできない。これまでの3Dスキャン像は全部，底抜けである。この底抜けのために，”The above volume might be invalid (mesh has holes)”のメッセージが現れていたのである。
次の表１のように，メッシュエンティティに対するCloudCompareの体積の計算結果は，実測値に極めて近い結果となっている。とはいえ，計算結果に付属して，invalidメッセージが出るのである。この原因が，3Dスキャン像の底抜けが原因であったのである。メッセージの理由がわかったし，正確な体積値が得られるので，まあ，これで良しとしてもいいが，底抜けが解消されたらこのメッセージが出なくなることを確かめたい。そのために，このページをこれから作成したいと思う。
1 大饗石周辺のライダー測量
次のページに大饗石について示している。
A 比沼の真名井（京都府京丹後市峰山町久次）の大饗石
B 元伊勢大饗石のLiDAR測量
２ 「６ 大饗石の体積を求める３： 点群欠損部の解消」に係わって
CloudCompareでの解析のために，点群PLYファイルを使って，分析を進めてきた。現場での3Dスキャンが満足の行くものでなかったこともあって，ポリゴンの欠落などがあったので，それを解消すべく，上記Bのウェブページの「６ 大饗石の体積を求める３： 点群欠損部の解消」に記した過程を実行した。体積計算値の信頼度が不確かなので，ウェブページ
C 身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める
も新たに作成した。ここで述べる内容を含む報告を，現在，関西大学文学論集（Vol. 73, Nos. 1 & 2「合併号」, 3）に作成中で，その作成過程で，本ウェブページの「はじめに」に示した表１の結果を得ることができた。
正確な値は，点群系のPLYファイルをメッシュ化してメッシュの欠陥を埋めたエンティティーか，メッシュ系のOBJなどをMeshLabで穴埋め処理したエンティティーに，Edit > Mesh > Measure Volumeを実行することで，得ることができる。
大饗石だけのオブジェクトを抉りだした作業で得たのは点群系のPLYファイルなので，それをメッシュ化したエンティティーについての処理過程を示したいと思う。なお，メッシュ化は，Mesh\Delaunay 2.5D (XY plane) のコマンドで実行できる。このリンクはCloudCompareのマニュアルである。次にコピペする。
図１では，斜面に載る大饗石を下方方面から上方面に眺めたものである。右手の垂直壁は日陰側で，杉が接して生えていて，LiDAR測量がこの裏の日向側からすると，撮影密度も多少は小さかったかも知れない。この点が後述するメッシュファイルが生まれた原因であったことは間違いない。
Menu
This tool is accessible via the ‘Edit > Mesh > Delaunay 2.5D (XY plane)’ menu.
Description
Computes a Delaunay 2D1/2 triangulation on a point cloud.
The point cloud is simply projected in 2D on the (XY) plane. Then the corresponding 2D points are triangulated and the mesh structure is applied to the 3D points.
By default the 2D Delaunay triangulation is done on the cloud convex hull. Therefore CloudCompare will ask the user to specify a maximum length for the triangle edges. This allows to remove the biggest triangles (generally on the boundary) that are not necessarily meaningful. If this value is left to zero, then all the triangles output by the Delaunay triangulation will be kept.
This works very well with rather flat clouds and properly oriented (i.e. with the Z dimension as the vertical one). If the point cloud is not properly oriented but is still rather flat in a direction, you should consider using the other version of this method Delaunay 2D (best LS plane).
Note: for 3D triangulation, refer to the qPoissonRecon plugin.
ここに記述されている内容であれば，Delaunay 2.5D (XY plane) を実行することに問題はない。”specify a maximum length for the triangle edges” が理解できないので，デフォルトで実行した。これ自体，問題はないはずではある。
３ CloudCompareからMeshLabへ
さて，表3では，二つの直方体で，一つ（段ボール３箱）は点群PLYを3Dメッシュ化したエンティティに対して体積計算を実施した。もう一つ（柱状石碑）は元々のファイル自体，OBJファイルにMeshLabで「穴」埋め作業を実施している。その結果，高い正確度を得ることができた。
この大饗石の場合は点群PLYを大饗石だけ刳り抜いたものである。これ自体に時間がかかった。そして，3Dメッシュ化したエンティティーに対して体積計算を実施した。その結果が35㎥であった。これが体積の真値を示す筈である。このメッシュ化したエンティティーを使って，底抜け部分を塞ぐ作業をしてみたいと思って，昨日，実行してその過程を63枚のスクリーンショットで記録したのであるが，土台の穴埋めには今だ成功していない。
今日はその続きをしようとしたが，
MeshLabによる、3次元測定データの穴埋め 2014-05-28
に巡りあった。筑波大の三谷さんのウェブページである。
この観点を使って，まずは始めたいと思う。ただ，ここには入力ファイルの形式が示されていない。特に記述が無いということは，メッシュファイルである。これまでの体験を通じて，どうもメッシュファイルは像を結ぶ上で，スキャン対象の3Dオブジェクト像が変形してしまう可能性が高いようだ。
そこで，大饗石の点群PLYファイルを呼び出せばいいはずだが，CloudCompareで大饗石だけ抉りだした結果はCloudCompareのbinファイルになっている。
weblio辞書では，3Dファイル形式がレガシーと現行の２種類に分類され，PLY (ファイル形式)は，レガシーにのみ掲載され，Wavefront OBJ形式(.obj)とともに配置されている。ウィキペディアの内容と同じだ。コピペされている。でウィキペディアはより詳しいが，そこに，
MeshLab – PLY形式と3Dメッシュ間の変換、処理、可視化のためのオープンソースのWindows、Mac OS XおよびLinuxアプリケーション
CloudCompare – PLYファイルを扱うための別のオープンソースアプリケーション
とあった。驚きだ。
binファイルを読み込んでcloudエンティティを選んで，File > Save >。ファイルの種類を先に，PLY meshとする。エクステンションは，.ply，なのだけど，PLY meshとある。OaeishiOnlySep07_2023.plyという名で保存した。
２ 次に，MeshLabを開いて，File > Import Mesh >，で，OaeishiOnlySep07_2023.ply，が読み込めた。そうなんだなあ。
CloudCompareでは, VisableだけでなくNormalsにも✓した画像に似ている。
４ Poisson surface reconstructinoを使ったが
前記のMeshLabによる、3次元測定データの穴埋め 2014-05-28
を実行しよう。これは，Poisson surface reconstruction に基づいている。操作情報は次の記述だけ。
「このような場合は、メッシュ操作で穴を埋めようとするのはほとんど無理なので、面の情報を破棄して、点群(法線情報を含む)からのメッシュ再構成をしてしまったほうがよいです。そこで、MeshLabに備わっている [Filters]の [Remeshing…]-[Surface Reconstruction: Poisson]を使ってみました。（オプションの Octree Depth は 8 に設定しました）」
このコマンドは，MeshLabのSurface Reconstruction Screened Poissonであり，これには，前述のKazhdan, M et al.のペーパーが引用されている。このパネルのHelpを参照した（図2）。
上記ウェブページではOctree Depth=8とだけあるが，他のパラメータも重要だ。現在のMeshLab 2022.02では，次のReconstruction Depthのようである。
Helpのオプション項目：
Merge all visible layers：デフォルトでは✓なしで，ママ。
Reconstruction Depth： デフォルト 8のママ。
Minimum Number of Samples： できるだけスムーズにするには高い値の方がいいようだ。デフォルトは1.5であるが，不確かだが10としよう。体積を求めるにはよりスムーズにした方がいいと思うからである。
Interpolation Weight： この値をゼロにすると，original (unscreened) Poisson Reconstructionになってしまう。このパネルを実行する意味が無くなると言って良いと思う。デフォルトは4で，4のママ。
Confidence Flag： デフォルトは✓なし。この場合，すべてのnormals法線はこの操作の前のunit-length（単位長）に揃えられる。デフォルトのママ。
Pre-Clean： デフォルトは✓なし。この場合，vertices (vertex) 関係の整理が実行されない。実行した方がいいと思うので，✓。
Number Thread： このreconstruction algorism 再建アルゴリズムの最大実行回数の意味であるがどういう役目を果たすのか，わからない。デフォルト 8のママ。
図３のように，実行した結果はスカートを穿いたようになった。底は抜けたままだ。残念っ。新しいレイヤーができただけなので，右クリックで “delete current mesh” を実行すれば削除できそうなので，一応，キープ。全くデフォルトで実行したのだが，その結果の違いがわからなかった。二つとも削除した。底抜けを埋めるのは全く無理。
５ Filters / Remeshing, Simplification and Reconstruction/ Close Holes
さて，現状は，前日の出口無しに戻ってしまった。先ほどMeshLabに取り込んだPLYファイルを操作する。Filters / Remeshing, Simplification and Reconstruction/ Close Holes を実行すると，PreConditions’ Failureとして，Current mesh does not have any faces. とのメッセージだ。
新たなファイルだから当然だなあ。
この点群PLYファイルに，Filters / Normals, Curvatures and Orientation / Compute normals for point sets, で点群の法線を生成する。Neighbour numをデフォルトの10で。Helpを見ると，Smooth Iteration欄がある。これを実行するかどうかで，像がスムーズになるかどうがわかるかも。
実行したが全く変化なし。faceを作ることができない。CloudCompareでは問題なくできたのにMeshLabではできないなあ。仕方が無いのでSep05のものを使う。つまり，これはCloudCompareでPLY点群エンティティをメッシュ化したものである。
６ 点群データを減らす
点群は現在，Vertices: 615, 237, Faces: 1,230,423である。底抜けを埋めるのにポリゴン数を減らす必要があると考えた。
Filters / Sampling / Clustered Vertex Sampling を実行する。Cell sizeの設定で，左の world unitを触ると，右のpercent値は連動して変化する。粗いモデルが欲しいのでworld unit値を大きくすれば良いと考えた（eg. 図６）。Applyを繰り返してCluste samples (Numbers)がどんどん作成されるがなかなか難しい。結局，自動で表示されていたディフォルトのworld unit値（図７）が一番よかった。No. 17を示したい。下部にはの情報がしめされている。Cluster samples (17)のVertices: 8,766 (624,003), Faces 0 (1,230,423)とある。（ ）内は処理前のものだ。
で，これから，図７の点群に対して，新たにメッシュを作成することになる。Cluster samples (17)を選択して，Filters / Remeshing, Simplification and Reconstruction / Surface Reconstruction: Screened Poisson を選択する。Reconstruction Depth （15）> 10，Minimum Number of Samples (8) > 6で設定。応答なしで，タブの✖️をプッシュすると，MeshLab終了か待つかが出て見ている時に，出てきた。やっぱり，大きなスカートを穿いてる。図８はwireframe表示をしたものである。
この図８には大饗石の３面，上面（大饗面），日陰の側面，日向の前面（斜面の低い方）である。図１には，ほぼ同じ面が見える。日陰の側面の壁の高さがかなり低いのが注目されるだろう。日陰の側面の，壁中部と下部は壁と認識されていない。つまり，大饗石のオブジェクトとはかなり異なったものとなっているのである。図７の点群は図１の点群PLY像と対応していて，大饗石を正しく表現しているが，メッシュ化された像は大饗石と異なる像を結んでいるのである。
つまり，このことが点群で得られた体積53.4または53.9㎥と，メッシュ化されたエンティティーから得られた体積35.3㎥との，違いの根拠となっているのである。
底抜けの解消を図る過程で，思いも寄らない結果を得ることができた。
なお，この過程で得られたレイヤーすべてを保存するには，図９のように，一応，レイヤーの表示をして，Save View State，と，Save All Files，に✓を入れた方が良いだろう。mlpは，MeshLab特有のbinファイルである。
以上，Sep. 7, 2023記。
７ メッシュファイルの限界だなあ。
今日，昨晩の発見をもとに，種々試行して，メッシュよりも点群の方が信頼できることがわかった。点群ファイルを点群対応の計算式で計算すれば，まあそれなりの解を得ることができる。自由度がありすぎるのが，欠点ではある。
で， 点群PLYをメッシュ化した時には，そのPLYにもともと内在していたものが出てくるようだ。それが，大饗石の体積の計算結果の点群計算とメッシュ計算に出てきてしまったのである。MeshLabで点群の編集をいくらしても，見かけ上，すごく良くても，問題点は内在していて，メッシュ化するともともとの歪んだ3D像が出てしまう。
前章で，「このことが点群で得られた体積53.4または53.9㎥と，メッシュ化されたエンティティーから得られた体積35.3㎥との，違いの根拠となっているのである」を，本日攻めきった。
MeshLabで，大饗石⋯⋯⋯⋯⋯4.mlp，の，Poisson meshを選んで，File > export mesh，を実行する。デフォルトと✓が入るところは全部✓（図10）。
その結果，図10の次に，右下のコンソールに，Saved Mesh C:/Users/moto/Documents/win_moto_documents/win_3d_scan/大饗石metascan_LiDAR/Poisson mesh ply in 31 msec，と出る。
それをCloudCompareに取り込む。図11のように，なんと，メッシュ出力したつもりだが，PLYになっている。
ここでは省略しているが，CloudCompareのDB Treeでは，meshアイコンが表示されている。
図12は日向の側面，図13は日陰の側面。segmentationは一気にはできない。図14では１回で切り取ったが，オーバーハングしているところもあるので，topビューで１回でsegmentationをしようとしたのはまずいと結果を廃棄した。
大雑把から少しずつ細かく実施して行った。図24が汚いけど，仮の完成。これで体積計算してみたら，図27のように，29.6㎥。削り過ぎた。途中の段階で体積計算を繰り返していたらよかった。とにかく，35㎥と近くて，meshモデルの計算結果はポアッソンモデルに対応していることは明らかである。
図28の，昨日実行したCluster samples (17)のcloudにはモデルが綺麗なので，これをメッシュ化したら，図29のようにやっぱり汚くなった。図28のようなモデルであっても，歪みは内在しているのである。点群モデルであってもそういった歪みを内在している。ソフト上での処理では解決できないのである。点群モデルを点群モデル用の計算アルゴリズムでやれば，まともな結果が現れるのである。図30に示すが，V=52.912（Matching cells 58.6%）であった。
元の点群にはノイズが多く，この図30のモデルの結果を優先したい。
以上，Sep. 8, 2023記。
８ 柱状石碑メッシュ系OBJファイルで底抜けを塞ぐ
柱状石碑にトライして，成功した。3Dメッシュモデルまたは3Dマッピングには必ず不要な空隙ができる。簡単にここでは穴と称するが，これを埋める操作は必須である。3Dスキャニングはオブジェクトの表面しか捉えることができない。オブジェクトは重力故に，その置かれた，または分布する場の3D情報が欠落する。その大きな穴を塞ぐ必要性は，特に，3Dプリンター出力の際に生じる場合が多いだろう。
まずは，成功した実例を述べるが，結果的に言えば，塞ぐことでオブジェクトの3D像は歪み，体積を求めるには不都合となることがわかった。体積（や表面積）を求めるには，この3D像の底抜けは塞がない方が良い。この結論は体積（や表面積）を求めるのに大変都合が良い。穴埋め作業にはかなりの時間を割く必要があるからである。この実例を一つ，ここに紹介する。
MeshLabに関する穴埋め作業が次のプレゼン資料に整理されている。
Simple Mesh Editing by Marco Callieri et al. https://vcg.isti.cnr.it/corsi/G3D_InfoUma/Slides_2021/06_MESH_EDITING.pdf
穴埋めには，次の三つのステップ Cleaning掃除, Fixing修理, Remeshing再メッシュ化がある。このツールとして最も簡便で多用されているのは，
Remeshing, simplification and reconstruction->Close Holes
パラメータには次の４点がある。（MeshLab でメッシュの穴埋めを行なう）
Max size to be closed： ふさぐ穴の境界を構成するエッジの最大数。このエッジ数より小さい穴が処理対象。
Close holes with selected faces： 処理対象を選択されている面に限定するかどうか。
Select the newly created faces： 新たに追加された面を選択状態にするかどうか。処理前の選択面の選択は解除される。
Prevent creation of selfIntersecting faces： なるべく既存面と交差しないように面を追加するかどうか。
他に参考になるページは： MeshLabでゴミ削除後の3Dデータの穴を埋める方法
で，これが功を奏さない場合，次の文献に基づくコマンドである。
Screened Poisson Surface Reconstruction by MICHAEL KAZHDAN and HUGUES HOPPE
Filters > Remeshiing, Simplication, and Reconstruction > Surface Reconstruction Screened Poisson
Poisson Surface Reconstructions Experiments
Procedure:
Open the point cloud file in Meshlab.
Clean the point cloud by removing any outliers and irrelevant data.It also reudces the number of points to be processed.
Compute Vertex Normals. Go to Filters->Normals,Curvatures and Orientation->Compute Normals for point sets.We have used default meshlab parameters for computing the normals.
Apply Poisson Reconstruction. Go to Filters->Remeshing,Simplification and Reconstruction->Surface Reconstruction:Poisson. To obtain good results, you may have to experiment with giving different octree depth value.Normal direction may need to be flipped for orienting them outwards.(Filters->Normals,Curvatures and Orientation->Flip Faces)
To add color, Go to Filters->Sampling->Attribute Transfer.Select color transfer check box and source and destination files appropriately for mapping.以上，Sep. 10, 2023
８.1 まずはポアソン面復元
MeshLabの分析対象ファイル名は，英数字にしないと行けない。CloudCompareは２バイト文字でも問題は無いが。ただ，経験上，path過程が２バイト文字であっても問題はない。
図31, 32では，ポアソン再建コマンドを選ぶ。
図32のパラメータ指定に注目。最下段のPre-Cleanに✓が入っていない。
図32, 33はエラーとエラーに対処。
図35, 36： 地面にスカートができて，底抜けは相変わらず。
８.2 Close Hole
Filters > Remeshing, Simplification and Reconstruction > Close Hole これを実行すると，manifoldエラーが出るので，前もって，
Filters > Cleaning and Repairing > Repair non Manifold Edges （デフォルトのRemove Facesのまま）（図37），Applyしたが，実行結果はゼロだった。つまり，不要だ。これはポアッソン再建実行後のためであろう。
そして，Filters > Remeshing, Simplification and Reconstruction > Close Holeで，サイズを100に設定して（図38），Apply。実行結果はゼロ。これも，ポアッソン再建実行後のためであろう。サイズを10,000 に設定して（図39）, Apply。
その結果，図40に合わせて，consoleでは，Closed 1 holes and added 117 new face，というメッセージ。柱状石碑メッシュの底の半分ほどが塞がっている。図41 に見えるように，sizeを 20,000 にして，Prevent creation of selfintersecting facesの✓は外してみた。図42のように底抜けが解消されている。
Prevent creation of selfintersecting facesの✓は外してみた
MeshLabでPoisson meshレイヤーを選んで，objファイルとしてエキスポートした。図43では，✓可能な３カ所を空欄にしたために，出力したobjファイルはあってもCloudCompareでは表示できなかった。図43に新たに赤い✓を入れているが，これをすることでCloudCompareで見ることができるようになる。図44はCloudCompareで見たものである。柱状石碑の底は，図43ではフラットであるが，CloudCompareでの表示，図44では丸くなっている。ファイル名は，/Poisson mesh.ply/ になっている。
図44の左ペーン下部のMeshウィンドウでは，Wireframeに✓を入れていない。
８.3 CloudCompareを使ってメッシュオブジェクトの体積計算
図45のオブジェクトは，柱状石碑だけでなく，その周辺の小石散布面も含む。このオブジェクトの体積は，Edit > Mesh > Measure Volume，から，V=0.119938㎥と出た。底抜けがないので，エラーメッセージが出ない。まさに，これを待っていた。これまでのinvalidメッセージから回避できたのである。この底抜けが原因であることが，まあ，明らかになった。うれぴい。
図46はこのオブジェクトを，柱状石碑とこの周辺の小石散布面に分割すべく，ポリゴン（赤い枠線）で区画した。
求めたいオブジェクト Mesh.part （図47）と，削除対象のオブジェクト Mesh.remaining（図48）を分割して，それぞれの体積を求めた。前者はV=0.0518695であるが，これは最初に提示した表１の実測値 0.0538に比べると，0.0519/0.0538 = 0.965で，元々の点群PLYを3Dメッシュ化したものの比1.006よりも真値からより離れていることがわかる。
つまり，体積（や面積）を求める場合，点群やメッシュの小さな綻びを修復して，Edit > Mesh > Measure Volume (or Surface)を実行する手法が最も妥当の方法と言える。”The above volume might be invalid (mesh has holes)”のメッセージは，3Dスキャンオブジェクトに否応無く現れる底抜けの存在によるものであり，この意味で，体積（や面積）を求める際には，全く問題のないメッセージであることがわかるのである。
なお，CloudCompareやMeshLabでの作業結果を保存する場合，作業しているファイルが格納されているフォルダがデフォルトの場として用意されず，前回の作業pathが残っており，他のアプリ使用時の感覚で，保存作業を進めると，ウィンドウズPC内のエクスプローラーのファイル分布に混乱が生じる。
元々のファイルがわからなくなった場合，コンソールには作業内容が秒単位で記録されているので，大変面倒なのであるが，机上またはデスクトップ上のテキストエディターに時刻とともに簡便な作業記録をした方がいいかも知れない。
いまぼくが触っているファイルの呼び出し記録を次にメモしておく。
[15:08:18][I/O] File ‘C:/Users/moto/Documents/win_moto_documents/win_3d_scan/直方体撮影ファイル名再構成forCloudCompare/3D神武天皇遙拝所碑/jimmuhi230126scaniverse_obj/Poisson mesh.ply/’ loaded successfully
図49では，先にMesh_remaining.objを保存し，次にMesh_part.objを保存しようとしている。保存すると，図50のコンソールにその所作の記録が残る。図51ではその結果をエクスプローラーで確かめている。
８.4 MeshLabで空隙を塞ぐ
CloudCompareで分割した，mesh.partとmesh.remainingを，MeshLabで開いて，分割した際の大きな穴を塞ごうとした。
mesh.remainingにあたる柱状石碑の周辺をまずは，トライした。
まずは，図52のように，Filters > Remeshing, Simplification and Reconstruction > Close Holeで，Max size to be closed: 10,000，他は全✓。結果は，Closed 0 holes and added 0 new faces。1,000,000も実行，これも駄目。原因はPreventの✓を外さなかったためかも知れないが。
ポアッソンに期待。図53のパネル設定。
図54のように，穴が埋まった。
図55のように，Poisson meshを選んで，これだけをobjファイルとしてエキスポート。
さて，Mesh.partについては，図56のようにポアッソン再建のパラメータを入れたが，図57のように裳裾のようなものが生成され，底抜けは解消されない。図42の成功は，柱状石碑の回りの平たい砂利面が功を奏したようだ。図56のような切り口では図57のようなスカートになってしまう。これは大饗石の場合と同じだ。
図54のように穴が解消しても体積値は変わらない。要するに，体積などを求めるには，穴を塞ぐという方向性は徒労に過ぎないのだ。
以上，0:26，Sep. 12, 2023記。
８.5 体積計算に最も適したファイル形式は
本日Sep. 12, 2023の大饗石3Dスキャンファイルに係わる試行錯誤を通じて，点群PLYファイルが最も優れたものであることが明らかになった。使用アプリは，3Dファイルを取り扱うオープンソースのうち，最も普及しているCloudCompareとMeshLabである。
最もポピュラーな3Dスキャンファイルの形式は，繰り返し述べているように，点群系のPLY，メッシュ系のFBXとOBJである。今日の両アプリでのFBXファイルのやり取りの過程で，FBXは少なくとも体積計算には適していないことがわかった。
OBJとPLYは，場合によっては，テキストでの編集が可能で，二つのファイル形式の共通点も多い。この二つがどうもぼくにとっては最適なものらしい。点群はPLY，MeshLabはOBJである。これまでフラフラしていたので，ファイル形式を絞ることができて，勝手に，喜んでいる。
以下，今日実施した一部をここに記したいと思う。
CloudCompareで，FBXファイルを開いて，図58には日向側，図59には日陰側を示している。大饗石だけを分割した結果であるが，メッシュ系の場合，faceまたはwireframeの関係だろうが，分割作業の切り口が比較的スムーズでは無い。しかもPLYファイルに比べて欠落部分が大きい。スキャンで出来上がった3Dオブジェクトをsegmentationすると，切り口が粗くなってしまうようだ。元伊勢大饗石のLiDAR測量 を改めて見たのであるが，確かに間違いない。
以上，Sep. 12, 2023記。これから夜の散歩だ。23:52，帰宅。
大饗石のスキャニングファイル出力はPLY, XYZ, FBXに限定し
