#2683 Refinement transformation

[jmaustpc]

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.

A note for anyone reading this who does not already know......Tanderson69 was the developer who wrote Refine in FreeCAD.

[chrisb]

... and he did a great job, thanks!

[abdullah]

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.

Thanks!! This is indeed a good pointer, which links somehow with triplus' open question of what if algorithms change.

If algorithms change and the algorithm is "switched", there is a not negligible chance a model will break. Specially not negligible when considering the current toponaming status.

I must admit I like the idea of implementing this occt functionality. Whatever mechanism we provide, I think will have to clearly identify what is being used, so as to maintain backwards compatibility (not so much referring to 0.16 here, but 0.18 vs 0.17 and so on), so if several refinement algorithms will (now or eventually) be supported, we need to indicate which one is being used.

I continue with my design. So far I am positively surprised of the result...

[ickby]

The occ algorithm may be a good choice, however, one needs to know that it was vastly improved lately. I think it is basically unusable before occ7.0 and even after 7.1 on recent master some essential improvements have been done. This needs to be considered when used.

[NormandC]

Hello,

Am I to understand there has been no progress on this?

Here's a recent topic, with the "Links go out of the allowed scope" restriction, the behavior has changed.

https://forum.freecadweb.org/viewtopic.php?f=3&t=26375

I don't expect any long term solution to be worked on before release of 0.17, but I am now wondering if, in the meanwhile, instead of making a new exclusive PD refine feature, it would be possible to make the OpenSCAD one compatible with PD Bodies.

Case in point: shaise, the developer of the Sheet Metal workbench add-on, has made it compatible with Bodies. Features are added under the body, in a lineal order.




So why couldn't it be possible to adapt the OpenSCAD Refine Shape feature? Or could it cause backward compatibility issues in the long run?

[wmayer]

Here's a recent topic, with the "Links go out of the allowed scope" restriction, the behavior has changed.

A temporary solution would be to disable this restriction and instead print a warning or error to the output window. And if the message includes the feature type we can fix the features step by step.

I don't expect any long term solution to be worked on before release of 0.17, but I am now wondering if, in the meanwhile, instead of making a new exclusive PD refine feature, it would be possible to make the OpenSCAD one compatible with PD Bodies.

An alternative would be to add a boolean property to the features that use the refinement. This way it doesn't matter if a user where the option is off gets a project from another where it's on or vice versa.

[chrisb]

An alternative would be to add a boolean property to the features that use the refinement. This way it doesn't matter if a user where the option is off gets a project from another where it's on or vice versa.

It would be great to have this property in the model. I used to have the auto refinement on but had to refrain from it to be able to exchange files without continuous issues.

[abdullah]

Am I to understand there has been no progress on this?

Unfortunately I have had no time to work on this. There is a ticket on my name, so probably I will work on it during the v0.18 development cycle.

[triplus]

A temporary solution would be to disable this restriction and instead print a warning or error to the output window. And if the message includes the feature type we can fix the features step by step.

We had tons of discussion about this area in FreeCAD 0.17 development cycle. And all that didn't get us far compared to the original proposal/objective (for having such restriction). Not that long ago @ickby expressed his views as having such restriction should help in the Assembly effort (things would be less complex). Now i do imagine FreeCAD 0.18 will be all about Assembly effort. Therefore would this temporarily solution introduce issues @ickby wanted to avoid? If yes i don't see much point in enabling it for FreeCAD 0.17 as some sort of temporary hack. If not too bad it didn't happen earlier in the FreeCAD 0.17 development cycle. As i do imagine one of the biggest complaints from end users (not being able to use favorite commands in PDN workflow in some straightforward way) could be (at least partially) avoided.

[NormandC]

Sorry for not replying sooner,

I don't expect any long term solution to be worked on before release of 0.17, but I am now wondering if, in the meanwhile, instead of making a new exclusive PD refine feature, it would be possible to make the OpenSCAD one compatible with PD Bodies.

An alternative would be to add a boolean property to the features that use the refinement. This way it doesn't matter if a user where the option is off gets a project from another where it's on or vice versa.

But I doubt this could be done before the 0.17 release, right? As this would need to be implemented in a lot of PD features. Besides, there were different approaches discussed here, and I don't think there was consensus. IMO, the long term solution is to remove this refinement from the hands of the end user and to deal with it under the hood.

I was just asking for a quick hack for the 0.17 release, so the current work flow in 0.16 could be kept, that is adding an OpenSCAD Refine Shape feature directly on a PartDesign feature.