LDraw.org Discussion Forums
Rounding Errors in primitives? - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Rounding Errors in primitives? (/thread-24515.html)

Pages: 1 2 3


Rounding Errors in primitives? - Tery Hamer - 2021-03-25

I'm a newbie, so I am nervous about asking... can someone confirm that either A) I'm talking BS, or B) there are rounding errors in the Official LDraw Primitive .dat files?

These are mostly derived from PrimGen2 (- but I haven't checked all).  Some of these files are perhaps 10 years old. Has anybody noticed this before?

AKAIK the standard is for the vectors in .dat files to be shown to 4 decimal places, removing trailing zeros.

For Rings, Cones the vector points for higher values of radii are a multiple of the cos/sin values of the segment angles times the radius. However, it would appear that the rounding is carried out on the cos/sin for the base radius (1, as used for Circle, Disc, etc), and <then> multiplied. That would be a No-No.  For the base and lower radii, the error may be only 0.0001 in a few cases.  But for the higher radii, these rounding errors mount up and impact the third decimal position.

So, BS or BUG?


tery


RE: Rounding Errors in primitives? - Travis Cobbs - 2021-03-25

(2021-03-25, 18:42)Tery Hamer Wrote: I'm a newbie, so I am nervous about asking... can someone confirm that either A) I'm talking BS, or B) there are rounding errors in the Official LDraw Primitive .dat files?

