Rect decimal precision

[Magnus Forsberg]

Only to prove my point, I have in these files reduced the number of decimals, 3, 2 and 1, and then created rect primitives.
The number of decimals, or the creation of rect primitives, is not the reason for thin gaps.

I challenge anyone to find a gap in them.

The only thing that happens is that there might be a need for some condlines. 
But even they are possible to eliminate as shown in u9563s01- flat no cond.dat.

[Peter Blomberg]

Don't know from where this discussion originates, but good to know. Did you use the Rectifier tool?

In my limited experience, thin gaps tend to occur a) when snap-to-vertex tolerances are too small (human misses the vertex), b) when human changes design on the fly (isecalc need to be rerun), and c) when custom placed polygons adjacent to scaled curved primitives are rounded to the desired number of decimals (the vertices in the subfiles are scaled but not rounded).

In this particular case, I would guess that the problematic rects have been created before rounding and they are rotated such that the vertices of adjacent polygons become rounded to a slightly different value. Perhaps the order of events is the key? To mitigate this type of thin gaps, one should first round to desired number of decimals and only then run Rectifier.

For the general case of interfacing with scaled primitives/subfiles (the custom coordinate is rounded to 4 decimal places while the coordinate calculated from the subfile using the 5-decimal places scaling factor is not rounded), the recommended four decimals appears good enough.

[Philippe Hurbain]

Interesting discussion... I made some experiments and couldn't find a mismatch failure after using Rectifier in LDPE.
Perhaps the mismatches we can see in some parts (generally so small that only Willy can find them   ) actually come from my command line version of Rectifier, often used in Datheader post-processing...

[Rene Rechthaler]

the rects and how to treat them seem to cause some skub:
https://1d6chan.miraheze.org/wiki/Skub
I think the main cause (of manually done ones) is when they end on some external geometry (like partial/rotated cylos) or at intersections...
if these have bad/odd/unnecessary decimals, rectifying it can worsen things.
(because a rect is at half of the distance, if this is odd, the result will have one decimal more...)

[Willy Tschager]

Perhaps the order of events is the key? To mitigate this type of thin gaps, one should first round to desired number of decimals and only then run Rectifier.

That's the ideal way - not reality. In real life, people might round and then rectify, but then there are things to fix/optimize/redone. The once ideal rect gets re-used/scaled/repositioned/re-rounded and suddenly the gaps start showing up ... for what: to save one line of code in a rect1.dat. The library is a constant work in progress, and I wonder how many of us inline rects before they start fixing things? Actually hands-up, who uses rects by manually position/rotate/scale them in an editor? We have rects 'cos we have Rectifier. Does it save you time and effort? Do you benefit from the existence of this series of prims?

I stopped generating them a long time ago 'cos the trouble they cause is by far greater than their benefit, and I wish I could turn off that "Convert bordered rhombuses into rects primitives" in LDPE by default.

w.

[Philippe Hurbain]

the rects and how to treat them seem to cause some skub:
https://1d6chan.miraheze.org/wiki/Skub
I think the main cause (of manually done ones) is when they end on some external geometry (like partial/rotated cylos) or at intersections...
if these have bad/odd/unnecessary decimals, rectifying it can worsen things.
(because a rect is at half of the distance, if this is odd, the result will have one decimal more...)

Yes, that's part of the problem.
Moral of the story, use Rectifier carefully if you mind small vertex mismatches (which is generally NOT a problem at all!)

[Peter Blomberg]

We have rects 'cos we have Rectifier. Does it save you time and effort? Do you benefit from the existence of this series of prims?

I use rect primitives all the time. In a carefully planned combination with boxes, they do save lines. Not time, but this is a hobby for me so using a little more time to produce good quality is pleasant. It also challenges my brain a little.

I'd love a recte2p primitive and would find it nice to have a recte2a primitive as well. An additional box2 primitive having only one rectangle with two connected perpendicular edges (box2-7 without one quad) would save some lines when making box intersections. Also a rect with four perpendicular edges (box5-4a without the side quads) would be nice.

[Orion Pobursky]

While I'm not gonna stop usage, I'm with Willy. I don't really see the point. Given the grief they cause the line savings argument doesn't really hold water (not that I feel the line saving argument is really valid in the first place). The only benefit in my mind is that the quad is guaranteed to never be non-coplanar but I don't think this outweighs the cons.

[Nils Schmidt]

...and I wish I could turn off that "Convert bordered rhombuses into rects primitives" in LDPE by default.

This wish is fulfilled with the next LDPE release 1.8.91*


* (the user will still be able to overwrite the default behaviour with another option and also toggle the creation of shear/rotation matrices)

[Gerald Lasser]

 I wish I could turn off that "Convert bordered rhombuses into rects primitives" in LDPE by default.

w.

What are you doing, that this happens? 
Or what function are you invoking, that give undesired rects?