Inside Hatches, more than meets the eye

Discussion forum for C++ and script developers who are using the QCAD development platform or who are looking to contribute to QCAD (translations, documentation, etc).

Moderator: andrew

Forum rules

Always indicate your operating system and QCAD version.

Attach drawing files, scripts and screenshots.

Post one question per topic.

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Fri Jan 17, 2020 10:30 am

BTW @1000000 Is as far as the Hatchkit guys go.
Their example is metric @25000000.

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Fri Jan 17, 2020 11:35 am

All,

I think we might have hit a snag here. I can not call it a bug.
What I presume is that Qcad calculates all the offsetted paralles and shifts endlessly
and that AC at some point re-calculates a new origin and starts over from there.
>>
>>EDIT: Redrawn, read further: John hitted the AC limit.
>>

And that can be done with some proper math and with higher precision.
Its kinda the way I came, reversed engineering down to Tiles.
The next step back to tiled cartesians restricted the cartesians themselves to a grid.
What I did not liked because that could not be the goal of all the effort.

on top:
If you would re-origin every tile you get SuperHatch capabilities.

I don't mind. I am glad I found the limit.
I'll adapt the decimal digit heuristics to that.
It will limit good coherence up to 500000x500000 tiles away.
But gives us far better cartesian precision inside 1 tile. Far neater designs.
instead of 0.01x0.01 we can go up to 0.0001x0.0001 in imperial.
Metric users always get 25.4 times less, but it is the same percentage.

The difference for the users, none.
Simply send a notice to the Qcad crowd that it is good practice to keep the hatch origin near the hatch.
Hatches that span more then 1000000 tiles will eventually loose coherence.
Nobody is doing that!!!
It is better to chage the units long before that.

Regards,
CVH
Last edited by CVH on Fri Jan 17, 2020 12:11 pm, edited 1 time in total.

John Hyslop
Premier Member
Posts: 473
Joined: Mon Sep 30, 2019 6:21 am
Location: Melbourne - Australia

Re: Inside Hatches, more than meets the eye

Post by John Hyslop » Fri Jan 17, 2020 11:40 am

Hi CVH
So are we so to speak "flogging a dead horse" ?
We stick to basic patterns 0,45 & 90 degrees? for standard hatches
Maybe the curved patterns can be addressed with
a ..... here we go again...... DXFTILE?

Adding another 0 onto 1000000 and AutoCad begins to struggle too..
Unless maybe you can come up with a way to optimize the patterns
so they don't use so many decimal places without loosing quality...
I have no idea, I don't do this sort of coding and because of that I
didn't understand Andrews answer to you.. e_confused



Cheers
John
IF IT IS TO BE IT IS UP TO ME [ Ten most powerful 2 letter words ]

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Fri Jan 17, 2020 11:48 am

AC might use long doubles or rely on the 16th digit of 15,95.... Ha e_geek :P :roll:
Sorry, could not temper myself.

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Fri Jan 17, 2020 12:07 pm

John Hyslop wrote:
Fri Jan 17, 2020 11:40 am
We stick to basic patterns 0,45 & 90 degrees?
Correct form one point: 0,45,90,135... do not have decimals, so the don't loose any. :P

There are also x.99999999abc ones with little or no absolute fault.
Apart from the non-clones (0,45,90...) there are also 1-2-3-4-5...9 clones.
At least 10 times 10 times less sensitive.

And that is what you see far away. Some stay coherent, some not.
I'll keep them coherent up to a certain point.

Regards,
CVH

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Sun Jan 19, 2020 3:48 pm

CVH wrote:
Tue Jan 14, 2020 8:44 pm
The trick is still reversing the definition with an opposed shift.
When? When not?
Solved & Explained !! e_geek
A smaller absolute value repeated gets less faster in trouble with the 15-16 significant digits.
The sign does not matter apart that it has to be stored in the 80 characters limit.
e.g. 240.0684...° : 8.062214... or -(30.016650...)
e.g. 315.8069...° : 48.795487... or -( 1.414073...)

Tool adapts now. :P

John Hyslop wrote:
Fri Jan 17, 2020 11:40 am
I have no idea, I don't do this sort of coding and because of that I
didn't understand Andrews answer to you..
C++ double is a 64 bit IEEE 754 double precision Floating Point Number.
(1 bit for the sign, 11 bits for the exponent, and 52* bits for the value).
*) All other values but "0" assume an invisible “1” in front.
52-53 bits binairy resolution.
The longest number that can be represented is:
2^53 = "9007199254740992" or about 15.95 digits (=log10(...))
The actual longest number that really fits is "0999999999999999"
= 15 significant digits

