(2026-05-22, 7:16)Willy Tschager Wrote: 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:
- 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.
Hello,
I’m no expert and have so far only tried my hand at printing. In two-dimensional space, I believe two decimal places are sufficient; in three-dimensional space, I think three to four decimal places are required. You have already touched upon what I consider to be the crucial point. As long as I do not use primitives, I have control over the number of decimal places. If I use primitives, the vertices are predefined and I cannot change them.
If you limit the number of decimal places, gaps will inevitably arise, or in three-dimensional space the point will move out of the plane.
It would first need to be defined at what point a gap is no longer a gap, because this deviation is accepted. The same applies to the point in three-dimensional space: how far is it allowed to protrude from the plane (length of the plane’s normal vector)?
Best regards
Manfred