Features and their Body

[jrheinlaender]

I moved this to a new thread.

Pad can retrieve the feature it has fuse to by the basis of the Sketch.

But I can think of lots of cases where I would want to create a Pocket without being able to sketch it on an existing face. E.g. cutting a keyway out of a shaft. If the sketch is not sketched onto a solid but onto a datum plane, then the Pad has no way of finding out what to fuse with except by looking at the Body it belongs to.

I think our different views on this subject stem from the fact that you use CATIA and I used Pro/Engineer. Modelling philosophies are very different... e.g. in Pro/E it is standard practice to have "single body" designs, where ALL features are strictly sequential, building upon one another. Sketching on faces is even considered bad modeling practice by many Pro/E people, because the model gets unstable when the faces are moved after editing the underlying feature.

IMHO FreeCAD should allow both philosophies. So inside a Body, features should be strictly sequential, with each feature building upon the preceding features. SketchBased features using sketches made on datum planes should be allowed. Multiple bodies and booleans between bodies then give us all the advantages of the CATIA philosophy on top of that (I hope I understood the CATIA philosophy correctly).

Using the Body history leads to all kind of problems. e.g. when you relocate the sketch on an other face...

Can you give a specific example?
It shouldn't be possible to relocate the sketch to a face that is created AFTER the Pad which consumes the sketch, of course. Pro/E doesn't allow you to do that.

Also if you have more then one Body in document and recalculate all bodies at once, there is no active Body.

The getBody() in Pad doesn't look for the "Active Body" (sorry my comment in the code was outdated). It looks at all Bodies in the Document and finds out which Body the Pad belongs to.

That allow also to load old projects (which has no Body) and use the PartDesign features without Body.

Your code already issues a warning to the user about that and tells him to use a conversion function (which I think needs to be implemented still). Actually I think automatic conversion can easily be done on loading a legacy document (we have a FileVersion property now )

[jriegel]

But I can think of lots of cases where I would want to create a Pocket without being able to sketch it on an existing face. E.g. cutting a keyway out of a shaft. If the sketch is not sketched onto a solid but onto a datum plane, then the Pad has no way of finding out what to fuse with except by looking at the Body it belongs to..

In that case I would rather add another Link property in Pocket to reference the feature to fuse in case the sketch has no Support.
Or we define a special sketch (or mode of the feature) which has the support set, but stays on the main axis it was placed.

I would not give up the locality of the features for such special cases...

I think our different views on this subject stem from the fact that you use CATIA and I used Pro/Engineer. Modelling philosophies are very different... e.g. in Pro/E it is standard practice to have "single body" designs, where ALL features are strictly sequential, building upon one another. Sketching on faces is even considered bad modeling practice by many Pro/E people, because the model gets unstable when the faces are moved after editing the underlying feature.

But editing the older features is the key benefit of parametric associative modeling! It sounds for me ProE has bad topological naming ( as we do at the moment ). And no plane referencing means falling back on CSG modeling. Using free planes in PartDesign sounds very rigid and counterintuitive to me. I wouldn't want prevent it, but its not my idea of the preferred way to model.

IMHO FreeCAD should allow both philosophies. So inside a Body, features should be strictly sequential, with each feature building upon the preceding features. SketchBased features using sketches made on datum planes should be allowed. Multiple bodies and booleans between bodies then give us all the advantages of the CATIA philosophy on top of that (I hope I understood the CATIA philosophy correctly).

Agree, but the feature itself don't need the Body for that. For the feature its input and output is only defined by the properties and not by pocking somewhere else. Logari is right, thats circular dependency - bad. Also its inefficient on lots of Bodies and long recalculations you do lots of reverse searching. And I still don't get the need...

Can you give a specific example?
It shouldn't be possible to relocate the sketch to a face that is created AFTER the Pad which consumes the sketch, of course. Pro/E doesn't allow you to do that.

Every parametric modeler allows that the one or other way. You need it if you have some kind of messed up history or your naming did something wrong. Its tedious, but that the only way you can repair really big designs. The other option is throw away and start new