But in special 15.95 is meaning that taking 16 digits for true will flaw in 5% for the 16th digit.
Most results are from more then one calculation, with increasing uncertainty for the 16th digit.
Some C++ compilers take it the safe way. 15 significant digits.

Patterns will fail far away when the integer part needs more digits and the decimal part looses its accuracy.

John Hyslop wrote:
Fri Jan 17, 2020 11:40 am
Unless maybe you can come up with a way to optimize the patterns
I can not beat the used numerical system.
But they are as optimized as possible. :P

On top:
As you can see above it is angle related.
Recoding is not that hard:
gravel_rev.pat
(2.9 KiB) Downloaded 598 times
In inch one can stretch this up to 100000 inch away.

QCAD-LOGO_rev.pat
(6.74 KiB) Downloaded 586 times
In inch one can stretch this up to 180000 inch away.

Regards,

John Hyslop
Premier Member
Posts: 473
Joined: Mon Sep 30, 2019 6:21 am
Location: Melbourne - Australia

Re: Inside Hatches, more than meets the eye

Post by John Hyslop » Mon Jan 20, 2020 12:47 am

e_confused
Last edited by John Hyslop on Mon Jan 20, 2020 12:51 am, edited 1 time in total.
IF IT IS TO BE IT IS UP TO ME [ Ten most powerful 2 letter words ]

John Hyslop
Premier Member
Posts: 473
Joined: Mon Sep 30, 2019 6:21 am
Location: Melbourne - Australia

Re: Inside Hatches, more than meets the eye

Post by John Hyslop » Mon Jan 20, 2020 12:49 am

Hi CVH

Thanks for the explanation I understood some of it🤔
I think it might be a good idea to add a comment to users that hatch far away from the origin to edit the hatch properties to set the hatch origin back to X 0 Y 0
To reset the pattern...
I did put a note at the start of the "Free Hatch Patterns" topic saying that some patients will fail or become scattered...but put in your words..
We just have a limitation but there is the above workaround...not the best solution as I know you wanted to take this above and beyond with all your great ideas.👌
Anyway..I might post the hatches I removed and add notes...the only ones that render nicely far away from 0,0 are the basic ones 90 and 0 degrees and increments of these, anything with an angle even 45deg breaks apart🤔

I still think what you've created so far is great it's just the limitations of Qcad....but as you say not many people would hatch that far away from origin...and we have above workaround..

Cheers
John
IF IT IS TO BE IT IS UP TO ME [ Ten most powerful 2 letter words ]

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Mon Jan 20, 2020 1:55 am

CVH wrote:
Fri Jan 17, 2020 11:35 am
Simply send a notice to the Qcad crowd that it is good practice to keep the hatch origin near the hatch.
John Hyslop wrote:
Mon Jan 20, 2020 12:49 am
I think it might be a good idea to add a comment to users that hatch far away from the origin to edit the hatch properties to set the hatch origin back to X 0 Y 0
In that we agree, I think it would be a standard notice or even a default behavior when 'hatching'. :idea:

Like I showed, recoding is done in a few minutes.
I did it aside while writing the post.
I started with < ar-conc.pat > but discovered that it is a strange fish.
This pattern is a collection of definitions based on mixed tile sizes so it looks more random.
so I took the Qcad gravel pattern like the Hatchkit example.
After generation, I discoverred the flaw at (0,0.78) ; Corrected it to 0.77 and redone it.
With that successfull, I processed the original QCAD-LOGO.
Fill in names, moving and rebooting took the longest.

After recoding the patterns are as less sensitive as possible on Qcad.
What I can't fix is the truncated 2 decimal digits of the examples what could be 4 digits in this case.
For that one has to restart from an existing or new master design.
With neater results possible.
John Hyslop wrote:
Mon Jan 20, 2020 12:49 am
Thanks for the explanation I understood some of it
Thanks, maybe even clearer with this: :)
With 15 significant digits one can represent:
abcdefghijklmno.000
abcdefghijklmno0000.000
abcdefghij.klmno
0.000abcdefghijklmno