These are mostly derived from PrimGen2 (- but I haven't checked all).  Some of these files are perhaps 10 years old. Has anybody noticed this before?

AKAIK the standard is for the vectors in .dat files to be shown to 4 decimal places, removing trailing zeros.

For Rings, Cones the vector points for higher values of radii are a multiple of the cos/sin values of the segment angles times the radius. However, it would appear that the rounding is carried out on the cos/sin for the base radius (1, as used for Circle, Disc, etc), and <then> multiplied. That would be a No-No.  For the base and lower radii, the error may be only 0.0001 in a few cases.  But for the higher radii, these rounding errors mount up and impact the third decimal position.

Scaling up the rounded values might be intentional. It would allow scaled primitives to perfectly align with non-scaled ones. (I'm not saying for sure that it's intentional, just that it might be.)

I took a quick look at 4-4ring3.dat, and it appears to be multiplying the 4-digit rounded numbers by the radii (3 and 4).


RE: Rounding Errors in primitives? - Philippe Hurbain - 2021-03-25

(2021-03-25, 18:42)Tery Hamer Wrote: For Rings, Cones the vector points for higher values of radii are a multiple of the cos/sin values of the segment angles times the radius. However, it would appear that the rounding is carried out on the cos/sin for the base radius (1, as used for Circle, Disc, etc), and <then> multiplied. That would be a No-No.  For the base and lower radii, the error may be only 0.0001 in a few cases.  But for the higher radii, these rounding errors mount up and impact the third decimal position.
Hi Teri,
Welcome here!
Very good observation... and actually, this is intended. For historical reasons, rings and cones are not normalized. Rounding is done this way for ring and cones (ok, seems weird at first sight!!!) so their vertices match exactly those of scaled normalized primitives (edges, cylis, discs and so on...)


RE: Rounding Errors in primitives? - Tery Hamer - 2021-03-25

(2021-03-25, 19:45)Philippe Hurbain Wrote: Hi Teri,
Welcome here!
Very good observation... and actually, this is intended. For historical reasons, rings and cones are not normalized. Rounding is done this way for ring and cones (ok, seems weird at first sight!!!) so their vertices match exactly those of scaled normalized primitives (edges, cylis, discs and so on...)

Thanks for the explanation - weird though it is. I'll definitely have another look, but - yes - I can see why compatability with other scaled primitives would be necessary.

This arose because I was investigating importing models into Blender and noticing some of the chunkiness.  I thought creating higher resolution files of 1/96 rather than 1/48 might 'improve' the smoothing.  This can, of course, be done piecemeal using custom parameters to PrimGen2, which then produces those 'non-normalised' values,  but I got fed up with all that clicking!!   I thought I'd do it in python, and auto-generate the primitives.  Still a WIP - havent tackled Torus yet - but 3855 Rings, Cones, Circles, Discs, Ndiscs, Chords, Cylinders .dat files take about 5 seconds to generate. 
I'll switch back to generating the 'non-normalised' values. Loads of time to play at this - we seem to have months of Lockdown to go ....

BTW, you seem to have rounded my name from Tery to Teri. Rolleyes


RE: Rounding Errors in primitives? - Chris Dee - 2021-03-26

(2021-03-25, 19:45)Philippe Hurbain Wrote: Hi Teri,
Welcome here!
Very good observation... and actually, this is intended. For historical reasons, rings and cones are not normalized. Rounding is done this way for ring and cones (ok, seems weird at first sight!!!) so their vertices match exactly those of scaled normalized primitives (edges, cylis, discs and so on...)

Yes, this is intentional for the reasons Philo explains.


RE: Rounding Errors in primitives? - Lasse Deleuran - 2021-04-29

Thanks for the explanation! I am using this to improve the automated testing framework that I am currently working on.

However. I have found an issue with 4-4con12.dat. The official file uses the following point in the quads:

-11.0868 1 4.5924

Such as in the following quads:

4 16 -8.4852 1 8.4852 -11.0868 1 4.5924 -12.0107 0 4.9751 -9.1923 0 9.1923
4 16 -11.0868 1 4.5924 -12 1 0 -13 0 0 -12.0107 0 4.9751

And even this conditional line:

5 24 -11.0868 1 4.5924 -12.0107 0 4.9751 -8.4853 1 8.4853 -12 1 0

However. The other conditional lines, where I expect the same point to be used, use:

-11.0866 1 4.5922

such as in:

5 24 -8.4852 1 8.4852 -9.1923 0 9.1923 -4.5922 1 11.0866 -11.0866 1 4.5922
5 24 -12 1 0 -13 0 0 -11.0866 1 4.5922 -11.0866 1 -4.5922


You can get to this point by computing the points without using the tip from this thread. With full decimals through the full calculation, the point should be:


11.08655439013544 1 4.592201188381077

which rounds to 4 decimals as:

-11.0866 1 4.5922

How do I know which method to use in conditional lines?

Please note that other cones, such as the following do not have this issue:
  • 2-4con0.dat
  • 2-4con1.dat
  • 4-4con0.dat
  • 4-4con1.dat
  • 4-4con2.dat
  • 4-4con3.dat
  • 4-4con4.dat
  • 4-4con5.dat
  • 4-4con6.dat
  • 4-4con7.dat
  • 4-4con8.dat
  • 4-4con9.dat
  • 4-4con10.dat
  • 4-4con11.dat

Edit: It seems that for a conditional line A B C D, A and B use the scaling trick from this thread, while the control points C and D do not.


RE: Rounding Errors in primitives? - Travis Cobbs - 2021-04-29

(2021-04-29, 19:59)Lasse Deleuran Wrote: However. I have found an issue with 4-4con12.dat. The official file uses the following point in the quads:

...

Edit: It seems that for a conditional line A B C D, A and B use the scaling trick from this thread, while the control points C and D do not.

I would say that the part is incorrect, and all instances of that coordinate should be the same.


RE: Rounding Errors in primitives? - Lasse Deleuran - 2021-04-29

(2021-04-29, 20:14)Travis Cobbs Wrote: I would say that the part is incorrect, and all instances of that coordinate should be the same.

I have now gone through all the official 4-4con[x].dat files, and these are my findings:

Of the 41 files, 10 of them have the incorrect control points. These are:

4-4con12.dat
4-4con25.dat
4-4con33.dat
4-4con42.dat
4-4con43.dat
4-4con46.dat
4-4con47.dat
4-4con48.dat
4-4con80.dat
4-4con81.dat


RE: Rounding Errors in primitives? - Lasse Deleuran - 2021-04-29

(2021-04-29, 20:14)Travis Cobbs Wrote: I would say that the part is incorrect, and all instances of that coordinate should be the same.

It is easy for me to generate new primitives that have one or the other type of control points using the testing library, so just tell me if you want any of them generated.


RE: Rounding Errors in primitives? - Magnus Forsberg - 2021-04-29

The file claims to be made using PrimGen2, but if I re-create a new version today, I get correct values.