Guys,
The discussion about precision and the number of digits in an LDraw file is probably as old as the standard itself, and we have seen the pendulum swing back and forth on how strictly it is handled. I came across this part:
[https://library.ldraw.org/parts/30885](h...rts/30885)
with its six digits (probably to avoid triggering warnings in Edger) in the main file and four digits in the subfiles. This equates to 0.00004 mm. I understand the desire to be as accurate as possible, but we also have to consider efficiency and consistency. We have files with 2 decimal places, some with 3, and some with 4. I believe the root of the problem lies in the vagueness of the specs, which currently offer recommendations rather than strict rules:
https://www.ldraw.org/article/512.html#precision
To ease the review process, I'd like to propose the following changes to the specs:
I'm open to discussing the exact number of digits—I'm fine with 3, 4, or 5 digits for general geometry—but we need to move away from mere recommendations and establish a firm rule. Some concerns have been raised about rotated subfiles, and the fact that general geometry meeting primitives may require 5 digits, as seen here:
1 11 0 0 0 13.1 0 0 0 1 0 0 0 12.9 1-8chrd.dat
1 12 0 0 0 13.1 0 0 0 1 0 0 0 12.9 1-8tndis.dat
3 13 13.1 0 0 9.26301 0 9.12159 10 0 0
Fair point, but personally, I can live with a tiny mismatch if it means I don't have to constantly check during the review process whether they meet a specific requirement. The fewer exceptions, the better.
What are your 2 cents?
w.
The discussion about precision and the number of digits in an LDraw file is probably as old as the standard itself, and we have seen the pendulum swing back and forth on how strictly it is handled. I came across this part:
[https://library.ldraw.org/parts/30885](h...rts/30885)
with its six digits (probably to avoid triggering warnings in Edger) in the main file and four digits in the subfiles. This equates to 0.00004 mm. I understand the desire to be as accurate as possible, but we also have to consider efficiency and consistency. We have files with 2 decimal places, some with 3, and some with 4. I believe the root of the problem lies in the vagueness of the specs, which currently offer recommendations rather than strict rules:
https://www.ldraw.org/article/512.html#precision
To ease the review process, I'd like to propose the following changes to the specs:
- General geometry (such as lines, triangles, quadrilaterals, conditional lines, and subfiles) must not exceed three decimal places. Any file exceeding this limit (except in cases required to match primitive vertices) must include a justification by the author.
- High-res primitives and any other files designed to be scaled (for example, cylinder sections, boxes, rectangles, discs, edges, etc.) must not exceed four decimal places. This allows such primitives to be scaled by a factor of ten while still preserving three decimal places of accuracy. The primitives reference indicates which primitive families are not designed to be scaled.
- No number in any file must exceed five decimal places.
I'm open to discussing the exact number of digits—I'm fine with 3, 4, or 5 digits for general geometry—but we need to move away from mere recommendations and establish a firm rule. Some concerns have been raised about rotated subfiles, and the fact that general geometry meeting primitives may require 5 digits, as seen here:
1 11 0 0 0 13.1 0 0 0 1 0 0 0 12.9 1-8chrd.dat
1 12 0 0 0 13.1 0 0 0 1 0 0 0 12.9 1-8tndis.dat
3 13 13.1 0 0 9.26301 0 9.12159 10 0 0
Fair point, but personally, I can live with a tiny mismatch if it means I don't have to constantly check during the review process whether they meet a specific requirement. The fewer exceptions, the better.
What are your 2 cents?
w.
LEGO ergo sum