Some hatching experience

Discussions about the development of the TechDraw workbench
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
sire42
Posts: 20
Joined: Thu Mar 11, 2021 11:31 pm

Some hatching experience

Post by sire42 »

Hi,

I experimented with the "Apply Geometric Hatch to Face" function and like to share my experience and some results.

Initially I tried to use the '...' button to change to some external PAT file, but it always showed an error in Report View:
"Could not find pattern: xxx"

I figured out, that only patterns that are present in the default pattern file can be selected, even though the ones of the chosen PAT file are properly shown in drop down list.
So it seems, one needs to stick to the FCPAT.PAT file and do the edits there. I don't think, it is supposed to be this way, because then actually the '...' button to select another file has no use. Maybe, you could also choose a completely different default file in TechDraw preferences, but again, on the fly re-selection of PAT file through '...' is not feasible. I suppose, it has to do with loading the first patterns from the default file, if then the pattern set is changed through another file, only the patterns are working, that also were present in the intially loaded file, all others raise the aforementioned "Could not find pattern" error.

So for my project I needed some specific patterns that are not present in the FCPAT.PAT and also I did not found them available in the internet.
So I started PAT programming.

I want the hatching patterns from ISO 128-3 which are recommended for architectural design hatching.

The result is shown here:
HatchPatternsI-SO128-3-Concrete.png
HatchPatternsI-SO128-3-Concrete.png (67.46 KiB) Viewed 2419 times
I followed the explanations provided here: https://knowledge.autodesk.com/support/ ... excel.html

But some behavior still puzzles me:
The repetition offset does not seem to work as I understood it, e.g. in this pattern

Code: Select all

*ISO-128-3_concrete-reinforced, 45 diagonal R, Solid-Dash, 4.0 mm separation
45, 0, 0, 0, 5.5 
45, 4.0, 0, 0, 5.5, 3.2, -1.6
I would expect the 5.5, which I found by try-and-error, to be an 8.0, because I want the first line to reappear every 8 "units".
This also seems to be impacted by the "Pattern Scale" value from the Geometric Hash function, because when used, the block of defined lines is scaled but the distance of these repeated blocks not accordingly, so that the pattern gets block-wise spread
HatchPatternsI-SO128-3-Concrete-scaled.png
HatchPatternsI-SO128-3-Concrete-scaled.png (39.15 KiB) Viewed 2419 times
[Attached the FCPAT.PAT I used, also containing a pattern provided by some other FC User here.] Edit: Removed wrong file. See post below for later version.

Maybe I explore the svg based feature next.
But this also seems to come with some challenges.
Making the base pattern repeat symmetric also with respect to scaling does not seem to be trivial, my first try failed at least:
HatchPattern-SVG.png
HatchPattern-SVG.png (54.81 KiB) Viewed 2419 times
OS: Windows 10 Version 2009
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24267 +148 (Git)
Build type: Release
Branch: Branch_0.19.4
Hash: 476ecf091941bead59b14e44afa6064d5a66afa3
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.3
Locale: German/Germany (de_DE)
Last edited by sire42 on Fri Apr 22, 2022 7:28 pm, edited 1 time in total.
User avatar
Roy_043
Veteran
Posts: 8450
Joined: Thu Dec 27, 2018 12:28 pm

Re: Some hatching experience

Post by Roy_043 »

sire42 wrote: Fri Apr 22, 2022 3:06 pm I would expect the 5.5, which I found by try-and-error, to be an 8.0, because I want the first line to reappear every 8 "units".
I have not read the information in the link you have provided, but this is incorrect. It is a bit tricky. The offset value is relative to the direction of the hatch lines. but the base point of the hatch lines is not.

The hatch definition should be:

Code: Select all

*ISO-128-3_concrete-reinforced, 45 diagonal R, Solid-Dash, 4.0 mm separation
45, 0,0, 0,5.6568542
45, 4.0,0, 0,5.6568542, 3.2,-1.6
sire42
Posts: 20
Joined: Thu Mar 11, 2021 11:31 pm

Re: Some hatching experience

