2016-04-25 64 views
3

我開始製作各種3D文件格式的查看器,並且這些格式我以前沒有造成問題,直到我來到PRC文件(它是支持的3D格式之一,可以嵌入到PDF中)。我可以從PDF中提取所有數據,並顯示那些以非損失方式編碼的模型,但是當我試圖解碼他們所謂的「高度壓縮的Tesselations」時,我遇到了一個我認爲是精確問題的問題,但我不知道如何解決它或在哪裏尋找解決方案。閱讀有損文件格式(PRC),導致精度問題

本質上它是一種有損格式,它們所做的是採用原始(基於浮點的)頂點座標和 - 使用公差值 - 將這些座標除以它並將結果四捨五入爲最接近的整數。當遍歷網格以編碼所有三角形時,只有第一個三角形存儲了絕對值,其餘三角形總是基於前一個相鄰三角形並且建立局部座標系,共享邊的中間是原點,矢量沿共享邊緣是x軸,三角形法線是z軸。 y軸只是這些交叉乘積的結果,並且使用這3個局部座標軸來存儲新三角形第三點的座標。

我的系統一般都能正常工作,對於三角形不太多的簡單模型,它的效果也不錯,但只要模型變得越來越複雜,結果就會全部錯誤,而且看起來距離最後一個絕對座標,偏差越大。

在下面的示例圖片中,您可以在左側看到預期結果(在Adobe Reader中呈現),在右側看到我的預期結果。這個模型基本上有一個內部部分和一個我們的部分,在這種情況下,內部部分由一個絕對三角形組成,後面是相對的部分(而外部部分大部分是由絕對座標組成的,這就是爲什麼它在我的看法是正確的),以及從內環到外環的遍歷。在Adobe渲染,你可以看到線應該或多或少徑向指向向外,而在礦山,大約從第四個「圈」起,事情開始出問題:

Expected result on the left, my result on the right

我目前卡住對此,並不太瞭解如何解決這個問題。我發現做一些細微的改變(比如將double改爲float,反之亦然)會對結果產生巨大的影響,並且很快就會變得更糟。但基本上我遵循這個規範,該規範說所有計算都使用雙精度浮點變量,並且也使用他們自己的計算平方根(標準化軸所需的)的實現。例如,通過使用它們的sqrt函數而不是正常的數學庫中的結果,結果已經更好了(沒有這一點,我甚至不會像上面顯示的圖片那樣接近)。

但我想知道是否有某種數學方面,我不抓這裏?或者其他一些可能有用的想法?同樣在這個特定的模型中,這些值看起來都足夠大,所以它不應該是由於浮點格式精度不夠造成的數據丟失問題。此外,在規格中還有一些特殊情況,如果y軸或z軸太短(< FLT_EPSILON),則必須使用另一種解決方案,但在此特定型號中,如果不觸發FLT_EPSILON情況。

僅供參考,這裏是關於點的編碼描述(但對解碼的細節沒有更多的信息):

info from the PRC spec on how to encode points

任何輸入將不勝感激。如果需要,我可以提供更多數據,信息,示例,規範摘錄等。

+0

這個問題並沒有真正與PDF相關。中國內容作爲獨立黑盒嵌入PDF文件中,PDF中沒有影響PRC呈現的數據。 Acrobat中的3D查看器可能會使用一些數學調整來獲取渲染權,但它們與PDF無關。 – iPDFdev

+0

Ok將刪除標籤(雖然實際上PDF中有一些影響PRC/U3D渲染的數據,例如影響使用哪個視口,相機透視圖或可執行的腳本以修改的幾個3D註釋內容 - 但它在這種情況下是不相關的) –

回答

2

根據我以前對PRC的經驗,這看起來非常像是在錯誤的地方應用了對象偏移量(我認爲它被稱爲原點偏移量)的問題。

由於每個新頂點都基於前一個頂點,因此使用基於最後一個三角形的局部座標系來獲得新三角形的第三個點,錯誤似乎在此非常快速地增長格式,並且是一種有損格式也無濟於事。在我原來的方法中,我試圖計算所有的三角形,然後應用最後的偏移量將它放到正確的位置,導致出現類似於你的問題。

通過改變它來將偏移量應用到「絕對頂點」(即在未修改時讀取的那些,以及當新三角形開始時作爲「錨點」的行爲),我能夠解決這個問題。

當然,作爲中華人民共和國還有其他各種你可能需要解決的問題,我不確定你是否已經有了。官方ISO規範中的很多內容都是錯誤的,其他人沒有提到(例如,當你應該重新計算法線而不是從文件中獲得明確的法線),諸如霍夫曼壓縮之類的東西就會出現錯誤等等。如果可以的話避免它,那麼最好不要實現它;-)

+0

啊,這可能是真的嗎?讓我檢查一下,並在以後回覆給你 –

+0

是的,事實證明,幫助,還有一些其他的事情,我需要數字但是那個簡單的小修補幫助了我。讓我感覺不好自己沒有意識到 –