Your code already issues a warning to the user about that and tells him to use a conversion function (which I think needs to be implemented still). Actually I think automatic conversion can easily be done on loading a legacy document (we have a FileVersion property now )

Yes, but I like to do always evolution instead of revolution. Otherwise you keep reimplementing the whole software again and again.

The only main difference is that you think the modeling history is in the Body, its not! The modeling history is in the feature linkage. The Body is more or less a group....

[logari81]

oh, this is a big discussion. I wished to have the time to present my arguments in form of code instead of words but unfortunately my free time is very limited atm.

I think that what Jan is trying to solve is indeed a weak point in the current FC design. I have seen new users, trying to:
- create a box named Box1
- draw Sketch1 on Face1 of Box1
- draw Sketch2 on Face2 of Box1
- create Pad1 using Sketch1
- try to use Sketch2 for creating a pocket, ... you get the point here. Pocket1 has Box1 as its base instead of Pad1
I was hopping that the Body feature would be clever enough to get the user out of this situation. Of course you can say, we can just teach users the right modeling practice but this is only one example. A similar problems occurs if you want to rollback your model and add a feature (e.g. a new pocket) somewhere in the middle of the modeling history. Then you have to remap all sketches from the previous feature to the newly introduced one.

There is a simple way of getting out of this, while keeping backwards compatibility and not affecting the overall design of FC:
1. add a Base property to the SketchBased class.
2. if this property is empty all sketch based features should behave as they do now, using the support of the sketch as their base.
3. modify all sketch based objects so that they will honor the Base property as their base shape if it is provided.
4. at Gui level use the Base property to create more flexible behaviors: e.g. in Command.cpp you create a new feature based on the selected Sketch and the Tip of the active body as its base. This also allows to use sketches that do not have a support
5. add checks and restrictions that may be necessary for promoting good modeling behavior and creating robust models only at Gui level

In general, I believe that we should put the modelling intelligence at Gui level, not App level like Jan's last try. Gui level is easier to change later without breaking too many things, like document file compatibility.

[jriegel]

Why so complicated... To solve that the Command has just to check if the Selected sketch bases on Tip of the active Body and can then show the user a dialog and pester him to do the right thing... IMO its not a good idea to base the sketch on one feature and fuse the resulting Pad/Pocket with an other. You disrupt a linear modeling history and create a diamond shaped graph. I would allow this only for sketches based on the base planes (no Support).

One way to ensure a good modeling history is to use the BodyViewProvider which has with ClaimChildren3D() control over its members, to show only tip. And if tip is a sketch, show the sketch and the support. So a older sketch gets hidden. To get it visible
again, the user has to rebase the sketch on a tip-face.

We should keep the history at the beginning lean/linear/local. Cleaning up model histories is a task which brings even very good wiled users over the edge...

Still not convinced....

[jrheinlaender]

if we want users coming from Pro/Engineer (and AD Inventor, and probably a number of other programs) to like FC, then I think we have to accept that they work along the following assumptions:

a) Only one body is possible in a part.
b) The feature tree is purely linear with features building on top of one another
c) It is good practice to create a "skeleton" of datum planes/axes/points at the beginning of your part and reference your sketches to these entities
d) Using sketches made on datum planes instead of on faces is not an exception, but extremely common usage

What you view as "the right thing" (basing sketches on faces) is simply NOT the right thing for Pro/E users...

This method works well, we have modeled parts with hundreds of features in Pro/E... This is not to say that Pro/E users will not be able to appreciate the advantages of having multiple bodies in a part. Often we had to work around the single-body limitation by using surfaces to cut out parts from the solid.

So, logari81's suggestion of a Base property that is by default set to the Tip seems to me a good compromise. We could even have a preference setting
a) For CATIA-like modelling, force all sketches (except the first) to have a support, and use the support as the Base property
b) for Pro/E-like modelling, allow sketches without support and use the Tip of the Body as the default Base property

