Sketcher mini-features

[abdullah]

Well in my workflow (maybe my pulse trembles too much), DeepSOIC's idea makes sense. I was thinking only for non-continue mode (only for the traditional select+click button or hit key, which is what I mostly use). If I have to think of hitting shift, wait no it was ctrl, lets look at the status bar... then I may well click the second point and get it over with.

Nevertheless, from the feedback I see that it is a much more complicated issue regarding user experience and that what may seem as an advantage for some users is a disadvantage for others. There is no need to bring complexity if there is not an obvious general advantage.

Or a new and separate command for adding coincidence by selecting a point and automatically using the nearest point. If implemented it should work in the same way when using continue mode.

P.S. But note that this is a totally new feature suggestion. It isn't directly related to my original suggestion. My original suggestion would still apply for such command. What to do when no nearest point can be found? Produce a pop-up or use origin instead.

I think that adding a new command for something that represents a 5% of the use cases and that can be achieved with the existing implementation with a negligible "extra" effort is only going to bloat the UI and overwhelm the user.

I will wait until my pending PR regarding "hidding constraints" is merged so that I can PR another mini-feature that is already implemented (point alignment) which would otherwise conflict with the former. Then, I would like to tackle the same locking mechanism and take a look at the overlapping constraint symbol issues. Then I also have in my pipeline the geometry virtual space (a possibility to send the visualization of individual sketcher geometry elements (and maybe constraints associated with them) to a connected virtual parallel universe from which they still constraint whatever they were constraining in this universe, so that the user can concentrate in details of a complex sketch or in that area with tons of overlapping lines, or with an assistant sending all construction geometry to virtual space). For the latter I would like to have user input (not that it won't be welcome for the former), so that the end result is really useful and solves in a general way lots of the little sketcher issues.

[wmayer]

Welcome!!

Another mini-feature (well this one had quite a lot of work, but the result is mini):

So with these two checkboxes you can hide the reference constraints from the inventor view or the driving constraints or both.

This was requested here:
https://forum.freecadweb.org/viewtopic. ... 00#p169615

Pull Request:
https://github.com/FreeCAD/FreeCAD/pull/696

Sorry but I had to completely revert this PR again. After merging it I realized it causes serious problems and made the sketcher unusable.

1. when creating an empty sketch the origin point is grey (minor issue)
2. when creating a single line, leave edit mode, enter edit mode => crash
3. when setting the option to hide constraints, leave edit mode, enter edit mode => crash

The last point is so serious that if you exited & restarted FreeCAD in the meantime it's not longer possible to open any sketch for editing any more.

Furthermore, I don't consider it a good idea to make the "hide" settings permanent. It is useful to hide constraints if there are too many but it should only be temporary. However, I would prefer a way to hide them also individually. Now it's infeasible to create an own SoSwitch node for each sub-graph element because it slows down the rendering. An alternative is to use the SmSwitchboard node of the SmallChange lib.

[microelly2]

Welcome!!

Another mini-feature (well this one had quite a lot of work, but the result is mini):

So with these two checkboxes you can hide the reference constraints from the inventor view or the driving constraints or both.

This was requested here:
https://forum.freecadweb.org/viewtopic. ... 00#p169615

Pull Request:
https://github.com/FreeCAD/FreeCAD/pull/696

Sorry but I had to completely revert this PR again. After merging it I realized it causes serious problems and made the sketcher unusable.

1. when creating an empty sketch the origin point is grey (minor issue)
2. when creating a single line, leave edit mode, enter edit mode => crash
3. when setting the option to hide constraints, leave edit mode, enter edit mode => crash

The last point is so serious that if you exited & restarted FreeCAD in the meantime it's not longer possible to open any sketch for editing any more.

Furthermore, I don't consider it a good idea to make the "hide" settings permanent.

Having the temporary hiding functionality is enough.
When I deactivate the hide flag before I leave the sketcher I can reopen and edit it furthermore.

[wmayer]

Under Ubuntu an assert fails and crashes the application. Error message is:

FreeCAD: SoGroup.cpp:292: virtual SoNode* SoGroup::getChild(int) const: Zusicherung »(index >= 0) && (index < this->getNumChildren())« nicht erfüllt.

Under Windows somewhere a serious error (probably a segmentation fault) occurs which is converted into an SEH exception. This exception then is caught in GUIApplication::notify and prints this error

Unhandled unknown exception caught in GUIApplication::notify.

Afterwards the whole application gets stuck and you have to kill the process.

Part of the problem might be that everywhere inside ViewProviderSketch child nodes are accessed with hard-coded index values and cast to the expected type without checking beforehand if the cast is valid.

[microelly2]

At the moment I use this workaround to get access into the sketch after restart:

Code: Select all

FreeCAD.ParamGet('User parameter:BaseApp/Preferences/Mod/Sketcher').SetBool("HideDrivenConstraints",False)
FreeCAD.ParamGet('User parameter:BaseApp/Preferences/Mod/Sketcher').SetBool("HideDrivingConstraints",False)

[abdullah]

Sorry but I had to completely revert this PR again. After merging it I realized it causes serious problems and made the sketcher unusable.

when creating an empty sketch the origin point is grey (minor issue)
when creating a single line, leave edit mode, enter edit mode => crash
when setting the option to hide constraints, leave edit mode, enter edit mode => crash

The last point is so serious that if you exited & restarted FreeCAD in the meantime it's not longer possible to open any sketch for editing any more.

Furthermore, I don't consider it a good idea to make the "hide" settings permanent. It is useful to hide constraints if there are too many but it should only be temporary. However, I would prefer a way to hide them also individually. Now it's infeasible to create an own SoSwitch node for each sub-graph element because it slows down the rendering. An alternative is to use the SmSwitchboard node of the SmallChange lib.

No need for you to be sorry. If it causes so many issues, it is me who should be sorry for the insufficient testing. I tested quite a lot the original PR, but not the version with the latest commit. Any further change that touches Inventor nodes I will post the branch here for testing before doing the PR.

For reference SmallChange SmSwitchboard:
https://bitbucket.org/Coin3D/smallchang ... ew-default

Thanks for the pointer. This is something I have been looking for. Just a pity it does not operate on MFs for the geometry.

I have been thinking of a separate feature lately, which could potentially absorb the functionality of this commit, achieve the individual hiding you indicate without any further dependency, and at the same time provide an additional powerful feature to the sketcher (selectively hiding geometry).

The feature, codenamed "Virtual space", allows to have two (potentially more, I do not know if it is practical to have more, let's stick to two) coin3d representations under a SoSwitch (which allows to select a child, so one representation out of the ones available). The two coin3d representations are complementary, so the elements that are hidden in normal space are transfered to the Virtual space. The elements that are made visible in the normal space disappear from the Virtual space. There is a button somewhere to change the 3D view from "Normal Space" to "Virtual Space". As said, the virtual space concept works not only for constraints, it also works for geometry.

There shall be some kind of logic behind it like:
1. if you hide an element, all the constraints using that element get hidden as well.
1.1. If you make one element visible, the associated constraints get visible unless there is another control (checkboxes like the ones of this previous commit, which prevent it).
2. Helpers like (checkboxes, buttons):
2.1. Hide all driven constraints
2.2. Hide construction geometry (for those who dislike the circles of the bsplines, or the axes of the ellipses, or just want a cleaner working space)
2.3. Hide external geometry

I am not sure if Virtual space should have memory or not.

What do you think of this (the idea and the indicated implementation)?

[wmayer]

Thanks for the pointer. This is something I have been looking for. Just a pity it does not operate on MFs for the geometry.

I have added it with git commit f76a9a773e0

The feature, codenamed "Virtual space", allows to have two (potentially more, I do not know if it is practical to have more, let's stick to two) coin3d representations under a SoSwitch (which allows to select a child, so one representation out of the ones available).

This is something we already do on all view providers where for the various Display modes in each child of an SoSwitch the same nodes are used but with different draw style settings.

However, with a single SoSwitch you can only show/hide a single item. To be able to hide each constraint item individually you would need a separate SoSwitch for each item which is a waste of memory. Therefore the switch board is a good alternative because only a single node is needed.

The two coin3d representations are complementary, so the elements that are hidden in normal space are transfered to the Virtual space. The elements that are made visible in the normal space disappear from the Virtual space.

How would implement this? By moving the nodes all the time? This is considered bad practice and leads to hazardous behaviour when the re-ordering is performed during a traversal of the scene.

I would like to work on the integration of the switch board for the constraints in the next days. And at some point we have to think about simplifying the ViewProviderSketch code. At the moment several methods are of epic lengths and it's more and more a pain to extend it with new functionality.

[abdullah]

Part of the problem might be that everywhere inside ViewProviderSketch child nodes are accessed with hard-coded index values and cast to the expected type without checking beforehand if the cast is valid

This would indeed prevent severe consequences (crashes). In the little additions I have done to the inventor nodes I have replicated the pre-existing method of hard-coded index without checks. It would be great to improve this.

I have added it with git commit f76a9a773e0

Cool!

However, with a single SoSwitch you can only show/hide a single item. To be able to hide each constraint item individually you would need a separate SoSwitch for each item which is a waste of memory. Therefore the switch board is a good alternative because only a single node is needed.

How would implement this? By moving the nodes all the time? This is considered bad practice and leads to hazardous behaviour when the re-ordering is performed during a traversal of the scene.

My intention was to implement this by recreating the scene on change.

For geometry, this involves maintaining two SoMaterialBinding/SoCoordinate3/SoLineSet. On redraw, when looping through the geometry, the geometry is assigned to one or the other depending on its virtual space. Here there is no movement of nodes per se, just editing those nodes. I do not know any other way to do this. It would be great to have a SmSwitchBoard alike node that works on MF like when assigning colors.

Well I do know another way, that is using a SoLineSet per geometric element with a separator per geometric element and using SmSwitchBoard on top (In other words, replicating the constraints structure in the geometry).

If you were to choose, which one would your prefer?

For constraints, my intention was indeed to move nodes. In the reverted commit this was the case. I was thinking of using some kind of mutex to avoid any harzardous effect. However, now you made it possible to use SmSwitchboard, it is way better to use it.

I would like to work on the integration of the switch board for the constraints in the next days.

I welcome your initiative

And at some point we have to think about simplifying the ViewProviderSketch code. At the moment several methods are of epic lengths and it's more and more a pain to extend it with new functionality.

I admit to have very little knowledge of Inventor. In fact, every time I have to do something with it I struggle. However you can count with my support/ assistance/collaboration in coding or discussion or wherever as you see it best fit. Just let me know.

[microelly2]

Is there some progress on hiding constraints?
I hoped to use this functionality in my project (https://youtu.be/J4kD1LLP3uU)

but if there is at the moment no force on this I will switch to SketchObjectPython.

[paullee]

Hi, finally find this discussion thanks to microelly2 - i hope to have some thing similar and addition also ...

Make Invisible-

• Reference Constraints

• & Construction Geometry

https://forum.freecadweb.org/viewtopic.php?f=3&t=24570
https://forum.freecadweb.org/viewtopic. ... 46#p194146


Hope something can be done and make this works again! Thanks.