GSoC 2023: Unified Measurement Facility

Contributions from the participants, questions and answers to their projects.
Discussions of proposals for upcoming events.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
mario52
Veteran
Posts: 4673
Joined: Wed May 16, 2012 2:13 pm

Re: GSoC 2023: Unified Measurement Facility

Post by mario52 »

Hi
maxwxyz wrote: Sun May 07, 2023 12:58 pm Awesome thanks! I never think of the add-ons :roll: BTW off-topic: is there a script or setting I can copy to a new machine when setting up FreeCAD to install all my last workspaces and macros?
you can create your toolBar
maxwxyz wrote: Sun May 07, 2023 12:58 pm And I am still curious if new measurement tools will be implemented.
depend number programmer volunteer for this feature

mario
Maybe you need a special feature, go into Macros_recipes and Code_snippets, Topological_data_scripting.
My macros on Gist.github here complete macros Wiki and forum.
hlorus
Posts: 30
Joined: Sun Oct 17, 2021 9:47 am

Re: GSoC 2023: Unified Measurement Facility

Post by hlorus »

Thanks for all the input, really great to see people being exited about this!

For the first part of the project i'll be occupied to create a base system that is hopefully flexible enogh to support the expected features while also allow extending it to cover other geometry types.

In the proposal i've outlined an inital implementation approach where a measurement command and a parameric object would be defined by base freecad. These would then handle the whole measurement logic and user interface. Workbenches that implement additional geomtery types would simply be responsible to translate the specific geometry into some abstract representation. Do people have an opinion / feedback on this approach? Or more specifically:

- Are there already other base commands in FC which get extended by workbenches?
- Is there already an abstract representation of geometry in FreeCAD's base that could be used for the measure command which shouldn't know about specific geometry types?
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: GSoC 2023: Unified Measurement Facility

Post by Zolko »

onekk wrote: Sun May 07, 2023 8:45 am I make model for other people and having a quick way to makea screenshot of a dimension that lacks of a proper measure in project will be very welcomed.
...
Avoiding the external annotation phase would be great.
this exists in Assembly4's measurement tool

maxwxyz wrote: Sun May 07, 2023 9:04 am It would be beneficial if the tool could support or asks for the selection mode of the first and second input, e.g. any geometry, edge only, and so on.
...
It would be also great if the tool could output the result in coordinates (absolute and relative to first selection)
this exists in Assembly4's measurement tool
try the Assembly4 workbench for FreCAD — tutorials here and here
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: GSoC 2023: Unified Measurement Facility

Post by openBrain »

hlorus wrote: Sun May 07, 2023 3:07 pm In the proposal i've outlined an inital implementation approach where a measurement command and a parameric object would be defined by base freecad. These would then handle the whole measurement logic and user interface. Workbenches that implement additional geomtery types would simply be responsible to translate the specific geometry into some abstract representation. Do people have an opinion / feedback on this approach? Or more specifically:
At the very low level, to keep things "simple" and maintainable/extensible implementation, I would have imagined something like :
* A selection observer class in charge of creating and maintaining a list of "elements of interest" -- for example when selecting an arc of circle, not only the arc but also its center can be used for measurement --
* A measurement class using the above one to compute real measurement values from available elements
- Are there already other base commands in FC which get extended by workbenches?
Yes there are. How are you imagining it ? All Python ? C++ calling Python extensions ?
- Is there already an abstract representation of geometry in FreeCAD's base that could be used for the measure command which shouldn't know about specific geometry types?
Yes we should find. But how are you imagining measures to be displayed ? Is that something permanent (saved in document) ? Does it appear in the tree as an object ?
hlorus
Posts: 30
Joined: Sun Oct 17, 2021 9:47 am

Re: GSoC 2023: Unified Measurement Facility

Post by hlorus »

openBrain wrote: Sun May 07, 2023 5:12 pm At the very low level, to keep things "simple" and maintainable/extensible implementation, I would have imagined something like :
Interesting, workbenches would then implement an inherited observer class while the measurement class will be defined only once in FC base?
Yes there are. How are you imagining it ? All Python ? C++ calling Python extensions ?
My plan was to have only one actual command. Workbenches would register "GeometryTargets" at startup, either from python or c++. These would be responsible to represent specific geometry in an abstract way. E.g. an angle mesurement would require 2 line GeometryTargets which could be represented in a variety of ways, like by 2 mesh vertices, a mesh line or a än edge of a solid etc.
Yes we should find. But how are you imagining measures to be displayed ? Is that something permanent (saved in document) ? Does it appear in the tree as an object ?
As a parametric element which is displayed in the tree and has s representation in the viewport. However the same infrastructure should also support to display just a temporary measurement while running the command.
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: GSoC 2023: Unified Measurement Facility

