#2683 Refinement transformation

[abdullah]

This is to notify that I will be working in PDN transformations code to add a refinement transformation (similar to the scale transformation).

Original feature request:
https://www.freecadweb.org/tracker/view.php?id=2683

[ickby]

How would a refine transformation work? Isn't this something that is always applied to the whole solid?

Apart from that I really hate how refine currently works, with the global option. This is rediculus, and there must be something done about it. I still have the feeling the refine operation is something that should be done in each feature automatically. The only thing that prevented me from introducing it directly​ in the part design features is backwards compatibility. Also a feature is bad imho, as it unnecessarily bloats the tree.

My current idea.is to have a hidden property in the body which enables feature refine, and set it by default to true. Than on migration this property would be set to whatever the current global variable says, this provides the backwards compatibility.

[chrisb]

I still have the feeling the refine operation is something that should be done in each feature automatically.

Is that the same as setting the Preferences->PartDesign->Automatically refne... options for everyone?

The only thing that prevented me from introducing it directly​ in the part design features is backwards compatibility. Also a feature is bad imho, as it unnecessarily bloats the tree.

I would rather have a clean solution than backwards compatibility. And a non bloated tree is always welcome.

I think backwards compatibility is nice to have but I guess that most models are not developed further and further over years. They rather reach a final state, get printed, machined or assembled and thats it. (The pros here may correct me).

[Jee-Bee]

Is that the same as setting the Preferences->PartDesign->Automatically refne... options for everyone?

According to the link to the tracker it goes about openSCAD refine. that one is parametric (and therefore in a lot of circumstances better).

I would rather have a clean solution than backwards compatibility. And a non bloated tree is always welcome.

I think backwards compatibility is nice to have but I guess that most models are not developed further and further over years. They rather reach a final state, get printed, machined or assembled and thats it. (The pros here may correct me).

+1

[abdullah]

Thank you for your feedback.

How would a refine transformation work? Isn't this something that is always applied to the whole solid?

I have not given it too much of a though yet. Sure it is applied to the whole solid. One quick thought is to apply it to the support, once the transformation is applied to the support. It need not be a transformation feature.

Apart from that I really hate how refine currently works, with the global option. This is rediculus, and there must be something done about it.

Current refine is useless IMO. It makes a single version of FC be incompatible non-standard so as to allow backwards compatibility. Either do it or do not do it but do not try

I still have the feeling the refine operation is something that should be done in each feature automatically.

I will reply to you with a question, wouldn't an automatic refine operation create more problems with the toponaming issue, i.e., making it easier for the model to break?

When answering take into account that a huge amount of the flexibility in the reordering of the features that PDN provides may be rendered useless if models start breaking into pieces when reordering features due to the refine option being enabled.

If the answer is no, then it should make an automatic refine. If it can not be answered negatively, then a selective refinement makes a lot of sense, so as to clearly isolate the weakest robustness points in a model.

The only thing that prevented me from introducing it directly​ in the part design features is backwards compatibility.

I think we can produce something that allows opening a design of v0.16 with v0.17 (migration involved), and still enables (by default) appropriate refinement in v0.17. I think there is no better moment than now. We already broke with the way of working in 0.16. We have a migration tool to bridge the two. The only problem I see with automatic refinement being introduced exactly as you describe is the potential aggravated toponaming problem. But for whatever we agree to be the best solution I think the moment to introduce it (by default) is now.

Also a feature is bad imho, as it unnecessarily bloats the tree.

I agree.

My current idea.is to have a hidden property in the body which enables feature refine, and set it by default to true. Than on migration this property would be set to whatever the current global variable says, this provides the backwards compatibility.

If the previous question can not be answer negatively, then I think we do need an alternative to automatic refine after each feature.

I think an alternative could be to define a property for all features, indicating whether prior to (or after, both have advantages and inconveniences) that feature a refinement operation should be performed or not. Such property could be defined to true by default on fillets/chamfers ("prior to" example) and to false in the rest of the operations.

I think I would need refine like 95% of the cases because of filleting/chamfering, then 5% because of broken coplanar faces/ collinear edges (transformations, pocketing sketch aligned with a previous edge,...).

I welcome discussion and more ideas regarding this issue. Neither have I started a predetermined implementation in my head, nor am I in a rush to have this finished for tomorrow, so we can shape a good idea before implementation.

It may help to remind ourselves about what is the problem with the lack of refinement. So far:
- Filleting/chamfering 95%
- broken faces/edges 5%

Please add to the list if you have identified any other problem. It sometimes help to focus on a better solution.

Is that the same as setting the Preferences->PartDesign->Automatically refne... options for everyone?

Same operation. Differs in when to apply it.

What I understand from the tracker is: If I use Openscad refine it is outside the PDN body, so I want a PDN refine. I never run into the problem of having an openscad object to deal with in PDN, so I might have misunderstood what Normand intended. Correct me if I am wrong.

[NormandC]

I still have the feeling the refine operation is something that should be done in each feature automatically.

It's what I've always wanted right from the start, years ago when RemoveSplitter() was added by tanderson69. Back then it was considered not mature enough. Then there were other concerns which I don't have a clear recollection.

Also a feature is bad imho, as it unnecessarily bloats the tree.

I also agree, but that's what we've had to live with so far. The real problem with the existing automatic refine settings is that they are not saved in the FreeCAD document. This can result in catastrophic breakage of a model if it is opened and edited while the settings are not the same as when the model was constructed. This is the only reason why we forum regulars resorted to discouraging its use. Many problems incurred because people would post their files but would not mention that they had enabled the auto-refine settings. It still happens from time to time.

