New feature demo: Measurements of selected elements displayed in bottom bar

General Development
1

Hello, for making measurements in parts and in assemblies, for example the axial distance between cyclindrial surfaces or the distance between parallel planar surfaces, or parallel edges, I created a modification which displays various measurements in the bottom bar, based on the items currently selected.

The following measurements are performed:

1 element:
___Face: Display area
___Edge, Wire: length
___Solid, Compound, Compound Solid: volume
___Vertex: Position (TODO)

2 elements:
___Faces: total area
_____Parallel: distance
_____Non-parallel: angle (TODO)
___Edges: total length
_____Parallel: distance
_____Non-parallel: angle (TODO)
___Vertices: delta XYZ, distance
___Solids: total volume (TODO)

3+ elements:
___Faces: total area
___Edges: total length
___Wires: total length (TODO)
___Vertices: amount
___Solids: total volume

All code is in a new C++ file in src/Gui.

It uses Part::Feature::getShape and Selection().getCompleteSelection(); it implements Gui::SelectionObserver::onSelectionChanged to listen for selection events.

Once the TopoDS_Shape is obtained using Part::Feature::getShape all measurements are done using OpenCascade.

There are commits on the vanilla freecad repo, as well as linkstage3. The code is identical across these 2 repos.
In Application.cpp, the class is instantiated, since it inherits Gui::SelectionObserver, it will automatically be registered as a selection observer and receive events.
In src/Gui/Selection.cpp at the very least calls to getMainWindow()->showMessage have to be removed or commented out, otherwise the measurement message might be overwritten. It takes over the role of some of the code in Selection.cpp, specifically the code which shows info when selecting an element. Probably some of that info should be displayed by this new code as well if this code were ever to be merged.

Some ugly things:

  • I had to link Part to the Gui module in order to invoke Part::Feature::getShape, needed to get the TopoDS_Shapes to perform measurements with.
  • I had to add ${OCC_INCLUDE_DIR} to CMakeLists.txt in order to use OpenCascade from the Gui module. I think the code has to be moved elsewhere ideally, but I do not know where.
  • The class is initialized as the last statement of Application::Application() in Gui/Application.cpp. There must be a better entry point for this code more consistent with the rest of the codebase, but I am unsure where to put it.
  • When performing control+A on a large assembly, your PC will emit the magic smoke or at least consume 100% CPU for longer then I am willing to wait. So a mechanism is needed to handle very large selections. For now limiting the selection size would likely fix this problem. Limiting to 10 selections should be a reasonable compromise.
  • Some code can be removed from Selection.cpp since it no longer needs to display messages with info about selected elements. This allows a minor restructuring of Selection.cpp which I have not done yet. Right now I just uncommented showMessage() invocations. In linkstage3 branch I also remove some of the code which generates the old selection summary, but also on this repo I have not fullt removed all unused code from Selection.cpp yet.

Future improvements:

  • Apart from moving the code elsewhere in the codebase to avoid having to link Part to the Gui module and having to add OpenCascade include directories to the GUi module, angular measurements would be usefull addition.

Other limitations:

  • Currently it passes a tolerance value of 0 to OCC for checking if surfaces/axis/edges are parallel. In my tests it sometimes does not detect the paralleism, especially in A2+ assemblies. I am not sure what the ideal tolerance values would be.
  • Units are not taken into account, there are no units. With some minor change it could display the correct units.

The goal of this code is to avoid having to use the Part_Measure_X commands and and for me to be able to perform axial measurements on cylindrical faces. That was the prime motivator for this piece of code.

I have made the commit on the 20.2 tag in FreeCAD vanilla and on one of the latest daily commits on the LinkStage3 repo:
The main piece of code is here: https://github.com/Celemation/FreeCAD/blob/joel_selection_summary_demo/src/Gui/SelectionSummary.cpp
This commit on the FreeCAD repo contains all the changes needed: https://github.com/Celemation/FreeCAD/commit/e938a6ad7078472e7ea6ae1b059d512a5a570a96
On the LinkStage3 repo the changes are done over three commits (1 initial comit with 2 minor revisions): https://github.com/EDG5000/FreeCAD_RT/commits/20220404-stable-joel-edits/src/Gui

I’m happy to hear any feedback.
vid1.gif
vid2.gif
vid3.gif

2

This probably needs to all go into the Part module rather than Gui

3

That would avoid having to adjust the target_link_libraries statement as well as the target_include_directory in the CMake file. It seems the overall pattern in the codebase is that the code in the Part module is not exclusively used for Part Workbench features, but also for some shared code. E.g. the Part_Measure_X commands are implemented in Part but made available also in other workbenches.
This feature is globally active and should work with all workbenches, but I also had the feeling that Part maybe the best place.