Post by sire42 »

Thanks Roy,

ok got it. The reference I provided has an example with vertical lines, i.e. a=90° angle.

And since it appears the offset in PAT is set as sin(a)*horizontalOffset, this made no difference (sin(90°)=1).

So, my expected horizontalOffset=8 becomes
patOffset=sin(45°)*8=0.70711*8=5.65685
sire42
Posts: 20
Joined: Thu Mar 11, 2021 11:31 pm

Re: Some hatching experience

Post by sire42 »

So I continued a bit.

Attached a pat file including the improved concrete hatches.
I found the "shift" value, the fourth in line, useful to properly align the dashed lines so they reappear always with the same starting.

I experience major issues with more complex pat configs available in internet.
One issue I was able to identify and fix:

The leightweight concrete hatch as I found it in internet:
*BETONL_org,Leichtbeton /o/o/o/o/o/o/o
45.000,0.0000,0.0000,0.0000,2.8284
45.000,2.0000,0.0000,2.8284,2.8284,2.8284,-2.8284
0.0000,4.7929,2.5000,0.0000,4.0000,0.4142,-3.5858
45.000,5.2071,2.5000,2.8284,2.8284,0.4142,-5.2426
90.000,5.5000,2.7929,0.0000,4.0000,0.4142,-3.5858
-45.00,5.2071,3.5000,2.8284,2.8284,0.4142,-5.2426
0.0000,4.7929,3.5000,0.0000,4.0000,0.4142,-3.5858
45.000,4.5000,3.2071,2.8284,2.8284,0.4142,-5.2426
90.000,4.5000,2.7929,0.0000,4.0000,0.4142,-3.5858
-45.00,4.5000,2.7929,2.8284,2.8284,0.4142,-5.2426

and the modification I figured out to make it work in TechDraw:
45.000,0.0000,0.0000,0.0000,2.8284
45.000,2.0000,0.0000,2.8284,2.8284,2.8284,-2.8284
0.0000,4.7929,2.5000,0.0000,4.0000,0.4142,-3.5858
45.000,5.2071,2.5000,2.8284,2.8284,0.4142,-5.2426
90.000,5.5000,2.7929,0.0000,4.0000,0.4142,-3.5858
-45.00,5.5000,3.2071,2.8284,2.8284,0.4142,-5.2426
0.0000,4.7929,3.5000,0.0000,4.0000,0.4142,-3.5858
45.000,4.5000,3.2071,2.8284,2.8284,0.4142,-5.2426
90.000,4.5000,2.7929,0.0000,4.0000,0.4142,-3.5858
-45.00,4.7929,2.5000,2.8284,2.8284,0.4142,-5.2426

Somehow I was able to follow the TechDraw approach more. But certainly for the more complex pat hatches this manual fixing is not possible.
Attachments
FCPAT.zip
(619 Bytes) Downloaded 41 times
Iso128-3-HatchPatterns.png
Iso128-3-HatchPatterns.png (60.4 KiB) Viewed 2317 times
sire42
Posts: 20
Joined: Thu Mar 11, 2021 11:31 pm

Re: Some hatching experience

Post by sire42 »

And now with some more:

Code: Select all

*ISO-128-3_masonry-brick, horizontal lines, 2xSolid-3xSolid, 1.0 separation
0,0,0,0,7.0
0,0,1,0,7.0
0,0,3,0,7.0
0,0,4,0,7.0
0,0,5,0,7.0

*ISO-128-3_masonry-strong, horizontal lines, 2xSolid-3xSolid, 0.5 separation
0,0,0,0,7.0
0,0,0.5,0,7.0
0,0,2.5,0,7.0
0,0,3,0,7.0
0,0,3.5,0,7.0

*ISO-128-3_solidwood-longways, horizontal lines, 1xSolid-3xSolid, 1.0 separation
0,0,0,0,8.0
0,0,1,0,8.0
0,0,2,0,8.0
0,0,5,0,8.0

