+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Request for new primitives (/thread-29266.html)
Request for new primitives - Manfred Schaefer - 2026-01-02
Hello,
Among the primitives, there is the primitive n-fchrd.dat. This primitive is well suited for creating a transition to, for example, an enclosing circle. Unfortunately, the starting point of the circle segment is always at 0°. Sometimes it would be useful if this starting point were at 22.5°, for example. The circle segment would then go from 22.5° to 67.5°. In the high-resolution version, it would be 7.5° or a multiple thereof.
Rotation that is not equal to a step size of 90° results in rounding errors that can lead to visual errors.
Furthermore, a similar primitive would be useful, forming a circle segment from, for example, 22.5° to -22.5°. The center point of the circle segment would then be at 0°.
My question is whether it would be possible to introduce such primitives.
Best regards,
Manfred
Request for new primitives - Manfred Schaefer - 2026-03-24
Hello,
I’d like to come back to my question above.
What is the procedure if I need primitives, as described above?
Can I simply create them, or are there specific rules to follow?
Question for Travis Cobbs: what about support for primitive substitution in LDView for these new primitives?
Best regards,
Manfred
RE: Request for new primitives - Travis Cobbs - 2026-03-24
(2026-03-24, 20:53)Manfred Schaefer Wrote: Question for Travis Cobbs: what about support for primitive substitution in LDView for these new primitives?
Regarding LDView, the best way to get it to support a new primitive is to create a GitHub issue. I will point out that I haven't spent a lot of time developing LDView for quite a few years now, but its development hasn't stopped.
RE: Request for new primitives - N. W. Perry - 2026-03-25
(2026-03-24, 20:53)Manfred Schaefer Wrote: Hello,
I’d like to come back to my question above.
What is the procedure if I need primitives, as described above?
Can I simply create them, or are there specific rules to follow?
Question for Travis Cobbs: what about support for primitive substitution in LDView for these new primitives?
Best regards,
Manfred
Since your original question raised no objection, I say create them, and let the normal review process bring up any issues of compliance.
RE: Request for new primitives - Magnus Forsberg - 2026-03-25
(2026-03-25, 3:43)N. W. Perry Wrote: Since your original question raised no objection, I say create them, and let the normal review process bring up any issues of compliance.
I think the prim definition spec states that all prim must start at x=1 (and that is equal to 0 degrees) and then continue ccw.
RE: Request for new primitives - Peter Blomberg - 2026-03-27
(2026-01-02, 18:53)Manfred Schaefer Wrote: Among the primitives, there is the primitive n-fchrd.dat. This primitive is well suited for creating a transition to, for example, an enclosing circle. Unfortunately, the starting point of the circle segment is always at 0°. Sometimes it would be useful if this starting point were at 22.5°, for example. The circle segment would then go from 22.5° to 67.5°. In the high-resolution version, it would be 7.5° or a multiple thereof.Any circle segment from -x to x can be replaced with two segments, each starting from 0. There is no need for pre-mirrored and superimposed primitives.
Rotation that is not equal to a step size of 90° results in rounding errors that can lead to visual errors.
Furthermore, a similar primitive would be useful, forming a circle segment from, for example, 22.5° to -22.5°. The center point of the circle segment would then be at 0°.
My question is whether it would be possible to introduce such primitives.
It is a well-known fact that rotation causes vertex mismatches. In most cases, one must choose a smaller primitive and/or use up to 6 decimals in the rotation matrix. There are also a number of tricks one can use to convert some of the most difficult angles to more reasonable angles. Vertex mismatches under 0.001 LDU are negligible.
RE: Request for new primitives - Manfred Schaefer - 2026-03-27
(2026-03-25, 11:04)Magnus Forsberg Wrote: I think the prim definition spec states that all prim must start at x=1 (and that is equal to 0 degrees) and then continue ccw.
I’ll see if I can find anything on this. The questions that remain are: Does this restriction make sense, and do all parts of a primitive have to be visible?
Regards
Manfred
RE: Request for new primitives - Manfred Schaefer - 2026-03-27
(2026-03-27, 14:53)Peter Blomberg Wrote: Any circle segment from -x to x can be replaced with two segments, each starting from 0. There is no need for pre-mirrored and superimposed primitives.
It is a well-known fact that rotation causes vertex mismatches. In most cases, one must choose a smaller primitive and/or use up to 6 decimals in the rotation matrix. There are also a number of tricks one can use to convert some of the most difficult angles to more reasonable angles. Vertex mismatches under 0.001 LDU are negligible.
Sorry, but I don’t quite understand your answer.
If I need a circular segment ranging from 22.5° to 45°, the only option I can see is to use the primitive that ranges from 0° to 22.5° and rotate it by 22.5°. However, this rotation causes rounding errors, which should be avoided.
What’s more, the number of decimal places should be kept to a minimum, otherwise this can lead to further problems. As is currently the case with flat designs, where the limit is three, if I remember correctly.
Regards
Manfred
RE: Request for new primitives - Peter Blomberg - 2026-03-27
(2026-03-27, 15:18)Manfred Schaefer Wrote: Sorry, but I don’t quite understand your answer.This is an example of converting the challenging angles to easier angles.
If I need a circular segment ranging from 22.5° to 45°, the only option I can see is to use the primitive that ranges from 0° to 22.5° and rotate it by 22.5°. However, this rotation causes rounding errors, which should be avoided.
What’s more, the number of decimal places should be kept to a minimum, otherwise this can lead to further problems. As is currently the case with flat designs, where the limit is three, if I remember correctly.
You'd rotate the prim by 45°.
You are correct in that 3 decimals are usually enough for vertex coordinates. In rotation matrices, however, more decimals (up to 6, sometimes even 7 if motivated properly) can be used to maintain reasonable accuracy of the resulting vertices.
RE: Request for new primitives - Peter Blomberg - 2026-03-27
(2026-03-27, 15:09)Manfred Schaefer Wrote: ... do all parts of a primitive have to be visible?The simple answer is: no, all parts of a primitive need not be visible. There are acceptable use cases where part of a primitive is obscured by other geometry. Avoid T-junctions where an edge of a non-visible surface goes along the surface of a visible surface as this creates optical flickering.
The more accurate answer would include considerations for minimizing/balancing the need for intersections with part complexity (number of lines required to create a particular geometry without intersections). If the part is transparent in any color, then superfluous interior surfaces should specifically be avoided as much as possible.
RE: Request for new primitives - Orion Pobursky - 2026-03-27
(2026-03-27, 15:27)Peter Blomberg Wrote: more decimals (up to 6, sometimes even 7 if motivated properly) can be used
This is incorrect. Anything >5 decimals is contrary to the library spec and this is enforced on submit.
Think of it this way: 1 ldu = .4mm. At 6 decimal places, 0.000001 ldu = 0.0000004 mm or .4 nm which is overkill for precision. Any gaps at this level are insignificant.
RE: Request for new primitives - Magnus Forsberg - 2026-03-27
(2026-03-27, 15:09)Manfred Schaefer Wrote: I’ll see if I can find anything on this.
"Where this fraction is less than an entire circle, the primitive starts at {+x,0} and progresses in a conterclockwise direction when viewed from above {-y}."
https://wiki.ldraw.org/wiki/Primitives_Reference#Curved_primitives
RE: Request for new primitives - Peter Blomberg - 2026-03-27
(2026-03-27, 15:56)Orion Pobursky Wrote: This is incorrect. Anything >5 decimals is contrary to the library spec and this is enforced on submit.So the specifications have changed since a year ago?
Think of it this way: 1 ldu = .4mm. At 6 decimal places, 0.000001 ldu = 0.0000004 mm or .4 nm which is overkill for precision. Any gaps at this level are insignificant.
Also, it wasn't about the vertex coordinates. It was about the rotation matrix. Sometimes, when one rotates and scales a primitive, the added decimals in the rotation matrix may be needed to achieve 3 decimals on the vertices. I've also encountered more than 5 decimals when the overall part has 3-fold, 5-fold, and 7-fold rotational symmetry. Have all such cases been updated to 5 decimals?
RE: Request for new primitives - Manfred Schaefer - 2026-03-27
(2026-03-27, 15:27)Peter Blomberg Wrote: This is an example of converting the challenging angles to easier angles.
You'd rotate the prim by 45°.
You are correct in that 3 decimals are usually enough for vertex coordinates. In rotation matrices, however, more decimals (up to 6, sometimes even 7 if motivated properly) can be used to maintain reasonable accuracy of the resulting vertices.
I need a circular segment from 22.5° to 45°.
If I understand your explanation correctly, I would end up with a segment from 45° to 67.5°.
This means I would have to reflect a circular segment from 0° to 22.5° across the x-axis and then rotate it by 45° about the y-axis. However, a rotation of 45° implies a factor of 0.707... which results in too many decimal places.
Regards
Manfred
RE: Request for new primitives - Manfred Schaefer - 2026-03-27
(2026-03-27, 16:05)Magnus Forsberg Wrote: "Where this fraction is less than an entire circle, the primitive starts at {+x,0} and progresses in a conterclockwise direction when viewed from above {-y}."
https://wiki.ldraw.org/wiki/Primitives_Reference#Curved_primitives
Thanks for your answer
From the link in your reply:
[...] Where the naming convention includes a prefix of the form n-f, this indicates the fraction (n/f) of the circle drawn by the primitive. Where this fraction is less than a full circle, the primitive starts at {+x,0} and proceeds in an anti-clockwise direction when viewed from above {-y}. [...]
This merely states that this prefix exists, but not that other prefixes are prohibited.
There is an error in the following section, or perhaps I am misunderstanding it:
[...] For example, use 3-16XXXX.dat rather than combining 1-8XXXX.dat with 1-16XXXX.dat rotated by 22.5 degrees.
3/16 corresponds to 67.5′
1/8 corresponds to 45°
1/16 corresponds to 22.5°
From this, I conclude that if I want to combine 3/16 with 1/8 and 1/16, I would have to rotate the 1/16 by 45°. Or if I were to combine 1/16 with 1/8, I would have to rotate the 1/8 by 22.5°.
Regards
Manfred
RE: Request for new primitives - Orion Pobursky - 2026-03-27
(2026-03-27, 16:36)Peter Blomberg Wrote: So the specifications have changed since a year ago?
Also, it wasn't about the vertex coordinates. It was about the rotation matrix. Sometimes, when one rotates and scales a primitive, the added decimals in the rotation matrix may be needed to achieve 3 decimals on the vertices. I've also encountered more than 5 decimals when the overall part has 3-fold, 5-fold, and 7-fold rotational symmetry. Have all such cases been updated to 5 decimals?
It's always been >5 is not allowed. The only change is that the PT is now automatically enforcing this standard.
I will say that it has been unevenly enforced.
RE: Request for new primitives - Rene Rechthaler - 2026-03-27
the nice thing about these primitives is that they can be oriented and rotated both ways...
a 22.5 to 45° prim can be done by rotating a 1-16 prim by 22.5° or mirror it to -22.5° and then rotating it by 45°.
a 22.5->45 prim is almost the same as a 45->22.5, but they have different rotation matrices.
as the starting point (the 0° position at 1 0 0) gets scaled by the rotation matrix, it has the clearer vertices than the far end, which has many decimals (from multiplying a fraction with a fraction)
RE: Request for new primitives - Peter Blomberg - 2026-03-28
(2026-03-27, 16:45)Manfred Schaefer Wrote: I need a circular segment from 22.5° to 45°.As Réné already explained, there is more to it than just rotation. You also have mirroring and scaling. Mirroring inverts the rotation from ccw to cw as you figured out.
If I understand your explanation correctly, I would end up with a segment from 45° to 67.5°.
This means I would have to reflect a circular segment from 0° to 22.5° across the x-axis and then rotate it by 45° about the y-axis. However, a rotation of 45° implies a factor of 0.707... which results in too many decimal places.
Yes, if the scaling is 1.00, then the entry in the rotation matrix is sin(45°)=cos(45°)=0.7071, which is less than 5 decimals. However, most of the time, the scaling isn't 1.00, but something else. In those cases, you would round or truncate it to 5 decimals.
Now comes the hard part. While the scaling in one unique use case may be such that the entry in the rotation matrix is more accurate for a 22.5° rotation, you always have to remember that there are two entries in the rotation matrix; a*sin(x) and a*cos(x). Usually, when sin(x)=cos(x), i.e. x=45°, you end up with less distinct entries in the rotation matrix. This makes it easier to combine multiple rotated primitives without introducing unnecessary microgaps.
RE: Request for new primitives - Peter Blomberg - 2026-03-28
(2026-03-27, 17:06)Orion Pobursky Wrote: It's always been >5 is not allowed.I'm surprised. We had lots of discussion about the x+ decimals last year, yet nobody pointed out such a limit. The specs didn't explicitly state it at the time. We came to the conclusion that 8 and 10 decimals were too many and could be the reason for a hold vote. At the time, 6 decimals outside a rotation matrix was not a reason for a hold vote.
RE: Request for new primitives - Peter Blomberg - 2026-03-28
(2026-03-27, 16:59)Manfred Schaefer Wrote: There is an error in the following section, or perhaps I am misunderstanding it:As it is written, you are grammatically correct. There is an error. The main point is that you should use one larger primitive instead of two smaller primitives where one of the smaller primitives is rotated to a non-90-degree angle.
[...] For example, use 3-16XXXX.dat rather than combining 1-8XXXX.dat with 1-16XXXX.dat rotated by 22.5 degrees.
RE: Request for new primitives - Orion Pobursky - 2026-03-28
(2026-03-28, 9:40)Peter Blomberg Wrote: I'm surprised. We had lots of discussion about the x+ decimals last year, yet nobody pointed out such a limit. The specs didn't explicitly state it at the time. We came to the conclusion that 8 and 10 decimals were too many and could be the reason for a hold vote. At the time, 6 decimals outside a rotation matrix was not a reason for a hold vote.
I was wrong. The >5 error limit is new.
However, there was a discussion, started by you:
https://forums.ldraw.org/thread-29110.html
It ended with the spec as currently written.
As always, I am open to more discussion on this but it should happen on that thread.
RE: Request for new primitives - Willy Tschager - 2026-03-28
(2026-03-28, 9:40)Peter Blomberg Wrote: I'm surprised. We had lots of discussion about the x+ decimals last year, yet nobody pointed out such a limit. The specs didn't explicitly state it at the time. We came to the conclusion that 8 and 10 decimals were too many and could be the reason for a hold vote. At the time, 6 decimals outside a rotation matrix was not a reason for a hold vote.
6 digits were always a "bad figure". Above a "Wayback" from 2 years ago.
w.
RE: Request for new primitives - Mark Kennedy - 2026-04-13
Looking at part 46379 on the tracker it seems that a primitive like this one could be useful.
RE: Request for new primitives - Magnus Forsberg - 2026-04-13
(2026-04-13, 5:05)Mark Kennedy Wrote: Looking at part 46379 on the tracker it seems that a primitive like this one could be useful.
What part are you looking at? That number seems wrong.
RE: Request for new primitives - Mark Kennedy - 2026-04-13
(2026-04-13, 16:09)Magnus Forsberg Wrote: What part are you looking at? That number seems wrong.Sorry, here is the link:
https://library.ldraw.org/parts/46379