Of course, you are the main developers but if you want Pro/E users to switch to FC then you need to adapt to their modeling practice instead of asking them to re-learn it

[NormandC]

I'm strongly against making FreeCAD geared toward users of a specific commercial package such as Pro|E rather than others. In any case, how many of them are there, compared to all other CAD software?

And it's not only because it's Pro|E. Over the past 3 years I've been telling quite a few newcomers here to not expect to find a SW-clone in FreeCAD (SW has the worst fanboys, they are like Apple fanatics - obviously not all SW users are, but when someone complains here that FreeCAD does not work like his software of choice, 99.9% of the time it's SW).

d) Using sketches made on datum planes instead of on faces is not an exception, but extremely common usage

What you view as "the right thing" (basing sketches on faces) is simply NOT the right thing for Pro/E users...

Well in my personal experience with mid-range parametric modelers such as SolidWorks and Solid Edge, it IS. What you call datum planes are used, yes, but not as much.

Of course, you are the main developers but if you want Pro/E users to switch to FC then you need to adapt to their modeling practice instead of asking them to re-learn it

Again, why should FreeCAD cater to Pro|E users more than to SolidWorks users, AD Inventor users, Solid Edge users?

A software that attempts to please everyone will please no one.

[kwahooo]

What you view as "the right thing" (basing sketches on faces) is simply NOT the right thing for Pro/E users...

Well in my personal experience with mid-range parametric modelers such as SolidWorks and Solid Edge, it IS. What you call datum planes are used, yes, but not as much.

Wait, in Pro/E you can use both datum planes and faces. You can choose the most convenient way. An face as pocket support is (in my practice) more intuitive.

[jrheinlaender]

I'm not arguing that FC should be a Pro/E look-a-like, any more than a CATIA look-a-like. All I want is for FC to be an option for as many users of other packages as possible. For that reason I pointed out the two modeling strategies that I know of and called them CATIA-like and Pro/E-like because I know no better. And IMHO users of one of those strategies will think twice about using FC if it ties them to the other strategy, because there is kind of an ideological war going on between those two

[logari81]

hi, if we reach a point were users will consider replacing their commercial CAD with FC, I expect these users to be open minded enough to also change their modeling practices, if we have a reasonable alternative. I don't think that mimicking modeling practices of commercial systems is a goal by itself. However the Body feature in PartDesign is crucial for providing flexibility to the user while keeping a robust data structure.

Coming back to my point. Reasons for adding a Base property to the SketchBased feature:
1. In order to accept the standard planes of the body feature as sketch planes for pad/pocket/etc.... Even in this case there has to be some way to define the base shape for such sketches without a solid support.
2. In order to use sketches defined in previous stages of the modeling history.
2a) To create features in a specific order (e.g. according to the manufacturing steps). Take as example the following:

one may want to do first the slope an then the keyhole. Currently we force the user to make the keyhole first and add slope afterwards. Especially for parts with draft, this may be problematic. Adding a draft to an already complex object makes it even more fragile within the geometry kernel.
2b) placing sketches as early as possible, can be used as a strategy for avoiding many of the problems observed due to the lack of topological naming. Faces at the beginning of the modeling history have less chances to lose their support due to some change. We may want to exploit this or not, but it is a fact.
3. We already have diamond like dependency graphs, e.g. in the multipattern feature. It is nice to have a completely linear graph but having some forks within the Body feature is not so bad.

[jmaustpc]

The thing I really hate about the current PartDesign workbench is that the work flow is lineal. Hence if I make something complicate and then decide I want to go back to an earlier step and do anything other than a trivial adjustment, it will ruin the model and quite possibly even crash FreeCAD.

So a lot of the time I just give up with Partdesign and do some operations as Booleans in Part.

It seems to me that lineal work flow. where you have to mount sketches on previously created faces. can only work well when you have a very clear idea of what you want to model and how to go about making a good model. That's probably OK for a manufacturing production environment but for a "mad inventor" who models something...then thinks ..I wonder what if we do this differently .... then you have to keep starting your model from scratch.


Jim