Drawing with very dense hatch patterns

[andrew]

From a QCAD user:

My drawing loads very slowly and is slow to work with. This might be caused by very dense hatch patterns in the drawing. How do I solve the problem?

[andrew]

1. Select all hatches which are not solid fills using the selection filter (View > Selection Filter):

select_hatches_with_patterns.png (24.34 KiB) Viewed 4113 times

2. Change the hatch pattern scale to something reasonable. Start with 1, if the performance is OK, try 0.1, 0.01, etc. to find the smallest reasonable pattern scale.

change_pattern_scale.png (90.98 KiB) Viewed 4113 times

[CVH]

Ideally we would work out a Hatch-segment density.
Or how many segments it takes to render 1 squared mm.

Knowing these are all line-segments or dots and are rendered in the associated Lineweight in mm ...
... We can avoid to invoke the Hatching-engine on a too dense pattern in a given scale.

Beats a boundary 'Complexity' factor and 'Timing-out' for each Hatch before it ever occurs.
But you need a good insight in CAD patterns to do so.

Invisible Hatches because too dense, too complex, because timed out, only slow down QCAD.
We once worked out a 'Cloning Load' factor, when too high the pattern would fail the QCAD Hatching-engine.

They are also mysterious things to select, regardless of even knowing that they exist in a drawing.
With the same ease the Hatching-engine can revert to filling it solid for the time being.
Or at least warn the user, once on loading is enough.
Like warning that there is 3D data in a drawing, except for QCAD/CAM.



The required Hatch for this test and the next one has a density of only 1 segment per mm at unit scale.
The Add-On deliberately uses the hatching engine to fill an entire area.
In scale 0.08 that are 12.5 parallel segments per mm, quite harsh but still feasible if you max out the 'Timing-out' preference.

HJ Seef requirements for this tool are near the limit of what is possible based on his 'White paper'.
Both tests produce over 10k segments in an Hatched area not larger than 78 by 124mm.
Zig-Zag pocketing for reasonable tool diameters is thereby implemented.
A larger Laser spot would be a good idea in his case.

Regards,
CVH

[HJ Seef]

=> "HJ Seef requirements for this tool are near the limit of what is possible based on his 'White paper'. Both tests produce over 10k segments in an Hatched area not larger than 78 by 124mm. Zig-Zag pocketing for reasonable tool diameters is thereby implemented. A larger Laser spot would be a good idea in his case."


A laser has a fixed tool diameter. Using a 2,5 Watt laser cutter, the best focused diameter is approximately 0,1 mm. However this is in a height range of plus/minus 1 mm! Meaning the spot-diameter can not be changed. To clear an area on a PCB, one has to hatch at an offset distance of 0,08 mm, meaning an overlap 20%.

[CVH]

To clear an area on a PCB, one has to hatch at an offset distance of 0,08 mm, meaning an overlap 20%.

With your setup and your Laser source.
There are other (cheap) Laser sources available.

Still, 12.5 horizontal lines per mm or 317,5 per inch is very close to the limit.
I already need to max out the time-out preference: 10000ms or 10s per Hatch.


Then the Hatch-engine is not flaw-less ...
See the given example 250715_Triac_Module-ZigZagTest.dxf in the White paper topic.

- Freeze all layers
- Thaw layer 'X) Hatch from 2 but patterned'
- Detect the flaw at Y=106.320000

- Freeze all layers
- Thaw layer 'XX) Hatch from inward offset of B_CU'
- Detect the flaw at Y=82.960000

For that last the flaw occurred at (51.060000, 82.960000) where a boundary Line segment is tangent to an Arc segment.
Turns out that the Hatch pattern is aligned with a horizontal boundary segment.
The Odd-Even fill rule trips over multiple intersections at that point or the one more to the left.
It then chops up the (almost) endless pattern line at the wrong places.

The WHY is documented and reported.
An intersection of a Line and Arc is not that hard.
The arc must virtually end in that point and that for all the resources in the same way and with the same tolerances.
Basic things like the angle of a vector or an angle difference should be bulletproof, especially in edge cases.

Regards,
CVH