Page 1 of 1

[solved] Part sort of changes shape when exploded

Posted: Thu Jun 01, 2023 11:13 am
by 2CV375
Hello, I am using QCADCAM 3.25.2.0 and Windows 10 Home 22H2. When the attached file is exploded, the top slots change size. The top slots were drawn 22x41mm and 22x78mm with the bottom 26x91mm. The top slots become 18x40mm and 18x77mm when exploded in QCAD.

The part was originally drawn using Microstation and then exported as a DXF.

I clean the Microstation drawing in QCAD before adding a tool path.

Why do the top slots change size and the bottom slots do not?

Thanks.

Daniel.

Re: Part sort of changes shape when exploded

Posted: Thu Jun 01, 2023 3:06 pm
by Husky
Hi Daniel,
2CV375 wrote:
Thu Jun 01, 2023 11:13 am
The top slots were drawn 22x41mm and 22x78mm with the bottom 26x91mm. The top slots become 18x40mm and 18x77mm when exploded in QCAD.
Why do the top slots change size and the bottom slots do not?
The top slots actually drawn as a block 18x40mm and 18x77mm and then inserted and scaled to 22x41 / 22x78 with a non-uniform scale factor!

Top
x: 1.016667
Y: -1.22
z: 1.016667

The bottom slots are not scaled with such a weird scale factor what explains why QCAD has no problems with exploding them correctly. BTW - the top slots are also under a slight angle of 0.001194° what "feels" wrong too. :wink:

Bottom
x: 1
Y: 1
z: 1

Re: Part sort of changes shape when exploded

Posted: Thu Jun 01, 2023 7:56 pm
by CVH
Hi,
Exploding block references does not consider non-uniform scaling for hatches.
They are exploded based on the X-scale. EDIT: But that results in not scaled.

Considered out of scope: https://qcad.org/bugtracker/index.php?d ... sk_id=2451

The solution is to draw them so that a uniform scale can be used.
It is also not advised to use a Z scale factor that differs from 1 there QCAD tools are 2D (Top ones use factor 1.016667 or about 6.1/6)
I see no reason in using negative Y scales for symmetric shapes in Y.

Regards,
CVH

Re: Part sort of changes shape when exploded

Posted: Fri Jun 02, 2023 7:03 am
by CVH
As extra information:

An arc as boundary must be scaled non-uniform to an ellipse-arc, a circle as an ellipse.
With a difference in Block Reference scale factors more pronounced then 1.016667 vs 1.22 it is better visible that it is rendered as such.
NonUniformScaledHatch.png
H-DIA 18 SLOT HOLE PLAN Scaled 2:1
NonUniformScaledHatch.png (2.2 KiB) Viewed 8633 times

Also meaning that the top slots all have semi full ellipses with an axis ratio of 0.83333... and not scaled semi-circles as probably intended. :wink:
@ 2CV375: I would at least include boundary shapes, certainly when the intention is to explode everything in a final stage.

Why it is perfectly rendered but not exploded as it is rendered remains a mystery to me.

Another artifact of this is when a Block is scaled non-uniform with larger factors, e.g. 20x/10x, the hatch is displayed correctly but the Block Reference is not highlighted as nearest entity when hovering over most of the hatched area. One needs to point near its original sized shape. :roll:

Regards,
CVH

Re: Part sort of changes shape when exploded

Posted: Sun Jun 04, 2023 8:33 am
by 2CV375
Thank you, Husky and CVH. I understand the problem and have advised the developers of this.

I believe that much of this is a drawing that looks functional rather than is functional. I have seen the twisting in parts previously and resolved these. In many cases, while a DXF is produced, it could be faster to draw everything properly rather than relying on what I would consider artistic, not engineering, drawings.

A frustrating problem that I'm pleased is not in the QCAD software. I can also see this is a carry-on from a problem I had many years ago - with a similar resolution, draw the bits you need.

Daniel.

Re: [solved] Part sort of changes shape when exploded

Posted: Fri Jun 09, 2023 6:54 am
by CVH
2CV375 wrote:
Sun Jun 04, 2023 8:33 am
Thank you, Husky and CVH. I understand the problem and have advised the developers of this.
Seen recent changes on GitHub: https://github.com/qcad/qcad/commit/891 ... 2346b434b3
It seems that you had more luck convincing then simply reporting a bug ... That was considered out of scope. :wink:

This will probably be fixed for the next release. 8)
Thank you and thank you Andrew. :P

Regards,
CVH