But never: abcdefghijklmno.pqrst :(
Never a huge number and a high accuracy at the same time.

It was nececary to hit these limits.
There is a lot of scaling going on (times 1 for now).
Scaling required a stable decimal digit strategy.

Cheers,
CVH

John Hyslop
Premier Member
Posts: 473
Joined: Mon Sep 30, 2019 6:21 am
Location: Melbourne - Australia

Re: Inside Hatches, more than meets the eye

Post by John Hyslop » Wed Jan 29, 2020 10:44 am

Hi CVH

This may be of interest to you... Autocad has the same problems with hatches but have system settings to reset the origin..

https://knowledge.autodesk.com/support/ ... rigin.html
Let me know what you think..

Cheers
John
IF IT IS TO BE IT IS UP TO ME [ Ten most powerful 2 letter words ]

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Wed Jan 29, 2020 11:37 am

John,
Sure, on the origin thing we have already launched the advice.
John Hyslop wrote:
Wed Jan 29, 2020 10:44 am
Let me know what you think..
That it would be nice that this would be automated at the moment of generation I think I did mention somewhere.
EDIT: 2posts up see :idea:

Apart from that I am still at the hatch generation step.
Tutorials for users or advice for Andrew is still way ahead.

Cheers,
CVH

John Hyslop
Premier Member
Posts: 473
Joined: Mon Sep 30, 2019 6:21 am
Location: Melbourne - Australia

Re: Inside Hatches, more than meets the eye

Post by John Hyslop » Thu Jan 30, 2020 4:15 am

Hi CVH

Hatch Pattern drifting and shifting of entities seems to be a very common problem even with AutoCAD too,
they suggest also to reset the origin e_surprised


https://autocadtips1.com/2017/07/24/fix ... h-pattern/

Cheers
John
IF IT IS TO BE IT IS UP TO ME [ Ten most powerful 2 letter words ]

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Thu Jan 30, 2020 5:19 am

John,
ok,
we know that by now.

But what makes Gravel-01 so much more stable as Garvel.
That is the big question.
I have them side by side for comparison.
Altough it isn't straightforward because a lot of segments have a reversed orientation.


And even more:
Why does 0.0902033691118° works out for YukonRubble @ Tile (!635! ,1)
While it should be 0,0902294994465307...° at that addres.
Simply equal to the Inverse tangent of 1/635.


AR-CONC-01 that you have to explain in detail to me.
That originates from a multi layer hatch.

Cheers,
CVH

John Hyslop
Premier Member
Posts: 473
Joined: Mon Sep 30, 2019 6:21 am
Location: Melbourne - Australia

Re: Inside Hatches, more than meets the eye

Post by John Hyslop » Fri Feb 14, 2020 11:06 pm

Hi CVH

I've given users the wrong information... I said to set the origin to X0Y0 on objects far from drawing datum
I should of said set Hatch origin to object datum.... see screenshot example of GRAVEL Hatch Pattern.. also
included is dxf file in mm's..the 2 objects were drawn 1st then the hatch patterns applied..
Cheers
John
Attachments
Hatch Origins - Gravel - mm.dxf
(204.04 KiB) Downloaded 547 times
Hatch Origins - Gravel - mm.jpg
Hatch Origins - Gravel - mm.jpg (113.09 KiB) Viewed 11699 times
IF IT IS TO BE IT IS UP TO ME [ Ten most powerful 2 letter words ]

CVH
Premier Member
Posts: 3416
Joined: Wed Sep 27, 2017 4:17 pm

Re: Inside Hatches, more than meets the eye

Post by CVH » Sat Feb 15, 2020 1:34 am

CVH wrote:
Fri Jan 17, 2020 11:35 am
Simply send a notice to the Qcad crowd that it is good practice to keep the hatch origin near the hatch.
Complex Hatches that span more then 50000 tiles will eventually loose coherence.
Nobody is doing that!!!
It is better to chage the units long before that.
Corrected the quoted a bit.
Remark here the use off the nominator 'tiles' and not units.
It is all an angle thing related to the use of a grid like structure.

And meanwhile we also know it is a huge tradeoff between detailed and accurate OR lookalike and stable.
Even with a 0.01 drawing grid in a unit tile one can draw segments that don't hold for 10,000 tiles.

Second most important is how to use the 80 characters wisely.
We have to put things in there like:
Simply a line from (0.99,0.01) to (0.01,0.02)
0.01 grid: 179.415369479295,0.99,0.01,0.999947942424286,0.0102035504329009,0.980051,-97.0250509080129
my solution is:
179.41536948,.99,.01,.999947942424286,.0102035504329009,.98005,-97.0250509080129
Keeping most up to 15 significant digits.
But also:
0.001 grid: 134.912968503119,0.529,0.108,465.98390530091,0.000716056673849367,0.34215,-1396.19535397188
134.9129685,.529,.108,465.98390530091,.000716056673849367,.34215,-1396.19535397188
Is still 82 long and reducing to 80 will decrease acuracy.

Regards,
CVH

Post Reply

Return to “QCAD Programming, Script Programming and Contributing”