Status PartDesign and further development

About the development of the Part Design module/workbench. PLEASE DO NOT POST HELP REQUESTS HERE!
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Status PartDesign and further development

Post by jriegel »

Analogous to the status post I made for the Assembly I will here do it for the PartDesign module.

IMO the most important single change will be the Body feature. Its at the moment in the Assembly branch and will change the way to work with prismatic history-based modeling. The Body feature will also greatly simplify some of the problems we face in PartDesign. Since it gives the features in PartDesign always a defined frame, it makes it easier for commands to refer to the right position or just the right features earlier in the modeling-history.

Unfortunately the Body object will impact most of the commands in PartDesign and a lot dialogs. There fore lots is still to do:

1.)PartDesign Commands. All PartDesign commands now have to honer the Body object. Mean they have to retrieve the active body object and append newly created PartDesign features to it. Also the Body have a Tip link which signal always the top of the modeling history. The commands have to adjust that also.
I did it already for the Pad feature, the rest is to be done...

2.) Visual switching. With the ClaimChildren3D of the ViewProvider its now possible to assemble all the visuals of the PartDesign-features under the Body ViewProvider and give it the control which feature is visible. Normally one want to be the tip of the modeling-history to be visible. But in some cases the, e.g. if you want to change the selection of an feature earlier in the history, where other feature have to be visible and not tip. That is a logic which have to be implemented in the Body ViewProvider.

3.) Selection clearance. If a Body is not in work (active) you normally see the visual of the tip of the modeling tree. If you select that feature for e.g. Assembly, CAM or FEM you most likely want to create a link to the Body not the actual PartDesign feature. Linking the Body object will prevent loosing the link on grave changes of the modeling history (e.g. deleting the last fillet in the history). There fore the Body ViewProvider have to take care to give the right selection if it is not active/in-work.

4.) Body Boolean. Since the Body objects is always the solid end-result of a modeling-history, it makes sense to allow Boolean operations in PartDesign only with Bodies as operand. That would lead to a new class of boolean features for PartDesign which get inserted in a modeling history with an other body as operand. So it will also be a Substracive (Cut) or Additive (Fuse) inherited, which open it to the pattern features.
Stop whining - start coding!
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Status PartDesign and further development

Post by jrheinlaender »

I can work on 1) as soon as the double-precision work is finished
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Status PartDesign and further development

Post by jrheinlaender »

Hello Jürgen,

I integrated the PartDesign::Pad into the body workflow. Maybe you could have a look before I do this for all PartDesign features?

https://github.com/jrheinlaender/FreeCA ... partdesign
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Status PartDesign and further development

Post by jriegel »

Hi jan,
great you find time.

Some comments:
I would not change the Pad feature the way you did it. Features should be atomic. Pad can retrieve the feature it has fuse to by the basis of the Sketch. Using the Body history leads to all kind of problems. e.g. when you relocate the sketch on an other face...
Also if you have more then one Body in document and recalculate all bodies at once, there is no active Body. E.g. when you in Assembly workbench the Active Body is empty.
So the features don't need to know about the Body! They are fully able to calculate itself by its links and properties (atomic/local). That allow also to load old projects (which has no Body) and use the PartDesign features without Body.

The helper functions in Body are good and such things will be needed!

The main changes will be in the Commands and Dialogs. They CAN use the information in the Body to build up the linking better/easier! For example on Pad. If no Sketch is selected, the command can search for a Sketch at tip of the active body and use this.
Stop whining - start coding!
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Status PartDesign and further development

Post by jriegel »

One thing we should also take a look at is the origin of the history tree. At the moment the features chain starts with the first feature (often a Sketch) and get there fore positioned from there. Catia e.g. create three base planes outside the Body to base the construction on. I did the same at the moment in Assembly "Add new Part".
We would need that to on PartDesign. I toyed with the idea to also add the base planes to the Body, but I'm not sure this is a good idea... Especially when it comes to using multiple Bodies with boolean features....
Stop whining - start coding!
logari81
Posts: 658
Joined: Mon Jun 14, 2010 6:00 pm