*ISO-128-3_solidwood-crossways, 45 diagonal R, 3xSolid-1xSolid, 1.0 separation
45,0,0,0,6.36396
45,1,0,0,6.36396
45,2,0,0,6.36396
45,5.5,0,0,6.36396

*ISO-128-3_wood-generic, vertical lines, Solid, 2.0 separation
90,0,0,0,2.0
Some I had to scale to be useful. And not all scale factors were working.
Attachments
Iso128-3-HatchPatterns2.png
Iso128-3-HatchPatterns2.png (48.92 KiB) Viewed 2290 times
FCPAT.zip
(758 Bytes) Downloaded 46 times
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Some hatching experience

Post by wandererfan »

sire42 wrote: Fri Apr 22, 2022 3:06 pm Initially I tried to use the '...' button to change to some external PAT file, but it always showed an error in Report View:
"Could not find pattern: xxx"
The file/pattern selection issue should be fixed in v0.20 by this PR issue #6781. That won't help you in v0.19.

An ugly work around is to save and reopen the FCStd file after you change the file and pattern. It should pick up the new values on reload.
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Some hatching experience

Post by wandererfan »

sire42 wrote: Fri Apr 22, 2022 9:07 pm And not all scale factors were working.
As in 2x works but 4x does not? Or the results are not pleasing at certain scale factors?
sire42
Posts: 20
Joined: Thu Mar 11, 2021 11:31 pm

Re: Some hatching experience

Post by sire42 »

Hi,

update time.

Nice to see such quick response and fixed; Thanks wandererfan.

I got access to the ISO standards. It seems, the 128-3 even though being the superseed of 128-50 does not contain the patterns I am working on.
So the best original source I have is

DIN-ISO-128-50_2002-05
Technical drawings — General principles of presentation —
Part 50: Basic conventions for representing areas on cuts and sections
(ISO 128-50:2001)

This actually seems to have a National Amendment for Germany which includes the hatch patterns I want.
So I don't know about other countries' requirements. US have ANSI standards, which you commonly find as pat-files.
But I would be interested in other European norms as well. To me, the 128-50 look quite logical, some people obvisouly had put some thoughts into it, so I have some motivation to make as much as possible openly available supported through FreeCAD.

Added some more:
Iso128-3-HatchPatterns3.png
Iso128-3-HatchPatterns3.png (162.37 KiB) Viewed 2092 times
Regarding the issues:

I think the interpretation of negative angles differs in FreeCad from the original pat file interpretation.
I suspect that FreeCad in the standards coordinate system (0° straight to right) interpretes e.g. -45° pointing from origin to upper left, but that the original interpretes it as pointing to lower right (which makes more sense mathematically).

The scaling issues are harder to analyse for me. Really strange are the ones, where the pattern exceeds the face boundary:
Iso128-3-HatchPatterns3_scale12.png
Iso128-3-HatchPatterns3_scale12.png (395.48 KiB) Viewed 2092 times
My current understanding would be that all values except the angle of all lines need to be multiplied by the same scale factor.
But I don't know, if this is the case.

I also noted, that the line pattern does not follow my current understanding:
Starting with the 6th value in row, one can specify the line pattern list. A positive value means a "pen-down" line of given unit length, i.e. a stroke. A negative value means "pen-up", i.e. a gap. A zero means a dot. If I put

Code: Select all

0,0,0,0,2,1,-1
I would expect a dashed line of equal stroke and gap length, i.e.

Code: Select all

- - - - - - - - - - - - - -
But in TechDraw the gap is actually shorter than the stroke:
GapSpacingLength.png
GapSpacingLength.png (13.15 KiB) Viewed 2092 times
The dot (0) works, but it is still a bar longer than 0.1, so that I used 0.1. instead of 0 to get a dot. Nice would be a real equal length to hight square as dot on putting 0.

I was able to track the source up to

Code: Select all

// inclusion of the generated files (generated out of DrawGeomHatchPy.xml)
#include <Mod/TechDraw/App/DrawGeomHatchPy.h>
#include <Mod/TechDraw/App/DrawGeomHatchPy.cpp>

But the xml did not help me much. So if the actual source of scaling is somewhere, you may point me to it and I can check.

