Teardrop shape and roof bridge direction can’t be set along existing geometry

[pierreporte]

According to the documentation, those feature can be oriented with a variable, even though it’s not visible either in the task panel nor the property view. The user then must know the exact angle to enter. It is not possible to select existing geometry or datum to orient the feature correctly.

[Rahix]

It should be visible in the Property view for the original Hole feature:

I was considering whether to add these properties to the Hole or whether to create a VarSet each time, but thought the VarSet would just unnecessarily clutter the feature tree... But maybe discoverability is not good enough with the properties hidden on the Hole feature?

[Rahix]

It is not possible to select existing geometry or datum to orient the feature correctly.

I am personally not at all a fan of using geometry references, because they can be fragile. Also, I don't quite see how a geometry reference for the angle would help much. An edge could be a reference of the printing direction, but this would still be ambiguous as the edge can be interpreted two ways.

I did consider adding a way to encode the print orientation of a Body as a sort of body-global property, but ultimately decided not to pursue this as it adds a lot of complexity for only little gain.

[hyarion]

I did consider adding a way to encode the print orientation of a Body as a sort of body-global property, but ultimately decided not to pursue this as it adds a lot of complexity for only little gain.

How about adding a settings object that can be placed inside a body? That way you can let that define print orientation and defaults settings for features similar?
Such an object could also be extended later to read profiles to import information from the slicer about overhang threshold etc.

[Rahix]

How about adding a settings object that can be placed inside a body?

Yeah, this is what I was thinking about back then. The things is, this adds a lot of inherent assumptions (policy) about how the design features are intended to be used. It also adds a lot of complexity in how to use the addon.

We need to make the tradeoff between adding these kind of features to optimize efficiency vs. keeping the functionality general-purpose and easy to use.

I personally do not see a huge gain in these particular topics at this time. Punching in a rotation value and maybe a layer height is a matter of a few seconds. The risk of messing it up is also quite low.

Consider, on the other hand, how much it will take users to learn about the additional intricacies of such body-global settings. To keep things flexible, each ffDesign feature will now need to gain an escape hatch when the policy of the gobal settings does not fit a specific usecase. And this is yet more for users to discover and learn.

[pierreporte]

The settings object (that could be a VarSet) is the solution proposed by the FreeCAD Design Working Group for the sheet metal workbench to contain common values like thickness and bending radius (that can individual features could override). It hasn't been implemented yet and the discussion isn't over, but it would be interesting if there was a common solution. Ease of use is also consistency across the program and every add-on that diverges from FreeCAD UI/UX is harder to use as a consequence.

It is of course understandable to keep the add-on simple while it's still new.