Request for new primitives

[Manfred Schaefer]

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

[Manfred Schaefer]

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

[Travis Cobbs]

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.

[N. W. Perry]

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.

[Magnus Forsberg]

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.

[Peter Blomberg]

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.

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.

[Manfred Schaefer]

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

[Manfred Schaefer]

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

[Peter Blomberg]

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.

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.

[Peter Blomberg]

... 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.

[Orion Pobursky]

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.

[Magnus Forsberg]

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_R...primitives

[Peter Blomberg]

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.

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?

[Manfred Schaefer]

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

[Manfred Schaefer]

"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_R...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

[Orion Pobursky]

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.

[Rene Rechthaler]

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)

[Peter Blomberg]

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.

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.

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.

[Peter Blomberg]

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.

[Peter Blomberg]

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.

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.

[Orion Pobursky]

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.

[Willy Tschager]

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.