[fixed] Regression-TD-dimension "lines" aren't generated/updated correctly

[M4x]

Hey everybody,

I think I've found a regression regarding the dimensions within the TechDraw workbench.

I'm currently working on some drawings and discovered, that the "lines" which are showing for example between which two edges a dimension is "measuring" aren't always reaching those two edges. Further more, they're staying at the location the dimension was generated at. If I'm dragging it somewhere else, the lines are staying at there original location.

To make it clear, I've made some screenshots and described what I did using the "file comment" (below each picture).

Front view and a detail view without dimensions

Snip macro screenshot-7015e5.png (20.36 KiB) Viewed 1550 times

Selecting a vertex and an edge

Snip macro screenshot-b24eeb.png (10.25 KiB) Viewed 1550 times

Insert a vertical dimension - it gets created on the right side. The "lines" which are belonging to the dimension aren't reaching the vertex or the edge!

Snip macro screenshot-5c69bb.png (11.73 KiB) Viewed 1550 times

When dragging the dimension over to the left side, the lines are responding but are staying at there original location.

Snip macro screenshot-1b3780.png (11.73 KiB) Viewed 1550 times

At first I've thought that it might has something to do with my current project (several bodies and drawings). It used to work with older versions (v0.19). I've made changes to one of the models and have to correct the dimensions which got hit by the topological naming problem. But it has nothing to do with that either. I can reproduce this behavior with a simple example file. A recompute doesn't help.

Example_TechDraw_dimensions_reg_v1.FCStd

(19.87 KiB) Downloaded 35 times

Furthermore, it's working with an older version!

