#2683 Refinement transformation

[DeepSOIC]

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.

Since refinement is there anyway, you are only about to change the conditions when it has to be applied. So I see no change at all in toponaming perspective.

Adding a refiner feature will end up being extra work, but that doesn't mean we suddenly have to stop making new features altogether, right ?

BTW, the options are not contradicting, and everything-at-once approach can be used. I.e.
* separate refinement feature
* 'Refine' property in PartDesign AddSub's
* 'Refine' property in a body (may populate feature's 'Refine' values when changed, for example).

[abdullah]

Adding a refiner feature will end up being extra work, but that doesn't mean we suddenly have to stop making new features altogether, right ?

Right

BTW, the options are not contradicting, and everything-at-once approach can be used. I.e.

Probably yes.

* 'Refine' property in PartDesign AddSub's

Sorry to insist. Do you think a refine property should not be used for other features not being addsubs, like for example transformations or dressup?

[DeepSOIC]

I don't know if it's useful for dressups. I think it should rather be a pre-refinement, since refinement is commonly needed because fillets fail otherwise.

For transformations, I don't know. It makes some sense to have it there too, or it can simply follow the 'Refine' flag of the feature being transformed. Which leads to an interesting question - what to do if one is transforming Feature1+Feature2, and Feature1 has .Refine == True, and Feature2.Refine == False?

Which points to an issue that refinement doesn't work on actual features (i.e. if Refine == True for only last feature in the sequence, the end result is equivalent to having Refine == True for all other features too).

[chrisb]

I like the idea of integrating refinement in the Part Design Workbench without exra features. If I understand it right, the problem is, that there are cases where it is necessary to have the refinement switched off. Perhaps we should talk about these cases. Can someone please provide an example?

[abdullah]

Which points to an issue that refinement doesn't work on actual features (i.e. if Refine == True for only last feature in the sequence, the end result is equivalent to having Refine == True for all other features too).

Thanks for your insight.

While having refine == true for the last feature should be equivalent to having refine == true for the last, it may not be the case because of invalid shapes generated based on previous features if refine was false on them.

I put all you said into my input list

I like the idea of integrating refinement in the Part Design Workbench without exra features. If I understand it right, the problem is, that there are cases where it is necessary to have the refinement switched off. Perhaps we should talk about these cases. Can someone please provide an example?

I think it is a very pertinent observation. Because I can not answer the question myself, I have been trying to get community feedback. I think, I may be wrong, that because of the little use of the current "autorefine" option, we, as a community, may not have a clear answer to this question.

Currently, in order to better understand what we need myself, I am doing a half-complex design with autorefine=on. Let's see if I manage to draw some conclusions.

If anybody has more experience than I with this topic I very much welcome further information.

[triplus]

There isn't a straightforward answer to this question. Anything optional is problematic as different topology is returned based on the setting. If it is not optional you can't get topology from kernel as instead you get topology from kernel that goes through a set of FreeCAD algorithms that decide what is redundant topology and what is not. There are performance considerations? Refine algorithms can and likely will change in the future? Therefore the most flexible and transparent option likely is to have a refine feature that gets added in the tree if and when needed.

[chrisb]

I have attached a very simple model (still 0.16 because it has only half the size) with a standard situation where refinement is needed and I think it is not an option, it is needed to repair an erroneous model.
When I attach a sketch to a face and pad it reversed it is in the same plane as the original face and I can see no reason why it should divide the face into several pieces. The same on the backside: If I pad to the opposite face I expect a single face on that side too. I am open to arguments if I pad with an explicit length which happens to result in the same plane, but with "Pad To First/Last" it is not a feature, it is a bug.
That's why I asked for examples where it is useful to have these residues. If they cannot be found it is now a good opportunity to include automatic refinement in the 0.17 version and loose some backwards compatibility.

[triplus]

it is needed to repair an erroneous model

Part -> Check geometry doesn't find errors.

As for the rest:

https://forum.freecadweb.org/viewtopic. ... 10#p178042

[triplus]

Note that i am not against or for any suggestion. I just gave my feedback on how i currently use Refine functionality in (current) FreeCAD and gave some rationale on why i use this approach.

Whatever happens in this regards next i am sure i will manage. And seeing another command to be duplicated or/and some serious effort to be invested in only a sub set of FreeCAD geometry. I came to terms with that too. Sometimes you need to take a step back to take two forward.

[tanderson69]

IMHO:
If you guys want to go "all in" on refinement, I think you should switch to occt::ShapeUpgrade_UnifySameDomain. Then work upstream with occt to work the bugs out. That might be a long haul so maybe that should wait until after a release.

Another thing to keep in mind is: the better topo-naming gets the less problems there will be with turning the auto refine on and off.