さまざまな3Dファイル形式のビューアを作成しましたが、前回の形式では問題はありませんでした。 PDFに埋め込むことができるサポートされている3D形式の1つです）。 PDFからすべてのデータを抽出し、非損失の方法でエンコードされたモデルを表示することができますが、「高圧縮テッセレーション」と呼ばれるものをデコードしようとすると、精度の問題はあると思いますが私はそれを修正する方法や解決策を探す場所をあまり知らない。精度の高い問題の原因となる損失の多いファイル形式（PRC）の読み取り
本質的にはロッシーな形式で、元の（浮動小数点ベースの）頂点座標をとり、許容値を使用してそれらの座標を分割し、結果を最も近い整数に丸めます。すべての三角形を符号化するためにメッシュをトラバースする場合、最初の三角形のみが絶対値を格納し、残りの三角形は常に前の隣接する三角形に基づいており、共有エッジの中央を原点とするローカル座標系を構築し、共有されるエッジはx軸であり、三角法線はz軸である。 y軸は、それらの積の単なる結果であり、これら3つのローカル軸を使用して、新しい三角形の第3の点の座標を格納する。
私はシステムが一般的に動作していますが、あまりにも多くの三角形を持たない単純なモデルでは、モデルも複雑になり次第、座標が大きいほど、偏差は大きくなります。
この下の図の例では、左側にAdobe Readerで表示される予想される結果が表示され、右側には表示されます。このモデルは本質的に内部と私たちのセクションを持ち、この場合の内部セクションは1つの絶対三角形とそれに続く相対的な三角形で構成されています（外側のセクションは主に絶対座標で作られています。内側のリングから外側のリングに向かうトラバーサル。
Expected result on the left, my result on the right
私は現在、立ち往生しています：アドビシステムズ社では4番目の「円」物事がうまくいかないために開始についてから始めて、鉱山のに対し、行が多かれ少なかれ半径方向外方を向いされるべきであると見ることができますレンダリングこの問題を解決する方法はあまり知られていません。マイナーな変更（floatに変更する、またはその逆を変更するなど）が結果に大きな影響を与え、すぐに大幅に悪化させることが判明しました。しかし、基本的には、すべての計算に倍精度浮動小数点変数を使用し、（軸を正規化するために必要な）平方根を計算する独自の実装を使用するという仕様を守っています。例えば、通常の数学ライブラリの代わりにsqrt関数を使うことで、結果は既に良いものになっています（そうでなければ、上の写真のように近くなることはありません）。
私はここで把握していないいくつかの種類の数学的な側面があるのだろうかと思っていましたか？助けてくれる他のアイデアですか？その特定のモデルにおいても、値はすべて十分に大きいように見えるので、浮動小数点形式の精度の欠如によるデータ損失の問題であってはならない。また、y軸またはz軸が短すぎる場合（< FLT_EPSILON）別の解決法を使用する必要があるスペシャルケースもありますが、この特定のモデルでは、< FLT_EPSILONのケースは決してトリガーされません。
ちょうどFYI、ここでのポイントのエンコーディングに関する記述である（ただし、デコードの詳細についてこれ以上の情報はありません）：
info from the PRC spec on how to encode points
任意の入力がはるかに高く評価されるだろう。私は、必要に応じてより多くのデータ、情報、例、仕様の抜粋などを提供することができます。
この問題は実際にPDFに関連していません。 PRCコンテンツは、自己完結型ブラックボックスとしてPDFファイルに埋め込まれているため、PRCレンダリングに影響を与えるデータはPDFにはありません。 Acrobatの3Dビューアでは、レンダリングの権利を得るために数学的な調整が行われている可能性がありますが、PDFとは関係ありません。 – iPDFdev
Okはタグを削除します（実際には、PRC/U3Dのレンダリングに影響を及ぼすいくつかのデータがPDF内にありますが、たとえば、使用するビューポート、カメラのパースペクティブ、または変更するために実行できるスクリプトに影響を与える3Dアノテーション内容 - しかし、それはこの場合は関係ありません） –