The explanations from the orignal source of pat format also were quite helpful to understand the concept:
https://knowledge.autodesk.com/support/ ... B-htm.html
Attachments
FCPAT.zip
(995 Bytes) Downloaded 33 times
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Some hatching experience

Post by wandererfan »

sire42 wrote: Sun Apr 24, 2022 4:46 pm
First, thank you for the detailed analysis.

Most of the code for interpreting PAT files is in TechDraw/App/HatchLine.cpp. The code for painting the pattern is in TechDraw/Gui/QGIFace.cpp.

re angles, there is some code that looks to map angles on to [-180, 180]. Maybe it has a glitch.

re scaling, there is a comment in the code that says "interval & offset are not patternscaled". I can't remember why.

I suspect the unequal mark and space lengths are due to this:
https://doc.qt.io/qt-5/qpen.html#cap-style
Using the default would make marks a bit longer than spaces.

I'd like to dig into the case where the pattern doesn't fill the face (your Iso128-3-HatchPatterns3_scale12.png).
Can you share an FCStd file and a PAT spec that shows this?
sire42
Posts: 20
Joined: Thu Mar 11, 2021 11:31 pm

Re: Some hatching experience

Post by sire42 »

Hi,

I wrote a test PAT to investigate:

Code: Select all

*PAT-algo-test_1, \_ \_ \_ - FC ok, 1.0 separation
0,0,0,0,4,1,-3
135,0,0,0,2.8284,1,-1.8284

*PAT-algo-test_2, diag to lower right - FC NOK stops drawing, 1.0 separation
0,0,0,0,4,1,-3
315,0,0,0,2.8284,1,-1.8284

*PAT-algo-test_3, diag to lower left - FC NOK is upper right, 1.0 separation
0,0,0,0,4,1,-3
225,0,0,0,2.8284,1,-1.8284

*PAT-algo-test_4, diag to lower left - FC NOK is upper right, 1.0 separation
0,0,0,0,4,1,-3
-135,0,0,0,2.8284,1,-1.8284

*PAT-algo-test_5, diag to lower right - FC NOK is upper left, 1.0 separation
0,0,0,0,4,1,-3
-45,0,0,0,2.8284,1,-1.8284
Looks like:
AngularTest.png
AngularTest.png (53.5 KiB) Viewed 1997 times
There is some useless part of single diagonal bars, but the important is the pattern where the two bars have the same origin.


Only dealing with -180:180 could explain test_2 and test_3 NOK. (Of course this input 0:360 could be easily mapped to -180:180), so this might already be one rather simple step towards PAT robustness.

Looking at HatchLine.cpp, I could maybe explain test_4 NOK:
Line 422 will run making the -135 a 45 angle with positive slope. But looking from origin, the line needs to start off in right the other direction.
For solid lines or simpler patterns with equal dash-gap, this does not matter, because the line is symmetric around the origin so that the actual "direction of traveling" the line does not matter. But for the more complex patterns it seems to do.
For full PAT support, it needs full Unit Circle vector support; The slope approach might just provide half of the story.
I am careful here, because I haven't fully analysed the code, for sure, Unit Circle calculus can be provided through sin/cos/tan as present in code. It's just the "slope" term used, which by definition in real number set lacks the internal pos/neg direction, and I do not see complex numbers used (I used to work in digital signal processing, complex number arithmetics are just great for this once this imaginary thing is somehow accepted as another axis with some handy calculus rules that completely avoid those non-linear, indeed "glitchy", real number based sin/cos/tan calculus).

On scaling:
getPatternStartPoint is currently hard for me to follow (no offense :lol: ). I expect scaling to be a linear operation on all PAT fields except angle.
The pattern i used for the overshooting issue was ISO-128-50_gravel as contained in lately attached FCPAT.zip.
The FCStd I use is too unclean to show right now :oops: . Maybe I can condense it to a simpler version only focusing on reproducing the error.

I agree on the dash length thing. Flat Cap as in your link should do it. But I did not find it in preferences.
Post Reply