algorithm - Reading lossy file format (PRC), resulting in precision problems -

i got making viewer various 3d file formats, , formats had before didn't pose problem, until came prc file (which 1 of supported 3d formats can embedded in pdfs). can extract data pdf , display models encoded in non-lossy ways, when tried decode call "highly compressed tesselations" run problem think precision problem, don't quite know how fix or solutions.

essentially lossy format, , take original (floating point based) vertex coordinates , -using tolerance value- divide coordinates , round result nearest integer. when traversing mesh encode triangles, first triangle has absolute values stored, remaining triangles based on previous neighbouring triangle , building local coordinate system middle of shared edge being origin, vector along shared edge being x-axis, , triangle normal being z-axis. y-axis result of cross product of those, , using 3 local axis stores coordinate third point of new triangle.

i have system working, , simple models not many triangles works too, models more complex result goes wrong, , seems further away last absolute coordinate, bigger deviation is.

in example picture below can see expected result (as rendered in adobe reader) on left, , mine on right. model has inner , our section, , inner section in case made of 1 absolute triangle followed relative ones (whereas outer section made absolute coords, that's why looks correct in mine), , traversal going inner rings towards outer ones. in adobe render can see lines should more or less radially pointing outward, whereas on mine, starting fourth "circle" things start go wrong:

expected result on left, result on right

i stuck on this, , don't quite know how solve problem. found doing minor changes (such changing double float or vice versa) has huge impact on result, making worse. following spec, says use double precision floating point variables calculations, , use own implementation of calculating square root (needed normalizing axis). example using sqrt function instead of 1 normal maths library, result better (without that, wouldn't near close in pictures shown above).

but wondering if there kind of mathematical aspect not grasping here? or other idea might help? in particular model values seem sufficiently big should not problem of data loss due lack of precision of floating point format. there special cases in spec, if y- or z-axis short (< flt_epsilon) solution has used, again in particular model if < flt_epsilon case never triggered.

just fyi, here description encoding of points (but there no more info on particulars of decoding):

info prc spec on how encode points

any input appreciated. can provide more data, info, examples, spec excerpts etc if needed.

based on previous experiences prc, looks problem object offset (i think called origin offset) being applied in wrong place.

due fact each new vertex based upon previous one, using local coordinate system based on last triangle third point of new triangle, errors seem grow very, in format, , being lossy format doesn't either. in original approach tried calculate triangles, apply offset @ end put correct location, resulting in problems similar yours.

by changing apply offset "absolute vertices" (ie read in unmodified, , sort of act "anchor points" when new triangle started) able fix problem.

of course, being prc there still various other things might need solve, not sure whether have or not. lot of things in official iso spec plain wrong, others not mentioned (for example when supposed recalculate normals rather getting explicit normals file), things huffman compression have bits wrong etc. if can avoid it, better not implement ;-)