Re: Status PartDesign and further development

Post by logari81 »

jriegel wrote:I toyed with the idea to also add the base planes to the Body, but I'm not sure this is a good idea...
no it is not. I had the same idea but in your implementation the Body feature is a child of all features contained in Model. This means that the features will not be able to use these planes as references (e.g. as sketch plane), otherwise a cyclic dependency is created.

The other idea to put the planes as the first features contained in the model list will work better, I think. We can also allow users to add new planes in the middle of the model list but in this case, the "Tip" cannot point to these planes. The Tip has to point to the last solid.

@Jan, please don't mix whitespace changes in your commits. If you want to fix whitespace issues please do it with an separate commit.
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Status PartDesign and further development

Post by jriegel »

Hi Logri,
great you tune in since you have done quit a lot work in PartDesign would be good you keep also an Eye on it!
logari81 wrote: The other idea to put the planes as the first features contained in the model list will work better, I think. We can also allow users to add new planes in the middle of the model list but in this case, the "Tip" cannot point to these planes. The Tip has to point to the last solid.
Your quit right, we can not use the Body itself! The question is the base planes under the Body (first entries in the history) or somewhere outside (like in Catia) to be used by multiple bodies which get eventually later put together by booleans....

I wouldn't allow "free" planes beside the base planes. I never needed on with all my projects under e.g. Catia. Its a bit cross to the PartDesign philosophy, its more a paradigm in Free Form Design.
But if we need one, I would implement a PartDesign feature Plane which always have to be a offset (or angel) to a solid face or base plane.

But I learned one thing - there are more then one way to model stuff :)
Stop whining - start coding!
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Status PartDesign and further development

Post by jrheinlaender »

@Jan, please don't mix whitespace changes in your commits. If you want to fix whitespace issues please do it with an separate commit.
I would love to get rid of these whitespace changes, but Qt Creator puts these in. I think it happens when I open a file saved on a Windows machine. I get the question "The file cannot be displayed in the encoding "UTF-8". It cannot be edited". Then I am forced to select a new encoding (I choose ISO-8859-1)" and when I commit all sorts of random whitespace changes show up which I never created.

I found out that I can ignore whitespace changes with git diff -b but I couldn't find out how to omit them from commits.

Any ideas would be highly appreciated!!!
jrheinlaender
Posts: 554
Joined: Sat Apr 07, 2012 2:42 am

Re: Status PartDesign and further development

Post by jrheinlaender »

The question is the base planes under the Body (first entries in the history) or somewhere outside (like in Catia) to be used by multiple bodies which get eventually later put together by booleans....
I agree to put them outside, as the first feature in the tree (AD Inventor even has a special group called "Origin" for that purpose)
I wouldn't allow "free" planes beside the base planes. I never needed on with all my projects under e.g. Catia.
But they are absolutely essential to e.g. Pro/E users. So if we want FC to be used by users coming from there, we MUST allow free planes, axes, and points. Pro/E even allows to define multiple coordinate systems!
But if we need one, I would implement a PartDesign feature Plane which always have to be a offset (or angel) to a solid face or base plane.
I can agree with that.
But I learned one thing - there are more then one way to model stuff
And I wish I had looked more over the shoulder of my CATIA colleagues because there seems to be a big divide in modeling philosophy here!
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Status PartDesign and further development

Post by jmaustpc »

Hi Jan
I found that problem too Jan, I don't have a real answer, I just stopped using QT Creator for editing, I just edit the files in Kate. Kate doesn't seem to complain about the encoding. I use QT creator only for searching the text with the files within a directory. E.G. search "ViewProviderBox" within /freecad/src/ to find everywhere that it is listed so that I don't miss something. There are probably better tools to do that but it works and I have got used to it. I also sometime use it to read the code it complains about, but not to write it.

I imagine you may well need to use better tools than I as your coding is far more complicated that the few things I have worked on.

Jim
Post Reply