If someone never shares their files and enables the auto-refine settings and never disables them again, I think it should not be a problem. On the other hand, if there are cases where the refine algorithm fails to produce a valid solid, this might be problematic if the setting cannot be turned off.

My current idea.is to have a hidden property in the body which enables feature refine, and set it by default to true. Than on migration this property would be set to whatever the current global variable says, this provides the backwards compatibility.

I like it, the refine algo would be run only once after the cumulative result of all the features, instead of after each feature. But why would it require to be hidden? I would prefer that it be visible and be changed by the end user if needed. Considering the geometric kernel we have to deal with , I bet there will be use cases where it is necessary.

And what about shapes made in Part or other workbenches than PartDesign? I know that some Arch shapes have a hidden auto-refine function.

What I understand from the tracker is: If I use Openscad refine it is outside the PDN body, so I want a PDN refine.

Exactly.

Of course my preference as stated would be never to have to manually add a refine feature. If we can get a reliable seamless auto-refine, great, we close this report - but if not, then a refine feature that stays under the body is very much needed IMO.

By the way, one thing that has not been mentioned here but is very important, is that the residual edges left by Boolean operations can be confusing to new end users. I've seen people puzzled by it on G+ and the chat channel. An auto-refine mechanism enabled by default would remove this confusion.

[ickby]

I will reply to you with a question, wouldn't an automatic refine operation create more problems with the toponaming issue, i.e., making it easier for the model to break?

IMHO no, it won't make topo naming more complicated. My reasoning behind this is that the refine operation is very well trackable (merging two into one) and hence each naming algorithm should easily handle it. Also I think removing the number of subshapes makes it way easier for the naming algorithm to handle e.g. booleans, where you have complex interactions between tool and result shapes. In Jan Rheinländers implementation he aktually did a refine before any naming operation, just to avoid the many drawbacks of small and unneeded shapes.

When answering take into account that a huge amount of the flexibility in the reordering of the features that PDN provides may be rendered useless if models start breaking into pieces when reordering features due to the refine option being enabled.

I even think reordering becomes more robust with refine, as there are less subshapes one needs to select for the same operation, and also I suppose the subshapes become more reliable in naming as the whole problem of splittet subshape/"which side has which name" issue is removed.

If the answer is no, then it should make an automatic refine. If it can not be answered negatively, then a selective refinement makes a lot of sense, so as to clearly isolate the weakest robustness points in a model.

I think it speaks for auto refine. But we should also ask deepsoic, as he is currently working on toponaming, he may have the best insight.

ping

The only thing that prevented me from introducing it directly​ in the part design features is backwards compatibility.

But for whatever we agree to be the best solution I think the moment to introduce it (by default) is now.

Yes, that is absolutely true! Just one thing to note: Currently PDN is designed to allow opening 0.16 part design features and also editing and recomputing those! We did make sure that noone losses it's designs. So this is something that mustbe ensured too. Thats why I too like the migration process as a tool for switching behaviour of old models.

I think an alternative could be to define a property for all features, indicating whether prior to (or after, both have advantages and inconveniences) that feature a refinement operation should be performed or not. Such property could be defined to true by default on fillets/chamfers ("prior to" example) and to false in the rest of the operations.

Yes, that would also be possible. Adding it to the body the features would query if they are within a body and then apply the body properties value, but this of course gives less control. However, I think that refine is the "natural" way of working for the features, this is what one normally expects, so if possible it should not be under user control but just be done.

It may help to remind ourselves about what is the problem with the lack of refinement. So far:
- Filleting/chamfering 95%
- broken faces/edges 5%

I'm all with normand here to add "user confusion". IMHO that is an important one

What I understand from the tracker is: If I use Openscad refine it is outside the PDN body, so I want a PDN refine.

Yes, you need a PDN one to have it inside the body, but it would work excactly the same as the openscad one.

[ickby]

I like it, the refine algo would be run only once after the cumulative result of all the features, instead of after each feature. But why would it require to be hidden? I would prefer that it be visible and be changed by the end user if needed. Considering the geometric kernel we have to deal with , I bet there will be use cases where it is necessary.

Ah interesting idea. My idea was to have a global setting in the body, and each feature than checks if it is in the body and if so, applies refine or not dependend on the bodies property. I would than hide it as changing the property would change the result shape of every feature, and with a >90% chance break the references in the model. So in my original idea it would only be to indicate if the model was migrated from 0.16PD and done there without refine.

I think applying the refine only one time after all features are done would introduce some problems with selection, as the user sees something else than what the features work with. Don't know if it possible to implement this correctly.

[DeepSOIC]

My opinion is that all PartDesign Add/Sub features should simply have a 'Refine' boolean property.

Having a 'Refine' property in Body is a bit of a problem, because that will create an implicit dependency of features on body, which will cause troubles with recomputes.

As for toponaming, don't worry. Jnxd is not that far yet, nothing will break.

[abdullah]

Thank you for you valuable input.

My opinion is that all PartDesign Add/Sub features should simply have a 'Refine' boolean property.

Why not transformation or dressup features?

Having a 'Refine' property in Body is a bit of a problem, because that will create an implicit dependency of features on body, which will cause troubles with recomputes.

This one I have to digest it.

As for toponaming, don't worry. Jnxd is not that far yet, nothing will break.

My concern was not breaking jnxd's early work, but putting an undue burden into jnxd's future work. Anyway, I think you are implicitly replying that it is not expected to cause problems.

Thanks again!!