Post by openBrain »

hlorus wrote: Mon May 08, 2023 6:19 am Interesting, workbenches would then implement an inherited observer class while the measurement class will be defined only once in FC base?
Not necessarily an observer. It could be that workbenches just have to implement a specific method that in turn will be called by the base system.
My plan was to have only one actual command. Workbenches would register "GeometryTargets" at startup, either from python or c++. These would be responsible to represent specific geometry in an abstract way. E.g. an angle mesurement would require 2 line GeometryTargets which could be represented in a variety of ways, like by 2 mesh vertices, a mesh line or a än edge of a solid etc.
Yes, something like this makes sense.
As a parametric element which is displayed in the tree and has s representation in the viewport. However the same infrastructure should also support to display just a temporary measurement while running the command.
Parametric is challenging at the moment because it relies on topology, which isn't stable yet (work is on going). But still interesting to foresee such a possibility.
I like idea that a measurement is created as a temporary object, but user can "fix" it as being an object.
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: GSoC 2023: Unified Measurement Facility

Post by yorik »

Welcome on board David! Looking forward to this!
hlorus wrote: Sun May 07, 2023 3:07 pm In the proposal I've outlined an initial implementation approach where a measurement command and a parametric object would be defined by base freecad. These would then handle the whole measurement logic and user interface. Workbenches that implement additional geometry types would simply be responsible to translate the specific geometry into some abstract representation. Do people have an opinion / feedback on this approach? Or more specifically:
There have been two directions in the past: One is to create an actual object that appears in the tree view, another is a kind of "shallow" measurement system that displays measurements in the 3D view (and maybe other outputs such as the Report window) but does not create an actual object in the model.

Basically there are advantages to both systems, creating a zillion of small actual objects would make your model noticeably slower, while solution 2 keeps the model light, however solution 1 makes dimensions stick across file saves. In an ideal world, we would have both :)

I would suggest concentrating on one, but keep the other as a possible extension

If you go the object way, I would imagine it could be like the basic Part Feature: There is a base class, that is used by all Part objects, and has a basic view provider, and it can be extended both in C++ and in Python.
hlorus
Posts: 30
Joined: Sun Oct 17, 2021 9:47 am

Re: GSoC 2023: Unified Measurement Facility

Post by hlorus »

yorik wrote: Mon May 08, 2023 8:35 am Welcome on board David! Looking forward to this!

If you go the object way, I would imagine it could be like the basic Part Feature: There is a base class, that is used by all Part objects, and has a basic view provider, and it can be extended both in C++ and in Python.
Thanks for the pointer, i'll definitely investigate that system.
With such a base feature what functionality would features that are inherited from it implement? Would they simply be Mesurement objects, like MeshMesurement, PartDesignMesurement that support measurements in the scope of their workbench?
IMO that could be kinda limiting as it wouldn't ever allow a measurement between elements of different geometry types.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: GSoC 2023: Unified Measurement Facility

Post by onekk »

An alternative would be a FeaturePython object (only one) that it will be reading a measurement list, this should be more fast than having multiple documentobjects.

Measurement list should contain eventually a flag that will disable visualization of certain measurements.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: GSoC 2023: Unified Measurement Facility

Post by yorik »

hlorus wrote: Mon May 08, 2023 11:14 am With such a base feature what functionality would features that are inherited from it implement? Would they simply be Mesurement objects, like MeshMesurement, PartDesignMesurement that support measurements in the scope of their workbench?
IMO that could be kinda limiting as it wouldn't ever allow a measurement between elements of different geometry types.
Basically you'd need to think of a "common" set of properties, behaviours, etc... that all those usecases would need. Thinking out loud, I'd say you should focus on getting clear, useful info out of the measurement, and a nice UX workflow to place those dimensions on a model.

The types of geometries and objects is not really a big issue I think, if you design the system to be modular enough and other "kinds" of measurements can be added later. For ex, I would imagine you could start with just vertex-to-vertex situations, or for ex. face area, then build upon that and add more types (line-to-point, arc-to-center, etc...) if you design the system with that in mind, adding more types (or in the base class or in derived classes) will be easy.

I would imagine the main reimplementation other workbenches would do is to make the dimension show differently on screen (I'm thinking Draft dimensions here). But for ex. Sketchers users always beg to allow the internal constraints to be visible outside the sketch. This could be useful here too

But for me the crucial point to achieve world success and fame is to design a cool UX flow to add those dimensions. Do you pick geometry on screen first? Do you place the dimension somewhere or is it placed automatically? How can you edit it afterwards? etc.
Post Reply