New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Part: Improve support for Links #6478
Conversation
You can re-open a closed PR, right? 😕 |
It kept showing 0 commits even though I added commits to it. Maybe after reopening they would have shown up? |
@realthunder , can you please review this PR? |
@mwganson Hi, I've gone through your changes. Here are my thoughts. First, Second, If you have removed Third, speaking of topo naming, although it is not relevant now, it would be better to use So my advice is that, if this PR is aiming for 0.20 release, then please make some changes to the usage of |
Thanks for the information. I will revise based on your feedback. |
I'm making some good progress, and I think it will be useful to be able to use App:Part objects similarly to using App::Link objects, but I have discovered something. If the App::Part container contains a sketch I can extrude it by selecting the Part and clicking Extrude toolbar icon. But if the sketch is later made invisible the Extrude object fails to recompute. Same is true for Check Geometry function. If I have for example a Cube and Cylinder in the App::Part container, select the container, and click the Check Geometry toolbar icon, it checks both the Cube and the Cylinder (and might show some self-intersections if they overlap), but if Cube is made invisible it does not get checked, same for Cylinder. The behavior seems to be if the Part::Features within the App::Part are made invisible they are not returned as part of the shape with: This can be demonstrated in python without need to build the PR. Create a App::Part container and put a Part::Cylinder into it. Select the Part and press Ctrl+Shift+P. In the python console: shp = obj.getLinkedObject().Shape This works if the Cylinder is visible, but fails with App.Part has not attribute 'Shape' if the Cylinder is made invisible. Is this the expected behavior or a bug? I can see how it could be useful to be able to control which shapes are in the compound that represents the App::Part container's shape by making them visible or invisible, but this will also be a source of confusion for many users. Visibility does not normally matter when it comes to the shape of an object. |
Converting to draft because I still have a few more dialogs to revise. Ones I have done so far: ruled surface, check geometry, extrude, thickness, offset2d, offset 3d, cross-sections, and revolution. |
I am using Part::TopoShape where possible, but my knowledge of OCC is not great, so where TopoDS_Shape is already being used it is trivial to convert from TopoShape to TopoDS_Shape. Part::TopoShape topoShape = Part::Feature::getTopoShape(docobj->getLinkedObject()); This will hopefully make it a bit easier if the TopoShape is needed later for topo naming mitigation since it will be there already. |
|
I have an very old pending PR that address this problem, by having the |
7b286df
to
204dbed
Compare
@realthunder I have discovered another anomaly when using the App::Part containers. Create a new App::Part. Add a sketch to it with a rectangle inside the sketch. Make the sketch visible. Select the App::Part, press Ctrl+Shift+P. In the python console: obj.Shape Extrude the sketch. Add the extrude to the App::Part. So now you have:
Now make Extrude invisible and Sketch visible. Select the App::Part, Ctrl+Shift+P. In the console: obj.Shape When selecting the App::Part, the sketch appears green in the 3d view, indicating it has been selected. It looks like what is happening is only the top level shapes are exported, and only then if they are visible. |
Some things I did not touch because we are in the feature freeze and already this is a relatively large PR. Among the untouched: Fillets, Chamfers, Project to face, Shape builder, Defeaturing. |
This is by design. The part container (actually |
This will be the last week I which feature PRs can be merged for FC 0.20. What is the status of this one? |
I think it's ready to go unless changes are required upon review. I have rebased locally. After I finish compiling and running the tests I will force push. |
@realthunder , is this PR ready to be merged in your option? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR is mostly okay. Just a few minor changes to make it more flexible.
Sorry, I did not get a notification of the new reviews. This is now tagged for 0.21 anyway. But I suppose it could be argued it is a bug fix and not a new feature. |
OK, putting it then on the 0.20 milestone list. |
@mwganson what is your time frame for this PR? Since it is in the 0.20 milestone, it should be merged soon, let's say it should be ready within a week? Would that be possible? |
I think it's ready now. Sooner the better so more people can build and test and report any issues. |
@realthunder , is the PR OK to be merged in your opinion? |
Looks fine to me. |
Great, so one PR less from the 0.20 milestone. |
@mwganson , don't forget to add documentation to the Wiki and to add it to our release notes: https://wiki.freecadweb.org/Release_notes_0.20 |
I accidentally closed the other PR for this, so I am creating this one. There haven't been any changes to the code except to resolve some conflicts with a recent commit (removing some includes).
Link to closed PR: #6353
Link to forum discussions:
https://forum.freecadweb.org/viewtopic.php?f=10&t=66159
https://forum.freecadweb.org/viewtopic.php?f=17&t=66449
It's a fairly big PR and the feature freeze is coming, so this probably will be for 0.21. But I think it would be nice to improve Links support in Part for 0.20, if possible.