LDraw.org Discussion Forums

I created these primitives with the purpose to avoid the rotation of the corresponding ones. I hope they can be approved. If not, I send an email to the PT Admin for deletions.

(2021-03-24, 17:41)Javier Orquera Wrote: [ -> ]I created these primitives with the purpose to avoid the rotation of the corresponding ones. I hope they can be approved. If not, I send an email to the PT Admin for deletions.

I will say right now that I'm not going to support these in LDView's primitive substitution. As such, the only way that I feel they would be acceptable is if they are shortcuts to the existing cyli and cylo primitives. Furthermore, they appear to be rotated 135 degrees, not 45 degrees.

(2021-03-24, 17:41)Javier Orquera Wrote: [ -> ]I created these primitives with the purpose to avoid the rotation of the corresponding ones. I hope they can be approved. If not, I send an email to the PT Admin for deletions.

I can see the rationale, as I often split round prims to avoid the need to rotate them, but the number of needed variants is so high (and become unmanageable for hires prims!!!)

(2021-03-24, 17:59)Travis Cobbs Wrote: [ -> ]I will say right now that I'm not going to support these in LDView's primitive substitution. As such, the only way that I feel they would be acceptable is if they are shortcuts to the existing cyli and cylo primitives. Furthermore, they appear to be rotated 135 degrees, not 45 degrees.

Forcing them to be an alias of the regular primitives would create the very rotation they intend to avoid.

(2021-03-24, 19:14)Magnus Forsberg Wrote: [ -> ]Forcing them to be an alias of the regular primitives would create the very rotation they intend to avoid.

If they're doing it for performance reasons, then they are misguided, since the matrix math is exactly the same with or without the rotation. I agree with Philo, though, that there are just two many possible ways to rotate things, and so we should completely avoid rotated primitives.

(2021-03-24, 22:03)Travis Cobbs Wrote: [ -> ]If they're doing it for performance reasons, then they are misguided, since the matrix math is exactly the same with or without the rotation. I agree with Philo, though, that there are just two many possible ways to rotate things, and so we should completely avoid rotated primitives.

But if an author is rounding of the values of a rotated primitive in his design, it will introduce a miscalculation, and cause thin, hairline gaps. Right?

I could have sworn that something like this was posted here before, but I could not find it.

In my opinion, to avoid rotating prims, I usually split them if I deem it necessary.

a separate set would be too much

(2021-03-24, 22:41)Magnus Forsberg Wrote: [ -> ]But if an author is rounding of the values of a rotated primitive in his design, it will introduce a miscalculation, and cause thin, hairline gaps. Right?

I don't know. In theory, yes, but I'm not sure if it happens in practice. (Note: when I say I'm not sure, I really mean that I'm not sure; I'm not saying I think it doesn't happen.) If it does happen, then it might be better to relax the 3-decimal-place restriction for transformation matrices in parts.

(2021-03-25, 1:19)Travis Cobbs Wrote: [ -> ]then it might be better to relax the 3-decimal-place restriction for transformation matrices in parts.

It is not a restriction but a suggession: "In general, three decimal places are sufficient for parts". All the parts I made for years have 5 digits transformation matrices, because I got too many problems with just 3. Even 4 causes problems.

(2021-03-25, 8:32)Philippe Hurbain Wrote: [ -> ]It is not a restriction but a suggession: "In general, three decimal places are sufficient for parts". All the parts I made for years have 5 digits transformation matrices, because I got too many problems with just 3. Even 4 causes problems.

Good point, but I still think the parts restrictions spec should be updated to reflect that. If more precision is required for matrices, then the "In general" sentence is misleading at best, and wrong at worst.

(2021-03-24, 17:41)Javier Orquera Wrote: [ -> ]I created these primitives with the purpose to avoid the rotation of the corresponding ones. I hope they can be approved. If not, I send an email to the PT Admin for deletions.

I think the conclusion already is that this type of rotation inside a primitive is a no go.

Use mirrored and divided primitives instead. Your suggested a3-8cyli should be created like this instead:
1 12 0 0 0 0 0 -1 0 1 0 1 0 0 3-16cyli.dat
1 12 0 0 0 0 0 1 0 1 0 1 0 0 3-16cyli.dat

(2021-03-25, 20:40)Magnus Forsberg Wrote: [ -> ]I think the conclusion already is that this type of rotation inside a primitive is a no go.

Use mirrored and divided primitives instead. Your suggested a3-8cyli should be created like this instead:
1 12 0 0 0 0 0 -1 0 1 0 1 0 0 3-16cyli.dat
1 12 0 0 0 0 0 1 0 1 0 1 0 0 3-16cyli.dat

So be it. I give it a try, but as all of you say, it more convenient divide the prims.
I send an email to the PT Admin asking for the deletions of my primitives; and updated again the p/npeghol2.dat with your suggestions. Just needed to submit it and the other parts.
Thank you all for your opinions.