working
OS: Ubuntu 20.04.1 LTS (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22039 (Git) AppImage
Build type: Release
Branch: master
Hash: 2bfc6301bc80c0344cbf13dbfe041fbd78cac93d
Python version: 3.8.2
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

not working
OS: Ubuntu 20.04.1 LTS (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22846 (Git) AppImage
Build type: Release
Branch: master
Hash: 1f46b72491a0008384a6db4f2615a656249f6f08
Python version: 3.8.6
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

Since I can't upload more files in this post, I'll show another example and the end result with both versions in the next post.
Please verify if you're seeing an identical behavior. I'd be very happy for ideas on how to solve this problem.

Thank you!

P.S.: If someone has a more suitable thread title in mind, please go ahead

[M4x]

How it should look like

How it should look like

Snip macro screenshot-c2aa4f.png (26.55 KiB) Viewed 1546 times

How it should NOT look like

How it should NOT look like

Snip macro screenshot-c1b14e.png (20.8 KiB) Viewed 1546 times

Example 2 (front view, horizontal dimension)

This shows where the horizontal dimensions was created at and which edge and vertex I've used to create it. The "line" which belongs to the dimension isn't reaching the vertex.

Snip macro screenshot-c36123.png (17.65 KiB) Viewed 1546 times

Example 3 (front view, vertical dimension)

Selecting a vertex and an edge

Snip macro screenshot-d31ebc.png (15.54 KiB) Viewed 1546 times

Inserting a vertical dimension - it gets created on the left side. The "lines" which are belonging to the dimension aren't reaching the vertex.

Snip macro screenshot-d5e7bd.png (17.69 KiB) Viewed 1546 times

[aapo]

I've made changes to one of the models and have to correct the dimensions which got hit by the topological naming problem. But it has nothing to do with that either. I can reproduce this behavior with a simple example file. A recompute doesn't help.

Thanks for the example file! I did a git bisect, and I believe that I found the problematic commit ad1b48b73d72f01b7bd4cc1fbcc110574e11dcb9. It seems Wandererfan had improved dimension endpoint placement logic, but had forgot that apparently the later logic always uses the startpoint of the edge, and not the closer point of the edge. The first version failing your test case seems to be 22306.

Here is the link for the problematic commit in Github: https://github.com/FreeCAD/FreeCAD/comm ... 574e11dcb9

Here are the bisection steps, to save time I bisected only the commits touching TechDraw files, which is generally not a good idea, if the problem is cascaded from somewhere else, but seemed to work this time:

Code: Select all

aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect start -- src/Mod/TechDraw
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect bad
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect good 864483d550bf5a4664d4b89ea26d729cca8b53a4
Bisecting: 26 revisions left to test after this (roughly 5 steps)
[f2a9f712e8d68ee2393d0fe748c02096c4148a32] [TD]Correct font size on PDF export
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect good
Bisecting: 13 revisions left to test after this (roughly 4 steps)
[ad1b48b73d72f01b7bd4cc1fbcc110574e11dcb9] [TD]fix V2E DistanceX,Y
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect bad
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[abd18ff88f7682e9b1160c36bb785b14a33473ef] [TD]fix showSectionEdge preference
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect good
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[cc81f791da3fb5e19eede440170b3118f5a8a65c] [TD]change Angle Dim tolerance format
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect good
Bisecting: 1 revision left to test after this (roughly 1 step)
[08ba104d87d5a689309fe7db4ffc37ce51262e25] [TD]remove restrictions on Edge-Edge Dims
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[4344f6bc089d1c4f06949f24427f453dbba517f1] Fix typos in source comments
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git bisect good
ad1b48b73d72f01b7bd4cc1fbcc110574e11dcb9 is the first bad commit
commit ad1b48b73d72f01b7bd4cc1fbcc110574e11dcb9
Author: wandererfan <wandererfan@gmail.com>
Date:   Sat Aug 29 19:39:51 2020 -0400

    [TD]fix V2E DistanceX,Y

 src/Mod/TechDraw/App/DrawViewDimension.cpp | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)
aapo@leastweazel:~/software/FreeCAD/freecad-code$ git rev-list --reverse HEAD --count
22306

It should be relatively straightforward to fix this now, after finding the problem. I'll probably need to make a Github account, though, in order to make pull-requests.

[aapo]

Okay, I made a pull request https://github.com/FreeCAD/FreeCAD/pull/4044, which should fix the issue. It reverts back to the old logic, which is certainly not perfect. However, optimal selection of which endpoint on the edge to use is impossible, because it depends on which side of the points the dimension label has been put, and the user can change it afterwards by dragging. Unfortunately, the endpoints are only selected once when creating the dimension, so this cannot be fixed in the way Wandererfan was apparently trying without quite drastic changes. In the absence of Wandererfan, maybe Yorik could test this simple fix, and commit the pull request if it works for others, too?

pinged by pinger macro

EDIT: I forgot to branch before pushing the pull request into GitHub, so I force-pushed the original pull request empty, which closed it; so that I could re-branch and open a new pull request with local branch other than master (which is recommended, I believe?). Anyway, pull request is now 4044 and not 4042 (which is empty and closed).

[M4x]

Awesome, thank you very much! If a ticket is still needed / wanted, I'd be happy to create it.

[aapo]

Awesome, thank you very much! If a ticket is still needed / wanted, I'd be happy to create it.

Hi, I believe that a bugtracker ticket is not wanted for a problem this small, I think those are reserved for cases for which there are no immediate simple fix available right away. I think that the biggest challenge here is to get any of the real developers interested on completing the pull request, or perhaps fixing the bug themselves, as there might currently not be any real TechDraw coders with commit authorization left, I'm afraid.

[Syres]

I think that the biggest challenge here is to get any of the real developers interested on completing the pull request, or perhaps fixing the bug themselves, as there might currently not be any real TechDraw coders with commit authorization left, I'm afraid.

Thanks for the PR, I'm about to do some important TD work for my house and hopefully I'm not impacted by this regression due to the geometry I'm using. Normally i would just revert ta month or two old build but that went out the window with my old hard drive, DR was invoked but was from late 2019.
When the house chaos has subsided, I'm going to allocate some time to learn how Techdraw hangs together, my C++ skills are pretty poor but I'm prepared to help out with bug fixes in the future.

[M4x]

Maybe Uwe could step in regarding this PR?

pinged by pinger macro

[uwestoehr]

Maybe Uwe could step in regarding this PR?

There is a PR to fix this and I have no commit rights. All I can do is try the patch and state if it fixes the problem. But I think, this is already the case, right?

[M4x]

Thank you for your fast reply! If you could test the PR, that would be very nice. I assume, that in this case yorik (or someone else - hopefully) wouldn't have to test it themselves.