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.
New cyli, cylo and ring primitives.
(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.
RE: New cyli, cylo and ring primitives.
2021-03-24, 22:41 (This post was last modified: 2021-03-24, 22:42 by Magnus Forsberg.)
2021-03-24, 22:41 (This post was last modified: 2021-03-24, 22:42 by Magnus Forsberg.)
(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?
(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.
« Next Oldest | Next Newest »
Users browsing this thread: 2 Guest(s)