LDraw.org Official Parts Library Standards: General

[Roland Melkert]

It's time to start discussing the LDraw.org Official Parts Library Standards.

Only nitpick I noticed at first read trough:

Leading zeros unless immediately before the decimal point must be removed (i.e. 1.5, not 01.5).

Found this a bit confusing, so 0.123,  00000.123  and .123 are all allowed?

Maybe:

Leading zeros unless at most one immediately before the decimal point must be removed (i.e. 1.5, not 01.5).

[Orion Pobursky]

Found this a bit confusing, so 0.123,  00000.123  and .123 are all allowed?

The first and third are ok, the second is not. This is already enforced by the PT submit validation.

Follow up: Should the PT autocorrect these errors and issue a warning instead?

Good feedback.

[Roland Melkert]

Follow up: Should the PT autocorrect these errors and issue a warning instead?

I think this can be an automatic correction (with a proven algorithm).

Maybe followed with a message about what has been corrected?

[Orion Pobursky]

Only nitpick I noticed at first read trough:


Found this a bit confusing, so 0.123,  00000.123  and .123 are all allowed?

Maybe:

I just realized that this is skipping ahead to the General section. I'll move these posts when I open discussion on that section.

[Gerald Lasser]

All part files in the LDraw Parts Library are required to carry the .dat extension.

we do have the texture maps as "png" as well

[Orion Pobursky]

Since a few people jumped the gun, I'll open the General sections for comments

https://library.ldraw.org/documentation/...ds/general

Some comments from the intro thread have been moved here.

[Travis Cobbs]

Suggestions for the General page:

Update:

Files shall not exceed five decimal places

to:

Numbers in files shall not exceed five decimal places

Update:

Four decimal places (at a minimum) shall be used for high-res primitives ...

to:

Four decimal places (at a minimum) shall be used in high-res primitives ...

Regarding this:

If the geometry is tangent to the curve. If it is sloped further, then a complementary conditional line shall be placed on the edge of that geometry, with the control points past the edge of the geometry configured to be tangent to the curve, and the two end points of the conditional placed to exactly overlap the complementary conditional line on the edge of the curved primitive.

First of all, the first sentence seems to be missing its conclusion (, "then ..."). Secondly, I wanted to verify that these instructions are accurate (along with the sample image). It seems to me that the control point that is on the curve side should be tangent to the curve and not on the next curve vertex. The provided instructions mean that sometimes both overlapping conditionals will be rendered at the same time.

For hinge or hinge like parts, the origin should be at the rotation point**

The two asterisks at the end are never defined.

Line types 2 and 5 must use colour 24.

I thought that line type 2 was occasionally allowed to use specific colors in patterns. Is this not the case?

[Chris Böhnke]

Stud Orientation:
Missing a few words?
"The individual studs on a part should be rotated such that the stud logo appears is [like] it would [be] on the real part."

Duplicate Lines:
Feels a bit random at it's current place in the list. Shouldn't this be more along the basic rules at the top?

Header Meta Commands:
So, older relics like "0 !CMDLINE -c14" are officially gone? Should this be mentioned for older parts?

Colours:

1. "[...] but does not include the colours of paint used to decorate parts or ink used on stickers."
   It gets a bit confusing when we consider that for example 80-82 (Metallic Silver, Gold, Green) are in fact NOT available as plastic colours, but are required due to their special nature.
   
   I know this has been there for a long time, but might I take this opportunity to ask why this rule is required? And not allow for example 163 Dark Yellow in LDConfig, where it's confirmed the colour exists and has an official name and number? (Rylie Howerter: https://www.flickr.com/photos/[email protected]/).
   
   My main issue with this rule is, that I would rather see these "confirmed" cases (there's also a very common shade of greenish light blue on 1980-1997 patterns, not part of the normal palette) to use a clearly defined colour rather than direct colour. I think it would help in consistency and make certifying these parts a bit easier.
   
   As a side note, the rules do not specify colours which do exist in plastic form, but never appeared in sets (as far as knowledge goes), like "108 Earth Yellow" (https://www.flickr.com/photos/[email protected]/)
   
   
2. "In general, metallic colours on stickers, patterned parts, and other printed materials should use the LDraw Metallic Colours and not Chrome or Pearl colours."
   Personally I would prefer the Pearl colours part to be a "must not" instead of "should not", as this should not be possible to be used as ink anyways (chrome is okay in edge cases). Opinions?
   

[Orion Pobursky]

First of all, the first sentence seems to be missing its conclusion (, "then ..."). Secondly, I wanted to verify that these instructions are accurate (along with the sample image). It seems to me that the control point that is on the curve side should be tangent to the curve and not on the next curve vertex. The provided instructions mean that sometimes both overlapping conditionals will be rendered at the same time.

The above needs to be discussed.  All the rest of your comments are fixed.

[Orion Pobursky]

Colours:

1. "[...] but does not include the colours of paint used to decorate parts or ink used on stickers."
   It gets a bit confusing when we consider that for example 80-82 (Metallic Silver, Gold, Green) are in fact NOT available as plastic colours, but are required due to their special nature.
   
   I know this has been there for a long time, but might I take this opportunity to ask why this rule is required? And not allow for example 163 Dark Yellow in LDConfig, where it's confirmed the colour exists and has an official name and number? (Rylie Howerter: https://www.flickr.com/photos/[email protected]/).
   
   My main issue with this rule is, that I would rather see these "confirmed" cases (there's also a very common shade of greenish light blue on 1980-1997 patterns, not part of the normal palette) to use a clearly defined colour rather than direct colour. I think it would help in consistency and make certifying these parts a bit easier.
   
   As a side note, the rules do not specify colours which do exist in plastic form, but never appeared in sets (as far as knowledge goes), like "108 Earth Yellow" (https://www.flickr.com/photos/[email protected]/)
   
   
2. "In general, metallic colours on stickers, patterned parts, and other printed materials should use the LDraw Metallic Colours and not Chrome or Pearl colours."
   Personally I would prefer the Pearl colours part to be a "must not" instead of "should not", as this should not be possible to be used as ink anyways (chrome is okay in edge cases). Opinions?
   

Let's discuss the above.

Stud Orientation wording fixed, Duplicate lines section moved, and missing hyperlink added to Header META section.

[Orion Pobursky]

Found this a bit confusing, so 0.123,  00000.123  and .123 are all allowed?

This is now clarified

[Peter Blomberg]

In the format section, "Trailing zeros must be removed" is a bit inaccurate. We mean that trailing decimal zeros or unnecessary trailing zeros must be removed. Maybe "trailing zeros to the right of the decimal point must be removed".
Also, there is no requirement to remove the point after a number, i.e. the present text suggests that "10." would be valid.

I'd change "A single leading zero before the decimal point is optional" to "The zero before the decimal point is optional"

Considering the leftmost picture below, suppose we call the next joint/bend to the right of the line ABCD as line HIJK, then I'd prefer a statement either allowing or disallowing a conditional line from H to K, i.e. without any line from I to J which is usually hidden away inside some other geometry. Personally, I'd prefer to require two separate conditional lines, one for HI and another for JK. This practice/preference has been unevenly enforced.
   

Orientation/Origin
It would be good to mention e.g. the standard expected for wheels.
I'd prefer mentioning the expectation that studless parts have their origin at the bottom of the part if the bottom can be attached to studded parts.
Should the preview keyword be mentioned here?

Why is the origin so late in the text? Since it is about the file rather than single lines, I'd expect it to be before or at the start of the geometry section.
What about

• file name, encoding, extensions
  
• origin, orientation
  
• meta commands
  
• geometry
  
• numbers
  
• colors
  

The 'duplicate lines' should be put under 'geometry'.

I also noticed overlap between the 'Header META commands' and the Official Library Header Specification. Do they really need to be two separate pages? Is this some kind of work in progress?

[Willy Tschager]

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.

[Manfred Schaefer]

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

[Orion Pobursky]

The draft says this:

Numbers in files shall not exceed five decimal places

Four decimal places (at a minimum) shall be used in high-res primitives and any other file that is designed to be scaled (for example, cylinder sections, boxes, rectangles, discs, edges, etc.)

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.

For all other files, three decimal places are sufficient. Any file exceeding this recommendation (except in cases to match primitive vertexes) should have a justification by the author.

I think this is just fine.  If we want stronger wording, the last line can change to this:

For all other files, three decimal places shall not be exceeded with the exception of matching primitive vertexes or on a case-by-case basis with justification by the author.

[Manfred Schaefer]

The draft says this:

I think this is just fine.  If we want stronger wording, the last line can change to this:

In my view, the description is accurate, but given my limited experience, I cannot say whether this might cause problems during implementation.
In Willy’s example above, the exception would apply, as the triangle is attached to a primitive and the contact points are determined by the primitive.
However, if, for example, a pattern is created for a minifigure head without using primitives, I can create it in 2D with two or at most three decimal places. But if I then rotate the individual rectangles of the pattern according to the angles of the individual head surfaces, the limit of three decimal places may be exceeded. If reduced to three decimal places, a point could shift out of the plane. To avoid this, I would have to provide a justification for using more than three decimal places and hope that this justification is accepted by the reviewers.
In another post, I had asked about the possibility of creating a new primitive. I wanted a 1/16th of a circular segment, but one that ranges from 22.5° to 45°. Here, it was suggested that I rotate a 1/16th circular segment by 45° and then mirror it along the Z-axis. Rotating it by 45° would then require a resolution of more than five decimal places. That would again be an exceptional case and would probably require justification and approval.
I don’t know whether the viewers impose a limit on the number of decimal places, or what value makes sense under which conditions.
Regards,
Manfred