+- 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: Vertex precision (/thread-29110.html)
Vertex precision - Peter Blomberg - 2025-10-09
For free-form stand-alone vertexes, one decimal is usually enough. However, when a vertex is defined by a circular primitive, rotated subparts or the intersection of slanted surfaces, then more decimals are needed. I've tried working with three decimals, but tools like Edger2 will not always recognize the presence of a cond line rounded to three decimals. Similar results with overlap- and gap-finding tools.
The official parts library specifications state "In general, three decimal places are sufficient for parts, subparts, and primitives representing portions of parts that are not intended to be scaled (for example, studs, pegs, peg-holes, clips, hinge ends, etc.). Four decimal places should be used for high-res primitives and any primitives designed to be scaled (for example, cylinder sections, boxes, rectangles, discs, edges, etc.) as this allows such primitives to be scaled by a factor of ten while still preserving three decimal places of accuracy.".
I'd like to amend this by allowing 4 decimal places to be used for
- vertexes on a rotational plane of symmetry (e.g. 30, 45, and 72 degree planes),
- intersections calculated by isecalc,
- any vertex that is defined by a scaled primitive.
The first one because this will avoid gaps/overlap when multiple similar subfiles are put together in a larger assembly.
The second one to have an accurate edge line where two surfaces intersect each other.
The third one to avoid gaps/overlap next to any scaled primitive. This is also needed for all cond lines that have a point or a control point on such a vertex.
If we all agree, can this be made official?
RE: Vertex precision - Willy Tschager - 2025-10-09
If 1 LDU is 0,4 mm, how much is 0.0001 LDU in mm?
++++++++++++++++++++++++++++++++++
To convert 0.0001 LDU to millimeters, you can multiply by the given conversion factor (1 LDU = 0.4 mm).
So, the calculation is:
0.0001 LDU x 0.4 mm/LDU = 0.00004 mm
Therefore, **0.0001 LDU is equal to 0.00004 mm**
++++++++++++++++++++++++++++++++++
w.
RE: Vertex precision - Orion Pobursky - 2025-10-09
Rather than try to codify all cases of what precision to to use when. I'd prefer to keep it as a recommendation. The author can justify why they are departing from recommendation upon submit. Regardless, no hold votes should be cast based solely on decimal precision.
RE: Vertex precision - Peter Blomberg - 2025-10-10
Indeed, as Willy points out the physical distance is negligible as is the impact on file size. However, the official parts library specifications do state "Every effort must be made to remove overlapping co-planar polygons (line type 3 or 4). Where overlapping polygons are unavoidable, the overlap must be kept to the absolute minimum.".
Having gaps and overlap at all these interfaces causes visual rendering issues. Sure, white dots and lines between surfaces and color-switching surfaces are rendering issues and are not necessarily seen when using the part in a computational build.
Sticking to three decimals would require Edger2, gap-finding, and overlap-finding algorithms to be adjusted. It would also mean that any gap or overlap less than 0.001 LDU is acceptable. Also, any edge line or conditional line would be allowed to be less than 0.001 LDU off target. This means that an edge line can "disappear" someway along its length or not be visible at all because the end points are in front of and/or behind a surface. These rendering issues will make the visual inspection of a part much more laborious.
This is primarily a tool set issue for me. If the tools available in LDPE aren't actually usable, then it makes parts authoring and parts reviewing much more laborious.
RE: Vertex precision - Philippe Hurbain - 2025-10-10
Regarding all this kind of problem: "if a part looks good, it is good." Period.