Inside Hatches, more than meets the eye
Posted: Tue Jan 14, 2020 4:22 pm
Hi all,
I was working at a scaled output for Tile2Hatch.
An add-on to turn anything you like in a hatch.
One day we will all create a hatch pattern in a few clicks.
(Like me and John do nowadays)
We used a common 6/8 decimal digit scheme with rather good looking patterns in inch.
For metric users the patterns are scaled by 25.4 and then the problems start to rise.
Something times 25.4 will always take more space to write down with the same accuracy.
The patterns are limited to 80 characters per definition line.
In short these are arraged as: Angle, startX, startY, dXshift, dXoffset, dash1, dash2, ... dash6
So I investigated many different strategies.
At a point I wondered if we could reduce the angle accuracy, but no, on the contrary.
Later on I looked over the hedge:
https://www.hatchkit.com.au/faq.php
In the first section one can read what a less good defined hatch pattern will do far away from the origin.
These guys say this is related to the accuracy of dXoffset and dash2.
What they leave out is that this is also true for the Angle.
Their example with Angle = 0 is not revealing that on purpose, protectionism.
By luck a pattern sourced online is made by hatchkit: YUKONRUBBLE
https://qcad.org/rsforum/viewtopic.php? ... 610#p25610 and further.
Learned some more from it but I am not very pleased with the heavy reduction in accuracy for the position and dash1.
With 3 or less decimal digits we are back where we started.
At some points I came accross only some segments that failed casted far away even with rather good accuracy.
Included is a dxf with the Qcad Logo by John. Don't ask me what revision, it doesn't care.
At 10000 units away from the origin it still looks ok apart from one single segment.
All other segments are also shifted somewhat but that is hardly noticeable.
Also notice the boundary crossings!!
Don't know what is going on here, that is for Andrew's to worry about.
PainterPaths is something that sits deep inside the Qcad forrest.
Why that 1 segment stands out is that it has a quite large dxshift at line 101, almost maxed out.
Instead of shifting the definition 48.79548753 one way we equally could shift it -1.41407331 the other way.
In se, that and using the endpoint is the only difference between the two pattern files apart from the name.
Included both pat files.
I will have to spend more research on that, if I can spare the time.
CVH
I was working at a scaled output for Tile2Hatch.
An add-on to turn anything you like in a hatch.
One day we will all create a hatch pattern in a few clicks.
(Like me and John do nowadays)
We used a common 6/8 decimal digit scheme with rather good looking patterns in inch.
For metric users the patterns are scaled by 25.4 and then the problems start to rise.
Something times 25.4 will always take more space to write down with the same accuracy.
The patterns are limited to 80 characters per definition line.
In short these are arraged as: Angle, startX, startY, dXshift, dXoffset, dash1, dash2, ... dash6
So I investigated many different strategies.
At a point I wondered if we could reduce the angle accuracy, but no, on the contrary.
Later on I looked over the hedge:
https://www.hatchkit.com.au/faq.php
In the first section one can read what a less good defined hatch pattern will do far away from the origin.
These guys say this is related to the accuracy of dXoffset and dash2.
What they leave out is that this is also true for the Angle.
Their example with Angle = 0 is not revealing that on purpose, protectionism.
By luck a pattern sourced online is made by hatchkit: YUKONRUBBLE
https://qcad.org/rsforum/viewtopic.php? ... 610#p25610 and further.
Learned some more from it but I am not very pleased with the heavy reduction in accuracy for the position and dash1.
With 3 or less decimal digits we are back where we started.
At some points I came accross only some segments that failed casted far away even with rather good accuracy.
Included is a dxf with the Qcad Logo by John. Don't ask me what revision, it doesn't care.
At 10000 units away from the origin it still looks ok apart from one single segment.
All other segments are also shifted somewhat but that is hardly noticeable.
Also notice the boundary crossings!!
Don't know what is going on here, that is for Andrew's to worry about.
PainterPaths is something that sits deep inside the Qcad forrest.
Why that 1 segment stands out is that it has a quite large dxshift at line 101, almost maxed out.
Instead of shifting the definition 48.79548753 one way we equally could shift it -1.41407331 the other way.
In se, that and using the endpoint is the only difference between the two pattern files apart from the name.
Included both pat files.
I will have to spend more research on that, if I can spare the time.
CVH