4

Would it ne possibile to add radius and approx radius of bsplines?
All these measurements features would be a great add for FC interface

5

I don’t quite understand how you’ll get a radius for bsplines but +1 for displaying circle radius and maybe also ellipse major and minor radius

6

I use it in my Caliper tool to get the approximation of a radius of a shape with bspline, and often happens with STEP models

https://forum.freecadweb.org/viewtopic.php?p=257476#p257476
some tips and code at the thread

If you have a B-spline curve you can “bi-arc” it and then you see directly the radius of each arc. Ideally the radius of all arcs is equal.

bspline=Gui.SelectiongetSelectionEx()[0].SubObjects[0].curve
arcs=bspline.toBiArcs(0.0001)
arcs[0].Radius
arcs[1].Radius

>

Caliper @line 1391

```text
                    arcs=nwshp.Edges[0].Curve.toBiArcs(tobiarc_tol)
                    sayerr('BSpline approximated to Arc')
                    #print (arcs[0].Radius)
                    #circ=arcs[0].Curve
                    bbxCenter=arcs[0].Center
                    rads = []
                    for a in arcs:
                        rads.append(a.Radius)
                    r0 = rads[0]; delta_tol = False
                    for r in rads:
                        if abs(r0 - r) > tobiarc_tol:
                            delta_tol = True
                    if delta_tol:
                        sayerr("more than an Arc in Bspline approximation!")
                        sayerr("only the first is dimensioned!")
                        for a in arcs:
                            say('Radius: '+str(a.Radius))
                    #print (arcs[0].Center)
                    #arcs[1].Radius

7

Hi Saturn
This looks very similar to the Quick Measure addon so if you are working with A2+, want to report the measurements in the units that are in the settings or want to paste the results to the clipboard, Quick measure is still available.
Dan

8

Thanks for pointing out, I was not aware of that addon. I gave it a try and it is great, it takes the kinds of measurements I wanted to do, and also does a point from plane distance measurement, it’s perfect.

9

so are you abandoning your C++ project?
Are we missing the option to have basic measurement information tips in FreeCAD without having to install an add-on?
Most of CAD sw just have these…

10

Why reinvent a ton of times the wheel.

There are around some measurement tools, why not trying to coordinate efforts to modify the actual tool to make one most useful?

I wonder why this “reasonable” approach is not taken in account.

you want to modify a software, try to guess what is already present in source code and submit a PR, maybe prior discussing the thing, in this case a post here with this title:

“Possible way to improve measurement tool” or

“Anyone interested in collaborating in improving measurement tool” or maybe:

“I’m volunteering on improving existing measurement tool”

Or similar, probably offering help will get help from some developers that most probably has something in his “to do list” and could share some hints and maybe some wip code to improve or develop further.

Or I have too much expectations.

wmayer or yorik or maybe Kunda1 I think will be very happy to supply some suggestions.

Regards

Carlo D.

11

there were many discussion on that… i.e.
https://forum.freecadweb.org/viewtopic.php?f=3&t=34213

unfortunately it seems that it is not easy to get a common consensual approach

12

I agree that collaboration is difficult, but as said wasting efforts is a bad thing.

Trying to involve some “developers” should be a way to improve things, as at the very end someone has to “validate” the PR you maybe had done with many “hard work”.

I know very well difficulties in talking with other people, even taking in account that as English is not my mother language, there could be some “mismatch” in what I write and what the recipients is guessing, and sometimes I have done some mistakes, but after some clarifications, I have found very little answers without a decent reason about why the ting we are discussing is not doable.

Sometimes it is simple that “there are other thing in my to do list prior to this thing”, or “this change is involving changing in a too dep way the code is working”, or other “reasonable answers”, or maybe a workaround, or a macro that will do same thing.

But as some matters have a “general consensus” about the fact that “how is actually working” is suboptimal or “not complete” or “almost useless”, some “offer for help” will be a clever move, in general, as once worked with some developers, probably it will be more easy to “break the ice” and demonstrate your “good will”, as it is not uncommon, that people came here trying to “change the world” and their efforts will result in “nothing” or “a little thing”.

As there are around as example in @Kunda1 signature “low hanging fruits” in code to improve, probably, if anyone is “willing to help” solve some of these problems should be a “good entry ticket” to FreeCAD developers team.


https://tracker.freecadweb.org/view_all_bug_page.php?filter=63aecdb9328d9

But the link is prior to GitHub migration, but probably they could useful, if not ask @Kunda1

https://wiki.freecadweb.org/Help_FreeCAD


It will show your skills and probably introduce yourself better than many long post and elaborate ideas.

I have contributed on small things, I don’t remember why my name is on the FreeCAD credits list, but probably it is about some errors reports or some other little thing, so a very small contribution, and I have edited some Wiki Pages, reported some mistypes and similar things, not a big contribution, but many small contributions will improve FreeCAD, and as we probably are here to discuss with the end goal of improving FreeCAD, better a little thing than nothing.

As FreeCAD is complex without some developers help is very difficult to make a decent work on sources, especially if they are C++ sources, so collaborations is the only way I see.

If not fork and create your own version, but as FreeCAD sources are not easy and very big to be managed by a small team of “one person” and few helpers, it is not even this a clever move.

The above are as usual my personal opinions only, as I’m an users, maybe skilled but not involved in FreeCAD development, if not for bothering some developers from time to time. :blush:

Regards

Carlo D.

13

The Quick Measure workbench works exactly as I envisioned for this feature, although it does take 1 more click than the always-active feature from this post. 1 click is really a minor inconvenience for taking a measurement though.

Automatically showing measurements has the downside that is sometimes takes a long time to compute values (it seems volumes for compound solids are problematic, I might have to disable that altogether). So the approch taken by the Quick Measure WB makes sense in this regard.

I might take a look at how easy it would be to port the Quick Measure code to C++ then that might result in a feature that requires less clicks and window real estate than the current Quick Measure workbench.

Another option would be to tweak the Quick Measure tool to allow docking the measurement window permanently. That would be a straight forward approach if the goal is primarily to reduce effort needed for taking measurements.

14

ok, so this option has gone again…

15

I consider measuring as a separate function from designing or drawing. The main time I measure is when I have imported a step file or opened someone’s assembly file and I’m measuring between parts so a continuous output of numbers the rest of the time is not needed, and an add-on was fine with me. Docking QM or a similar tool permanently IMO would be a waste of screen space.
Using a dialog with a text box gave me a better way to explain the output of numbers rather than just printing a bunch of numbers and hoping the user could guess what the output meant. The textbox also allowed an easy copy/paste feature. Using a dialog box let me add buttons for options: Where is the origin in a step file? Use the origin button to find it. Do you want to measure from the midpoint of an edge? Select an edge and use the midpoint option to create a point to measure from.
This tool was created because I had a hard time figuring how to use the other available measuring tools when I wanted a quick measurement between features. Other measuring tools will be needed for more complicated tasks.

Saturn
Good input. I’m not a programmer so my code is weird.
Dan

16

Thanks for the great job done here! :smiley:

TLDR: This is the feature a lot of users expected for a long time.
Already existing more complex tools with graphical display and some panel menu are very useful as well for more informations or for complex measurements.
However, IMO your tool is definitely neccessary, it avoids carpal tunnel syndrom. FreeCAD needs it as a standard C++ tool in base code.

Full text:

+1 clic is an inconvenient IMO, such tool is very useful and often used, the more the use the more the clics.
Protect users from carpal tunnel syndrom is very important.

Automatically showing measurements has the downside that is sometimes takes a long time to compute values (it seems volumes for compound solids are problematic, I might have to disable that altogether). So the approch taken by the Quick Measure WB makes sense in this regard.

Sure, so maybe you should delete measurement features which are too CPU consuming. Or add an additional shortcut to lauch the complex part of the measurement? So that th user will decide to get or not full measurements informations.

I might take a look at how easy it would be to port the Quick Measure code to C++ then that might result in a feature that requires less clicks and window real estate than the current Quick Measure workbench.
Another option would be to tweak the Quick Measure tool to allow docking the measurement window permanently. That would be a straight forward approach if the goal is primarily to reduce effort needed for taking measurements.

IMO panel menu for existing measurements tools are great, but it clutters the screen and requiere to download addons and/or load WB. Not so easy for beginers.
A text string on bottom of the screen as you done, futhermore as in status bar which is empty, that’s perfect at first sigh for beginers and for everyone, that’s actually the best way to save screen space for modeling. Then if users want more informations, they will search for more complex tools with graphic panel/popup/buttons/icone interface then they’ll download then clic to acces appropriate tools.

Go ahead! :wink:

17

Probably the best way will be to have a way to make some measurement in the 3d view using the “right click menu”.

Now the behaviour (0.20.2) is that when you select something you will have in the statusbar these informations:

Preselected: “description of what yo have selected” and some data.

But as example for an edge, it will be interesting to have the length if is a line or maybe if is a circle even the radius and the center.
now there is three coordinates, that is the point on which you clicked, interesting, but not very useful.

adding “Curve type” = “Line circle, or similar” the start and ending point coordinates, and maybe for circular arcs, start and end degrees, radius and center.

As example using python console on a circular edge I get:

print(obj.Shape.Edges[7].Curve)
Circle (Radius : 2.675, Position : (0, 1.90348e-15, 8.5725), Direction : (-0, 2.22045e-16, 1))

This should be achieved in the stock FreeCAD interface, without the need to load anything.

Probably it will be very useful, at least for edge, when modelling.

For faces, what will be a decent set of information, maybe the nature of the surface (plane, or BSplineSurface or similar thing).

Probably for more “complete” info will be interesting to have when you select and right click a menu other than Navigation with maybe an “Geometry Info” items that will supply only when selected more informations.

This should be not a complicated task even in C++ and an interesting addition.

Regards

Carlo D.

18

IMO not the best:

  • it adds 1 clic plus moves of mouse → carpal tunnel syndrome disease.
  • measurements information are not displayed by default, then some beginners will not see it easily and will still ask us “how measure elements in FC?”

Now the behavior (0.20.2) is that when you select something you will have in the statusbar these informations:

Are you sure about that? I hope I get you right, but AFAIK now element information is displayed in status bar when mouse cursor spend over elements, no any selection is needed or even efficient.
Hence element information could be temporarily overwritten by measures information, when elements are selected, right?

In some big CADs such measurements text information at first sight provide only mains dimensions, not too much information.
Type of elements is even not mentioned:

  • if you read “D=50” you know it’s about a diameter of 50mm (360° closed arc in FC)
  • if “R=33.5” you know the element an arc (+ center, arc length, angle, cord length or whatever…)
  • if “length=xx + start-end points coordinates” means the element is a line (+ delta x,y,z if you want)
  • “length (only) = xx”: means a accumulation of selection of lines and/or arcs or bsplines
  • etc…
  • no solid, no weight, no area information available in such tool for quick look.

IMO that is the good approach. Very clear, simple, readable, lightweight, fast: powerful.
If the user want more measurements information he has to use a more specialized tool, like existing measurement tools in addon manager or in some WB.
That’s my opinion, but I’m just a CAD experimented user. I let developers talk now.

19

How many times you want a complete info about an object regarding measurement, not every time you select them. so carpal tunnel is not a problem at least in this case.

In fact, only when I select explicitly an element additional infomation should be displayed, not to overload FC when not needed to measure thing, but this is a personal preference.

Main dimensions for a circle “radius, center” are the data you need to know for a line, length and probably start and ending point.

I admit that this things has to be discussed by users and developers, to evaluate:

  1. coding cost of additional info
  2. information that are needed and are easily retrievable in term above 1)
  3. better way to show informations, in the statusbar seems a good place, any additional thing should make 1) more heavy

Probably an alternative way could be to show measurement after some time spent on the element, like after 1sec additional infos will appear in the status bar. But I don’t know what this behaviour will affect point 1) above.

If you want a more complete info something should be available in the main interface, for useful info, for more “specialized info” an addon or a WB should be appropriate.

When I model I use mainly scripting so absolute informations, like lengths and start and end point position will suffice for me, to verify things during creation, and I think that even when modelling with GUI you don’t need usually informations such tangents, derivative or other things, maybe [pnt, dir] that you will find the Part.make… methods will be interesting, not much more.

I’m not considering things related to links and compounds, as the “global placement” could enter the game, even in Vertex positions.

I’m made this considerations for measurements made on solids shown on 3d view only, as usually measurements are useful when you as example convert a solid from a mesh.

Main point IMHO is to improve the ability to evaluate quickly things, I select and edge of a solid and I have his length and his build data (if they are not to complex to retrieve).

As example I doubt that someone will need “center of Mass”, or similar data directly in the interface as usually you need this data when as example you want to create something using draft or Part, as in Sketcher (or Part Design) the workflow is completely different, as for a constraint driven modelling, absolute positions are not useful, i could make four points and then assign lengths later with constraints.

Regards

Carlo D.

Edited to correct considerstions about carpal tunnel, my intention was not to underestimate the problem. :smiley:

20

When a user makes a circle and another feature touches the circle it will create two arcs. I found it hard to determine arcs from circles.
When measuring an arc or circle, sometimes I wanted the radius and other times I wanted the diameter, I made errors by multiplying and dividing in my head.
For the two reasons above I included both radius and diameter in the output.
If I wanted the start or end point of a line or circle I clicked on it to retrieve the x, y, z position.


I don’t use scripting to model parts so I never considered that.

If I were to further develop the Quick Measure tool I would like to be able to set the number of decimal units separate from FreeCAD’s units and the decimal units for degrees separate from others. The measurements are converted in separate Def statements for this reason.
These are just some reasons why the tool ended up the way it is. I know other people have other opinions.
Dan