点群OBJで小数点のカンマが問題になる理由
点群OBJをアップロードしたときに、頂点数が0と表示される、ファイルを選択しても処理が進まない、点群の一部しか表示されない、座標が異常な大きさになるといった問題が起きることがあります。こうした症状の原因の一つが、座標値の小数点にピリオドではなくカンマが使われていることです。
OBJは、行頭のキーワードと、その後ろに続く値で形状情報を記録するテキスト形式です。標準的な頂点行では、vの後ろにX座標、Y座標、Z座標が空白で区切って記述されます。元仕様では、vは幾何頂点を定義し、X、Y、Zは浮動小数点数、必要に応じて4番目の値として重みwを持てます。また、点要素はp行で頂点番号を参照して定義されます。したがって、v行だけを点群として表示できるか、p行が必要かは読み込み先の実装によって異なります。Gist
text v 12.345 67.890 3.210
この例では、座標同士が空白で区切られ、各数値の小数点にはピリオドが使われています。多くのOBJ読み込み処理は、このようなピリオド小数点の数値を前提に解析します。
一方、データを書き出した環境の地域設定や、表計算ソフトなどを経由した変換処理の影響により、次のように小数点がカンマになることがあります。
text v 12,345 67,890 3,210
人が見れば、12.345、67.890、3.210を意味すると推測できます。しかし、読み込み処理によっては12,345を一つの有効な浮動小数点数として認識できません。その結果、その頂点行を無効と判断したり、ファイル全体の解析を中断したりすることがあります。
点群OBJは、数万点、数百万点、場合によってはそれ以上の頂点を含みます。ほぼすべての頂点行で同じ小数点形式が使われている場合、読み込み側が有効な頂点を取得できず、頂点数0として扱う可能性があります。
ただし、OBJ内にカンマがあれば、すべて小数点として置換してよいわけではありません。仕様外の出力や中間変換データでは、カンマが値同士の区切りや桁区切りに使われる場合があります。また、コメント、オブジェクト名、グループ名、材質ファイル名の一部にカンマが含まれることもあります。
たとえば、123,456という表記は、作成元の条件によって123.456を意味する場合と、12万3456を意味する場合があります。この違いを確認せずにカンマをピリオドへ変換すると、本来の座標値を壊すおそれがあります。
点群OBJの小数点問題を解決するには、最初にファイルの構造を確認し、カンマの意味を判別したうえで、数値部分だけを安全に変換することが重要です。変換後には、読み込めるかどうかだけでなく、点群の位置、縮尺、高さ、広がりが元データや既知の寸法と整合しているかも確認します。
変換前に読み込みエラーの原因を切り分ける
点群OBJを読み込めないからといって、小数点だけが原因とは限りません。OBJの読み込みエラーには、行構造の崩れ、文字コード、改行、座標値の不足、ファイル容量、点要素の不足、関連ファイルの参照切れなど、複数の原因があります。
変換作業を始める前に、まずOBJの先頭部分をテキストとして確認します。ファイル容量が小さければ一般的なテキスト編集環境で開けますが、大容量の点群OBJを全体表示しようとすると、読み込みに時間がかかったり、操作できなくなったりすることがあります。その場合は、先頭部分や指定した行だけを確認できる方法を使います。
確認の中心となるのは、行頭がvで始まる頂点行です。先頭から数十行程度を見て、値の区切り方と小数点の表記を確認します。
text v 42135,245 9876,810 32,445 v 42135,251 9876,816 32,449 v 42135,260 9876,825 32,451
この形式では、各頂点行に空白で区切られた数値が3つあります。また、それぞれの数値にカンマが一つずつ含まれ、カンマの後ろの桁数もおおむね揃っています。座標範囲や単位と矛盾しなければ、小数点としてカンマが使われている可能性が高いと判断できます。
一方、次のように空白がなく、複数のカンマが並んでいる場合は注意が必要です。
text v 42135,245,9876,810,32,445
この行だけを見ても、42135.245、9876.810、32.445という3つの座標なのか、6つの整数値なのかを確定できません。これは標準的な空白区切りのOBJ頂点行ではなく、元データの桁数や出力条件が分からなければ安全な自動変換は困難です。
OBJの標準的なv行はX、Y、Zに加えて、必要に応じて重みwを持ちます。一方、実装依存の拡張として、X、Y、Zの後ろにRGB値を並べる頂点色表現も使われていますが、元のOBJ仕様に含まれる標準項目ではありません。色付き頂点を扱う場合は、書き出し元と読み込み先の両方が同じ拡張形式に対応しているかを確認する必要があります。元仕様のv x y z wと、拡張のv x y z r g bを混同しないことが重要です。Gist+1
text v 12,345 67,890 3,210 0,500 0,600 0,700
この例は、X、Y、Zに続いてRGB値が並ぶ拡張形式である可能性があります。ただし、値の個数だけで断定せず、出力ソフトの仕様や正常なサンプルと照合します。
OBJに面やテクスチャが含まれている場合は、v以外の数値行も確認します。テクスチャ座標を表すvt、法線を表すvnにも浮動小数点数が記述されます。
text vt 0,250 0,750 vn 0,000 1,000 0,000
これらの行にもカンマ小数点が使われている場合は、対応する数値を変換する必要があります。
一方、面を表すf行や点要素を表すp行では、通常は頂点などの参照番号が使われます。
text p 1 2 3 f 1/1/1 2/2/1 3/3/1
これらは小数座標ではないため、通常は小数点変換の対象にしません。点群OBJを標準的な点要素として記述している場合は、v行数だけでなくp行の有無と参照番号も確認します。頂点だけを並べたファイルを受け付ける読み込み先もありますが、点要素がないと表示しない読み込み先もあります。
小数点が原因かどうかを判断するときは、座標値の変化にも注目します。
text v 100,100 200,100 10,000 v 100,110 200,105 10,002 v 100,120 200,110 10,004
カンマを小数点と考えると、X座標は100.100、100.110、100.120と変化しています。単位がメートルなら差は0.010メートルです。ただし、OBJの行順が空間的な隣接順とは限らないため、連続行の差だけで判断せず、座標範囲、既知点、対象物の寸法も併せて確認します。
これに対し、カンマを削除して100100、100110、100120としてしまうと、座標値の意味が大きく変わります。読み込み自体は成功しても、点群が本来とは異なる場所や大きさで表示される可能性があります。
小数点の変換を始める前には、座標系、単位、対象範囲、既知点の座標、想定する点数も可能な範囲で確認します。数値表記だけでなく、実際の現場条件と照合することで、カンマが小数点か桁区切りかを判断しやすくなります。
手順1 元のOBJを複製して数値形式を確認する
最初の手順は、元のOBJを直接編集せず、必ず複製してから作業することです。小数点変換は多数の数値を書き換える処理になるため、条件を誤ると元データを復元できなくなるおそれがあります。
元ファイルはそのまま保管し、変換作業用と確認用のファイルを別に作成します。ファイル名には、元データ、確認用、変換済みなどの役割が分かる情報を付けておくと、アップロード時の取り違えを防ぎやすくなります。
OBJが材質ファイルや画像ファイルを参照している場合は、元のフォルダを丸ごと複製し、その中でOBJを変換する方法が分かりやすいでしょう。OBJ内のmtllib行やMTL内の画像参照は、実際のファイル名と配置に依存するため、関連ファイルを別々に移動すると参照関係を確認しにくくなります。
複製後は、ファイルの先頭だけでなく、中間付近や末尾付近も確認します。複数のデータを結合して作成したOBJでは、前半と後半で数値形式が異なる可能性があります。前半はカンマ小数点、後半はピリオド小数点という混在も考えられます。
確認する際は、行頭の種類ごとに数値形式を整理します。頂点行のv、テクスチャ座標のvt、法線のvn、点要素のp、面のfなどをそれぞれ確認し、カンマを含む浮動小数点数がどこにあるかを把握します。
OBJには、コメントや名称を記録する行もあります。#で始まるコメント行、オブジェクト名を表すo、グループ名を表すg、材質を指定するusemtlなどです。
text
area, north side
o block,01 g group,main
これらのカンマは座標の小数点ではありません。ファイル全体を無条件で置換すると、コメントや名称まで変更されます。
材質ファイルを参照する行も確認します。
text mtllib material,01.mtl
このカンマをピリオドへ変更すると、実際の材質ファイル名と一致しなくなり、参照が切れる可能性があります。点群だけを表示する用途で材質が不要な場合でも、元のファイル構造を意図せず変えることは避けます。
次に、少数の頂点だけを含む確認用OBJを用意します。元のOBJから代表的な頂点行を数十行程度抜き出し、必要に応じて点要素も付けて、変換規則を試します。
text v -12,345 67,890 1,250 v 0,000 68,000 1,000 v 10,5 69,1250 1,75 p 1 2 3
確認用ファイルには、正の座標だけでなく、負の座標、ゼロ、整数に近い値、小数部の桁数が異なる値、頂点色がある場合はその代表例などを含めます。
小数部の桁数が揃っていない場合でも、各数値内のカンマが小数点であることを確認できれば変換できます。ただし、カンマの後ろを常に3桁とみなすなど、固定桁数だけに依存する方法では誤変換が起きる可能性があります。
手順1では、まだ全ファイルを変換しません。どの種類の行があり、どの位置に浮動小数点数があり、どのカンマが小数点として使われているかを把握することが目的です。
この確認を省略すると、読み込みエラーを直すつもりで、座標、重み、頂点色、材質参照、名称などを同時に壊してしまうことがあります。大容量データほどやり直しの負担が大きいため、最初に小さな確認用データで規則を確定することが重要です。
手順2 カンマの役割と変換対象を特定する
二つ目の手順では、カンマが小数点、桁区切り、値同士の区切りのどれに該当するかを判別し、変換する範囲を決めます。
最も判断しやすいのは、座標同士が空白で区切られている形式です。
text v 125,125 340,875 12,500
vの後ろに空白区切りの値が3つあり、各値にカンマが一つ含まれています。元の対象物や座標範囲と照合して問題がなければ、125.125、340.875、12.500として変換できる可能性が高い形式です。
ただし、12,500が12.500なのか1万2500なのかは、1行だけでは確定できません。ほかの頂点行、既知の寸法、座標系、単位と比較します。
たとえば、対象物の高さが数メートルから数十メートルであることが分かっており、Z座標が12,500、12,510、12,520と推移している場合、12.500、12.510、12.520と考えるのが自然です。
一方、平面座標として数十万から数百万程度の値を扱うデータでは、123,456が12万3456を意味する可能性もあります。小数点変換では、対象データの座標系や単位を無視して判断しないことが大切です。
カンマが複数含まれる値にも注意します。
text v 1,234,567 2,345,678 12,345
この形式では、X座標とY座標のカンマが桁区切りで、Z座標のカンマが小数点という可能性もあります。すべてのカンマをピリオドへ置き換えると、1.234.567となり、有効な数値ではなくなります。
逆に、すべてのカンマを削除すると、Z座標の12.345が12345になり、本来の高さを失う可能性があります。桁区切りと小数点が混在している場合は、単純な一括置換では対応できません。
座標の区切りにもカンマが使われている場合は、さらに慎重な判断が必要です。
text v 10,25,20,50,3,75
すべての座標の小数部が2桁で固定されていると分かっていれば、10.25、20.50、3.75と復元できる可能性があります。しかし、整数値や異なる小数桁が混在していると、どこで数値を区切るかを確定できません。
このような曖昧な形式では、元の点群データからOBJを書き出し直す方法が最も安全です。再出力ができない場合は、既知点の座標、点数、座標範囲、数値の桁数、元の列定義などを使い、変換規則を慎重に設計します。
変換対象となる行は、原則として浮動小数点数を含む行に限定します。点群OBJでは、まずv行を対象とします。vtやvnがある場合は、これらも確認します。vpが含まれる自由曲面データでは、その値も浮動小数点数ですが、一般的な点群用途では使われないことが多いため、存在する場合だけ仕様を確認します。
行頭だけで対象を判断する場合でも、行の途中に数値以外の文字が混ざっていないかを検査します。
text v 12,345 error 3,210
この行に対してカンマだけを置換しても、有効な頂点にはなりません。変換後に各要素を数値として解釈できるかを確認し、不正な行として行番号と内容を記録します。
負の値も対象です。
text v -12,345 -0,250 3,000
負号はそのまま残し、数値内のカンマだけをピリオドへ変換します。
text v -12.345 -0.250 3.000
指数表記が含まれる場合も、指数部分を壊さないようにします。たとえば、-1,234e-3が小数点カンマを使った数値であると確認できれば、-1.234e-3へ変換します。ただし、読み込み先が指数表記に対応しているかは別途確認が必要です。
変換対象を決める際は、頂点行に含まれる値の個数も確認します。標準的なv行はX、Y、Zの3値で、必要に応じて重みwが続きます。RGBが続く形式は実装依存の拡張です。
値が3つではないという理由だけで削除すると、正当な重み付き頂点や、読み込み先が対応する頂点色を失う可能性があります。一方、値の個数を確認せずにすべて受け入れると、区切りが崩れた行を見逃します。
変換前後で要素数が変わらないこと、各要素を意図した数値型として解析できること、pやfの参照番号が変わっていないことを確認します。
手順3 数値部分だけをピリオド小数点へ変換する
三つ目の手順では、特定した数値部分だけをピリオド小数点へ変換します。ファイル内のすべてのカンマを置換するのではなく、対象行を分解し、各数値要素の中にある小数点のカンマだけを変換する方法が安全です。
変換前の頂点行が次の形式だったとします。
text v -12,345 67,890 1,250
変換後は次のようになります。
text v -12.345 67.890 1.250
この処理では、行頭のv、座標同士を区切る空白、負号、整数部と小数部の桁数を維持します。変更するのは、数値要素内の小数点記号だけです。
小容量のOBJで、カンマが数値の小数点にしか使われていないと確認できる場合は、テキスト編集機能の置換でも対応できることがあります。しかし、点群OBJにはコメント、名称、材質参照などが含まれる可能性があるため、全体置換を行う前には十分な確認が必要です。
より安全なのは、ファイルを1行ずつ処理する方法です。処理対象の行頭を確認し、v、vt、vn、必要に応じてvpなどの数値行だけを空白で分割します。その後、各要素が想定する小数点カンマ形式に一致するときだけピリオドへ変換し、元と同じ順序で書き出します。
p、f、コメント行、名称行、材質参照行は、そのまま出力します。
text
area, north side
v 12.345 67.890 3.210 p 1 o block,01
このように処理すれば、コメントやオブジェクト名のカンマ、点要素の参照番号を維持しながら、頂点座標だけを変換できます。
変換済みの内容は、元ファイルとは別のファイルへ書き出します。元ファイルを読み込みながら同じ場所へ上書きすると、処理途中で停止した場合に元データまで失うおそれがあります。
大容量のOBJでは、ファイル全体を一度に読み込まず、1行ずつ読み書きする方法が適しています。数GBの点群OBJをすべてメモリ上へ展開すると、処理環境によっては動作が不安定になります。
行単位で処理すれば、必要なメモリを抑えられます。また、何行目まで処理したかを記録しやすくなり、途中で不正な行が見つかった場合にも位置を特定できます。
変換時には、正常に変換した頂点行数、カンマが見つからなかった頂点行数、数値として解釈できなかった行数、p行やf行の件数を記録すると検証しやすくなります。
元の頂点行数が100万行あり、変換後に正常な頂点行が99万行しかない場合、1万行が失われたことになります。読み込みに成功しても、点群の一部が欠落している可能性があります。
数値の桁は、できるだけ維持します。たとえば、12,345678を12.35のように丸めると、点の位置が変化します。変換の目的は小数点記号を直すことであり、桁数を減らすことではありません。
小数部の末尾にあるゼロも、そのまま残して構いません。
text v 12,500 3,000 0,250
text v 12.500 3.000 0.250
数値としては12.5、3、0.25と同じですが、元の表記を保つことで、変換前後の文字列比較がしやすくなります。
頂点色が含まれる拡張形式では、書き出し元と読み込み先がその形式に対応していることを確認したうえで、RGB値にも同じ小数点変換を適用します。
text v 12,500 3,000 0,250 0,400 0,500 0,600
text v 12.500 3.000 0.250 0.400 0.500 0.600
色が0から255の整数で記述される別の拡張形式なら、整数部分は変換しません。
text v 12,500 3,000 0,250 102 128 153
text v 12.500 3.000 0.250 102 128 153
ただし、頂点色の形式はOBJの元仕様で統一されていないため、値域や並びを推測だけで変更しないことが重要です。
変換後は、文字コードと改行にも注意します。数値だけを直したつもりでも、保存方法の違いによって文字コードや改行形式が変わり、別の読み込みエラーが起きる場合があります。
OBJの主要部分は英数字ですが、コメント、オブジェクト名、グループ名、材質名に日本語が含まれている場合は、保存時の文字コード変更によって文字化けする可能性があります。元ファイルの形式を可能な範囲で維持します。
全体変換の前に、確認用OBJへ同じ処理を適用します。確認用データが読み込めること、点要素が必要な読み込み先ではp行が正しく参照されていること、点の位置や縮尺が正しいことを確認してから、本番の大容量OBJを変換します。
手順4 変換後のOBJを検証してアップロードする
四つ目の手順では、変換後のOBJが構文上だけでなく、点群データとして正しいかを検証します。読み込みに成功したという結果だけでは、座標値が正しく変換されたとは判断できません。
最初に、変換前後の総行数を比較します。小数点記号だけを置き換えた場合、通常は行数が変わりません。変換後の行数が大幅に少ない場合は、処理が途中で停止したか、不正な行を除外してしまった可能性があります。
次に、vで始まる頂点行数を比較します。点群OBJでは、頂点数がデータ量を確認する重要な指標です。変換前後で頂点行数が一致しているかを確認します。
p行がある場合は、点要素の行数と参照される頂点番号も比較します。vtやvnが含まれる場合は、それぞれの行数も確認します。面を持つOBJでは、頂点、テクスチャ座標、法線の対応が崩れると、形状や表示に問題が起きることがあります。
ファイル容量も確認します。カンマをピリオドへ置き換えるだけなら文字数は同じであるため、ファイル容量は大きく変化しないのが一般的です。
改行や文字コードの違いで多少変化することはありますが、変換後のファイルが元の半分以下になっている場合は、途中までしか出力されていない可能性があります。
変換後の先頭、中間、末尾から複数の頂点行を抽出し、小数点が正しくピリオドになっているかを確認します。先頭だけが正常でも、途中に異なる形式のデータが含まれている場合があります。
次に、X、Y、Zそれぞれの最小値と最大値を確認します。座標範囲を求めることで、変換後の点群が本来の大きさを維持しているかを判断できます。
たとえば、変換前の値が12,345であり、本来は12.345を意味していたとします。誤ってカンマを削除すると12345になり、座標値が1000倍になります。
この状態でも数値としては有効なため、OBJの読み込み自体は成功する場合があります。しかし、点群が極端に大きくなったり、視点から遠く離れたりして、画面上で見えないことがあります。
点群の外形寸法も確認します。X座標の最大値と最小値の差を幅、Y座標の差を奥行き、Z座標の差を高さの目安として比較します。
実際の対象物が幅20メートル程度なのに、変換後の幅が2万メートルになっている場合は、小数点または単位の処理に問題がある可能性があります。
逆に、対象範囲が数百メートルあるのに、変換後の幅が0.数メートルしかない場合は、小数点の位置や単位を誤っている可能性があります。
行順に並ぶ点の変化量は補助的な確認に使えますが、OBJの頂点順は必ずしも空間的な隣接順ではありません。連続行の差が大きいだけで異常と断定せず、外形寸法、既知点、点の分布を優先して確認します。
確認用OBJをアップロードし、全体表示を行います。点群の形、向き、位置、縮尺、高さを確認します。点が表示されない場合は、読み込みエラーだけでなく、p行の要否や表示設定も調べます。
点群が座標原点から遠い位置にある場合、初期視点の範囲外に配置されることがあります。表示範囲を点群全体へ合わせる操作を行い、読み込まれているかを確認します。
点の表示サイズが小さすぎる場合も、データがないように見えることがあります。点サイズ、背景、視点の距離、表示範囲などを調整します。
確認用OBJで問題がなければ、同じ変換条件を本番ファイルへ適用します。本番ファイルについても、行数、頂点数、点要素、容量、座標範囲を確認してからアップロードします。
アップロード後には、既知の位置や寸法を使って最終確認します。測量基準点、構造物の高さ、既知の距離などと照合できれば、小数点の変換が正しいかを判断しやすくなります。
カンマの一括置換で起こりやすい失敗
小数点のカンマ問題を見つけたとき、最も簡単に見える方法は、ファイル内のすべてのカンマをピリオドへ置換することです。しかし、OBJの内容を確認せずに一括置換すると、別の問題を発生させる可能性があります。
まず、コメント内のカンマが変更されます。
text
survey area, section 1
一括置換後は次のようになります。
text
survey area. section 1
コメントは形状に影響しない場合が多いものの、データ管理用の説明や変換履歴を意図せず変更してしまいます。
オブジェクト名やグループ名にカンマがある場合も変更されます。
text o area,01 g point,group
名称が変わると、読み込み後の管理単位や外部の管理情報と一致しなくなる可能性があります。
関連ファイル名に含まれるカンマを変更すると、参照切れが起こることがあります。
text mtllib material,01.mtl
この行だけがmaterial.01.mtlに変わり、実際のファイル名がmaterial,01.mtlのままであれば、材質ファイルを見つけられません。
桁区切りのカンマを小数点へ変更する失敗もあります。
text v 1,234,567 2,345,678 12,500
すべてを置換すると次のようになります。
text v 1.234.567 2.345.678 12.500
一つの数値にピリオドが複数含まれるため、X座標とY座標を有効な数値として解釈できません。
カンマをすべて削除する方法も危険です。
text v 12,345 67,890 3,210
削除後は次のようになります。
text v 12345 67890 3210
構文上は3つの整数として読み込めるため、エラーが出ない可能性があります。しかし、本来の座標が12.345、67.890、3.210であれば、点群の位置と大きさが大幅に変わっています。
すでにピリオド小数点が使われている行と、カンマ小数点が使われている行が混在する場合もあります。
text v 12.345 67.890 3.210 v 12,350 67,895 3,215
この場合は、カンマ小数点を含む数値だけを変換し、正常なピリオド小数点はそのまま維持します。
区切り文字と小数点の両方にカンマが使われているデータでは、一括置換による復元が難しくなります。元の値の個数や桁数が分からない場合、見た目だけで正確に変換することはできません。
また、pやfの参照番号に対して不要な加工をすると、頂点との対応が壊れます。小数点変換の対象は浮動小数点数を含む行に限定し、参照番号は原則として変更しません。
点群OBJの変換では、エラーが出なくなることだけを目標にしないことが大切です。誤った数値でも構文上有効なら、読み込みは成功します。そのため、変換後の座標範囲、外形寸法、点数、点要素を必ず確認します。
大容量の点群OBJを変換するときの注意点
点群OBJは、頂点数が多くなるほどファイル容量も大きくなります。小容量ファイルでは問題なく使える変換方法でも、数百MBや数GBのOBJでは処理が停止したり、保存に失敗したりすることがあります。
大容量のOBJを一般的なテキスト編集環境で開くと、全データをメモリへ読み込もうとして動作が不安定になる場合があります。編集画面が表示されても、検索や置換の実行時に長時間反応しなくなることがあります。
大容量データでは、ファイルを1行ずつ読み込み、変換した行を別ファイルへ順番に書き出す方式が適しています。この方式なら、ファイル全体を同時にメモリへ保持する必要がありません。
変換前には、保存先の空き容量を確認します。元ファイルを残したまま変換済みファイルを作るため、少なくとも元ファイルと同程度の追加容量が必要です。
途中経過を保存する処理や一時ファイルを使用する場合は、さらに余裕を持たせます。空き容量が不足すると、変換済みファイルが途中までしか保存されないことがあります。
不完全なOBJでも、先頭部分だけを確認すると正常に見える場合があります。変換後は末尾まで出力されているかを確認し、総行数、頂点行数、点要素数を比較します。
ネットワーク上の保存先へ直接書き出す場合は、通信の中断にも注意が必要です。長時間の処理中に接続が切れると、変換済みファイルが不完全な状態で残る可能性があります。
可能であれば、安定したローカル作業領域で変換と検証を行い、完成したファイルだけを共有先へ移します。
大容量OBJでは、変換の進行状況を確認できるようにすると管理しやすくなります。処理済みの行数や書き出した容量が分かれば、処理が継続しているのか停止しているのかを判断しやすくなります。
変換中に不正な行が見つかった場合は、その行番号と内容を記録します。不正な行を無条件で削除すると、点群の欠落やp、fの参照ずれに気付きにくくなります。
不正な行が少数であっても、その周辺を確認します。ファイルの一部だけ区切り形式が異なる場合や、複数の頂点行が一つにつながっている場合があります。
大容量データを扱うときは、小数点変換とほかの加工を同時に行わない方が安全です。座標移動、単位変換、点の間引き、色の変更、小数点変換を一度に実行すると、問題が発生した際に原因を切り分けにくくなります。
まず小数点だけを修正し、頂点数、点要素、座標範囲を検証します。その後、必要に応じて別の工程で座標調整や軽量化を行います。
工程ごとに中間ファイルを残しておけば、異常が見つかった時点で一つ前の状態へ戻れます。元ファイル、変換済みファイル、座標調整済みファイルなどを区別して管理することが重要です。
変換しても読み込めない場合の確認事項
小数点をカンマからピリオドへ変換しても点群OBJを読み込めない場合は、小数点以外の原因を順番に確認します。
まず、各頂点行が正しい形になっているかを見ます。
text v 12.345 67.890 3.210
vと最初の座標の間、各座標の間には空白などの区切りが必要です。次のように文字が連結している場合は、正しく読み込めません。
text v12.34567.8903.210
数値の一部が欠けている行にも注意します。
text v 12.345 67.890
標準的な幾何頂点にはX、Y、Zが必要なため、Z座標がない行は正しいv行として扱えません。
数値以外の文字が含まれている行も読み込みエラーの原因になります。
text v 12.345 67.890 unknown
小数点だけを変換しても、unknownは数値として解釈できません。
表計算用の形式などを経由したデータでは、数値が引用符で囲まれている場合があります。
text v "12.345" "67.890" "3.210"
読み込み先によっては引用符付きの値を数値として扱えないため、元データの列構造を確認したうえで不要な引用符を除去します。
通常の空白とは異なる制御文字が区切りとして含まれる場合もあります。見た目では空白に見えても、読み込み処理が区切りとして認識できないことがあります。
改行の崩れも確認します。複数の頂点行が一つにつながっていると、正しく解析できません。
text v 12.345 67.890 3.210 v 12.350 67.895 3.215
本来は次のように行を分けます。
text v 12.345 67.890 3.210 v 12.350 67.895 3.215
文字コードや改行形式が読み込み環境に対応していない場合もあります。数値変換後に保存形式が変わったときは、変換前と同じ形式を維持できているかを確認します。
次に、点群として扱うための要素を確認します。元仕様ではvが頂点座標を定義し、pが点要素として頂点番号を参照します。読み込み先が頂点だけのOBJを点群として表示しない場合は、正しい参照番号を持つp行が必要です。反対に、読み込み先が独自の頂点のみ形式を要求する場合もあるため、アップロード先の仕様を確認します。
text v 12.345 67.890 3.210 v 12.350 67.895 3.215 p 1 2
p行がある場合は、存在しない頂点番号を参照していないか、0番を使っていないか、負の相対参照に読み込み先が対応しているかも確認します。
座標値が大きい場合は、読み込みに成功していても点が見えないことがあります。平面座標などをそのまま記録したOBJでは、点群が座標原点から大きく離れている場合があります。
初期視点が原点付近に設定されていると、点群が画面外に配置されているように見えます。点群全体へ視点を合わせる操作を行い、データが存在するかを確認します。
表示処理の数値精度によっては、原点から遠い座標で細かな形状が不安定になる場合があります。この場合は、元座標を保持する必要性を確認したうえで、表示用にローカル原点へ平行移動したデータを作る方法があります。
ただし、座標を移動すると保存される位置情報が変わります。移動量を記録せずに使用すると、ほかのデータと重ね合わせられなくなるため注意が必要です。
単位の違いも確認します。OBJの頂点値には、メートルやミリメートルなどの単位を機械的に指定する標準項目がないため、書き出し側と読み込み側で単位の解釈が異なる場合があります。
メートルで作成した座標をミリメートルとして解釈すると、点群は1000倍の大きさになります。反対に、ミリメートルの座標をメートルとして扱うと、1000分の1の大きさになります。
点群が極端に大きい、または小さい場合は、小数点だけでなく単位も確認します。
アップロード先が扱えるファイル容量や頂点数を超えている可能性もあります。この場合、小数点を正しく変換しても処理が完了しません。
確認用に頂点数を減らしたOBJを作り、同じ形式で読み込めるかを試します。少数の頂点では読み込めるのに全体では失敗する場合、構文よりも容量や処理負荷の影響が疑われます。
元のOBJに面情報が含まれている場合は、頂点番号との整合も確認します。頂点行を削除したのにf行の参照番号を変更していない場合、存在しない頂点を参照することになります。
点群として頂点や点要素だけを使う場合でも、読み込み先がOBJ全体の整合性を確認することがあります。不正な面行、点要素、材質参照が原因でファイル全体を受け付けない可能性があります。
関連する材質ファイルや画像がなくても形状を読み込める実装はありますが、読み込み先の仕様によっては参照エラーとして扱われることがあります。OBJ内の参照名と実際のファイル名、フォルダ構成を確認します。
小数点問題を再発させない運用方法
点群OBJを扱うたびにカンマを変換する運用では、作業時間がかかるだけでなく、誤変換のリスクも残ります。継続的に点群OBJをアップロードする場合は、書き出し段階で小数点をピリオドに統一することが重要です。
まず、OBJを書き出す環境の数値設定を確認します。地域に応じた表示設定が、ファイル出力へ反映されるソフトや変換処理があります。
画面上ではカンマ小数点が自然に見えても、異なる環境とのデータ交換では互換性の問題が起きることがあります。OBJの出力では、表示用の地域設定とは別に、ピリオド小数点を固定できる設定や、ロケールに依存しないエクスポート方法を選びます。
座標同士の区切りには空白を使用し、小数点と区切り文字に同じカンマを使わないようにします。小数点と座標区切りが同じ記号だと、元の値を正確に復元できない場合があります。
書き出し後には、OBJの先頭数行を確認する工程を設けます。
text v 12.345 67.890 3.210
このように、行頭がvであり、X、Y、Zが空白で区切られ、小数点にピリオドが使われていることを確認します。点要素を必要とする運用では、p行も確認します。
大容量の点群を本番出力する前に、少数の点を含む確認用OBJを出力し、アップロード先で読み込めるかを試す方法も有効です。
確認用データで問題を発見できれば、大容量ファイルの再出力や再アップロードを避けられます。
複数の担当者が点群OBJを作成する場合は、出力条件を共通化します。小数点記号、座標の区切り、p行の要否、座標系、単位、原点、軸方向、頂点色の形式、関連ファイルの配置などを作業ルールとして記録します。
同じ現場のデータでも、担当者や作業環境によって形式が異なると、結合時やアップロード時に問題が起きやすくなります。
変換処理を継続的に使用する場合は、変換結果の記録を残します。元の頂点行数、変換後の頂点行数、点要素数、不正な行数、X、Y、Zの最小値と最大値、変換日時などを保存します。
処理が正常終了したという結果だけでなく、点群の内容と参照関係が維持されていることを確認できる記録が重要です。
ファイル名にも変換状態を反映させると、誤ったファイルのアップロードを防ぎやすくなります。ただし、OBJが材質ファイルなどを参照している場合は、関連ファイル名や参照行との対応を確認します。
元データ、変換済みデータ、アップロード確認済みデータを別の場所で管理する方法もあります。作業途中のファイルを本番用の共有場所へ置かないことで、未検証データの使用を防げます。
変換後のファイルを保管するときは、どのカンマをどの規則で変換したかを記録します。単純な小数点置換なのか、桁区切りの削除を含むのか、座標区切りの再構成を行ったのかによって、データの信頼性は異なります。
元の出力環境を変更した場合や、点群の作成工程を更新した場合は、以前と同じ形式で出力されるとは限りません。定期的に先頭行、点要素、座標範囲を確認し、設定変更による形式の変化を早期に見つけることが大切です。
LRTK Phoneで取得または管理する点群データをOBJへ出力・変換してアップロードする場合も、利用する機能の対応形式、座標系、単位、頂点色、点要素の扱いを確認し、アップロード先の仕様に合わせて検証します。
まとめ
点群OBJの小数点にカンマが使われていると、アップロード時に座標値を数値として認識できず、頂点数が0になる、処理が停止する、点群が表示されないといった問題が起きることがあります。
安全に変換するための最初の手順は、元のOBJを複製し、頂点行や関連する数値行の形式を確認することです。元データを直接編集せず、少数の頂点を含む確認用ファイルで変換規則を試します。
二つ目の手順では、カンマが小数点、桁区切り、値同士の区切りのどれに該当するかを判別します。座標系、単位、対象物の寸法、既知点、数値の並びなどを使い、カンマの意味を確認します。
三つ目の手順では、v、vt、vnなどの浮動小数点数を含む行だけを対象にし、各数値内のカンマをピリオドへ変換します。コメント、名称、材質参照、ファイル名、pやfの参照番号などは変更しません。
四つ目の手順では、変換前後の行数、頂点数、点要素、ファイル容量、座標範囲、外形寸法を比較し、点群として正しいことを確認してからアップロードします。読み込みに成功しただけでは、座標が正しいとは限りません。
特に避けたいのは、ファイルの内容を確認せず、すべてのカンマを一括置換したり削除したりする方法です。桁区切りや名称まで変更すると、読み込みエラーだけでなく、座標の拡大、参照切れ、管理情報の変更につながります。
また、標準OBJではvが頂点を定義し、点要素はpで頂点番号を参照します。頂点行だけを点群として表示できるかは読み込み先によって異なるため、小数点を直しても表示されない場合は、p行の要否と参照番号を確認します。
頂点色は広く使われる拡張形式がありますが、元のOBJ仕様で統一された標準項目ではありません。X、Y、Zの後ろの値を自動的にRGBと決めつけず、重みwとの違い、値の個数、読み込み先の対応を確認します。
変換後も点群が見えない場合は、行構造、値の個数、点要素、文字コード、改行、単位、座標原点、表示範囲、ファイル容量などを順番に確認します。小さな確認用OBJが読み込めるかを試すことで、構文の問題とデータ量の問題を切り分けやすくなります。
継続的に点群OBJを扱う場合は、書き出し段階でピリオド小数点と空白区切りを使用し、点要素の扱い、座標系、単位を含めた出力条件を共通化することが重要です。