[bugs] problems when using selfmade hatches

When using selfmade hatchs there is some area which is not hatched.
In the zip archive there is a hatch(hatch_rect2) for testing and a file (tobefilled) I used hatching on.
Looking at the hatches which are bundled with the installation-file and the self-made one, it looks like in the self-made hatches there are some extra lines like the AcDbSymbolxxxx stuff. So they are more complicated.
Don't know if this causes the problem.

Looks like sometimes the hatch just is not created. But I can not reproduce this atm.

http://www.gamefront.com/files/23729627/hatch.zip
7a037ae362ca3711d2b876c5f141a6a7  hatch.zip

using git zip file from yesterday

Searching what may have caused this behaviour I found something strange.
in librecad/src/actions/rs_actiondrawhatch.cpp
lines: 82-91
is the same as
lines: 92-101

Do we need the lines lines: 92-101 ??

Hi,

what is the result you expected from the hatch pattern you created?
Please, can you draw a sample how the pattern should look like with some iterations in X and Y?

Armin

Hi,

you nearly convinced me, but have a second look and find the difference:

82:    for (e=container->firstEntity(RS2::ResolveNone); e!=NULL;
83:            e=container->nextEntity(RS2::ResolveNone)) {
:
92:    for (e=container->firstEntity(RS2::ResolveAll); e!=NULL;
93:            e=container->nextEntity(RS2::ResolveAll)) {

Armin

" but have a second look and find the difference: "
Ooops, thanks missed that.

in the zip file there are 3 files
One pdf file which describes my problem about creating/using self-made hatchs.
hatch_rect2.dxf -> hatch to use on hatchbug2_1.dxf
hatchbug2_1.dxf -> I can't use the above hatch on this drawing -> no hatch is created

http://www.gamefront.com/files/23731746/hatchproblem.zip
d91d5734fced126ba777f74d1641a678  hatchproblem.zip

The hatches:
daemon
brick
do not work.

When I open these two hatch files and save them and then copy them to the hatch directory they work for me.

Hi,

here are some answers to your hatch problem:

no hatch is created:
Your hatch pattern size is about 70x25.
The hatch contour size is about 4200x2900.

There is a fix limit in LC to avoid huge memory and time consumption.
This limit is 100 in both directions. That means your pattern fits in Y direction more than 100 times and is therefore abandoned.

The problem is that the message in the output window tells you the hatch was created successfully. I will change this, that an error message will appear instead.

To solve this problem, change the factor when applying the pattern or create a bigger pattern file, which fits better to the drawing dimensions.

expected result with hatch_rect2.dxf:
To achieve the expected result add small lines left/bottom and top/right, look down to the misc3.dxf part.

I haven't look deeply in, but for me it look like this:
The fist patter is draw in the origin at 0,0 and for the iteration the absolute size of the pattern is used.

I'm not sure if this is a bug or misinterpreted rules, but as there is a workaround, I think we shouldn't touch this until release of 2.0.0.

pattern brick.dxf and daemon.dxf:
This is a matter of layers. When reading the hatch pattern, LC uses the active layer. In these two pattern files the active layer is empty and therefore no hatch is created. To avoid this, use only one layer to draw the pattern and delete all unused layers.
Because this pattern files are part of the LC package I will change and update them on github.

misc03.dxf:
I expect, that these two points are the attempt to reach the behaviour of the right image. The current implementation ignores the points, which results in the pattern of the left image.
To achieve the right image behaviour replace the points by small line entities, 0.1 or even smaller.

arcs.dxf:
Can't reproduce the behaviour you documented, don't know what you mean with this.

Armin

"The problem is that the message in the output window tells you the hatch was created successfully. I will change this, that an error message will appear instead. "
+1
What about, the hatch pattern which are too big maybe we should tell something like "Hatch was created successfully but it may be too big for the area you used it on" ??? Or something in those lines.

"I'm not sure if this is a bug or misinterpreted rules, but as there is a workaround, I think we shouldn't touch this until release of 2.0.0. "
ok

"Can't reproduce the behaviour you documented, don't know what you mean with this."
To reproduce this:
#1 Draw a rectangle (using lines->rectangles) from 0/0 to 350/370
#2 add a "arcs" (not arcs_2) hatch to the rectangle
Now you should see some weird stuff going on. (similar to the image in the pdf file)
In the image in the pdf file the left blue ellipse shows how it should look like.
The greed ellipse on the right shows where the correct arc should be.
The red arcs show that (maybe) on the right side the arc is dawn correctly but in the wrong direction??
thanks for looking at this.

Hi,

followed your instructions, but still can't see what you posted in your PDF.
I also tried the rectangle 0,-200 / @350,370 as it is in the PDF, this changed nothing. The hatch was totally OK with the latest master branch build on Ubuntu 12.04 64-Bit.

Armin

Updated brick.dxf and daemon.dxf with commit commit 50d49b4
Added error messages on hatch creation with commit 8c775aa

"...but still can't see what you posted in your PDF. "
That's strange.
Here is how it looks on my ubuntu12.04 32bit (downloaded the zip archive from git on 27.09.2013)

Hi,

in the About box I see that you work with 2.0.0rc2, I used the latest commit version when testing this issue.

Maybe this bug was solved last week when I found a similar issue. Dxli finally fixed it on Sep 21,2013 with commit 3a7cbbb.

I have to switch back to 2.0.0rc2 to test this, but now it's too late for me.

Armin

"in the About box I see that you work with 2.0.0rc2,"
When downloading the zip archives do I get the latest version or just the latest released version?
I always was thinking that I get a version with all commits added up to the download date.
(if that's correct then I should have the commit-> "fixed it on Sep 21,2013" I downloaded on Sep 27,2013 will have a look if I got the commit/patch in my source)

Did some more testing. Here is some more weird hatch behaviour on OpenSuse12.2 also 32bit.


Looks like arcs_2 works, cause the drawing is made up of line segments and not arcs like the "arcs" hatch.

update: yep, looks like I have the commit in my downloaded zip archive/tested version

Hi,

when you have downloaded the ZIP archive from github, you will have the latest sources.

I expected the commit hash in the SCM Revision string, but as I have seen, if you don't have git installed, it wouldn't change. So this maybe OK.

But even the Compiled on date shows 2013-Aug-27, that means, the executable you have used was compiled on this date and newer changes couldn't be included in it.
After successful compilation of the sources, the About box should at least show the actual date in the Compiled on string. If this is not true, you have to search for the outdated executable in your path and delete or replace it.

Armin

Looks the same when using the snapshot from Sept30 (on OpenSuse12.2 32 bit as in my last post).

Hi,

for me it was OK yesterday, when I switched back to the 2.0.0rc2 tagged version.

Now I had the idea to test it on my 32 Bit Windows machine and what a surprise, there it is. Exact the same pattern as you have posted. So it seems to be a 32 Bit issue only, platform independent, will have a look on it later.

Armin

WOOOOOOOOOOOOOHHHHHHHHHHOOOOOOOOOOOOOOOOOOOOOOOOOOO,
I don't know why but it looks like I found something.

Looking at the file librecad/src/lib/engine/rs_hatch.cpp line 188, it says:
 copy->rotate(RS_Vector(0.0,0.0), -data.angle);

But when looking at line 237, it says:
te->rotate(RS_Vector(0.0,0.0), data.angle);

So I thought, why not changing that and see what happens ;)
So I changed the line 237 to:
te->rotate(RS_Vector(0.0,0.0), -data.angle);

And now this weird looking arcs just disappeared (needs more testing, did only one test run).

Made some tests and it looks like the weird behaviour is fixed.
But I don't know if I actually fixed it or just created a new bug which will compensate the old bug.
If that was just the "-" shouldn't it behave the same way on 32 and 64 bit?

btw. LordOfBikes could you please add this "ppa:librecad-dev/librecad-stable" repo to the ubuntu install guide on the homepage?

Hi,

I haven't digged into this '-' issue yet, but what speaks against this is the angle of 0.0° when creating the hatch. It shouldn't make any difference in computing the hatch. But it changes the size of code and memory locations of binary code and that is someting that suits my results so far.

My first assumtion on 32/64 bit was killed by the fact, that the issue wasn't present on my 32 bit Ubuntu.
So I started debugging on 32 bit Windows and was surprised, that the debugging version worked well. That may be the reason on your machine, you must test with the release version if the bug is gone. The 64 bit Ubuntu release version worked well too on my machine.

Because debugging on a release version is absolute horror, I found a test case that fails even on 64 bit Ubuntu. I'm not sure yet if it is the same source of failiure, but there's something cooking and I'm working on it.

Here are my test files if you want to have a look on it:
* the pattern
* the contour
which results in this hatch


I reduced the pattern to one arc and two small line segments to keep the size.
The start, end and intersection points of the clones are computed correct with the arc from the pattern file, but somewhere the information about the entity typ are lost. The cause of this may also be responsible for swapping the start and end points on the arcs.dxf pattern which results in the inverted arcs hatch.

Armin

That's what it looks like on my ubunru 12.04 32bit with my "-" patch in release and debug mode -> my patch does not help


Is there a difference between using ubuntu 32 bit on a 32bit cpu and 64bit cpu?

same os (release mode and debug mode looks the same), without my patch, on a 0,0/350,370 rectangle
(once I had the same behaviour, but could not reproduce it -> the arcs become lines)


update:
That's strange:
When I add the line (sorry)                  
RS_DEBUG->print("fuck");
after my "patchline"
and run it -> QtCreator asks to save changes ... ->OK
My patch seems to work. After removing this offensive line, my patch seems not to work (only tested with the arcs hatch)

Looks like when I change something in the debug mode and the arcs hatch is shown properly, I can switch to the release mode and doing the same, the arcs hatch will also look good.
So I guess I have to make the changes in the release mode to check if they work or not.