Position of a feature in a list of features in a body, if attached to, or based on a face of an older feature

[Rabbit-sk]

Dear Realthunder,

When using Part Design workbench, a feature (a sketch, an additive or a subtractive feature) is not last in the list of features in a body, if it is attached to, or based on a face of a feature older than the last feature. In the case of sketch, this affects also position of a feature based on such sketch.

How to recreate issue:

1. Open FreeCAD Link Branch 2020.11.16
2. Create new document.
3. Switch to Part Design workbench.
4. Create new body and make it active.
5. Create some features in that body.
6. Unhide a feature older than last one.
7. Create a feature based on some face of feature from previous step.
8. New feature is located after feature from 6th step and later features are left hidden. If set to unhidden mannually, their faces could not be used for example for "pad up to face".

I am showing here some simple example, from which one could assume that this is not a problem and could be easily solved by different approach, but with some more complex bodies I sometimes used this workflow. Second reason for reporting this, is that this behaviour is not present in your older build from 2020/08/18, also not in older or current build of official brach (0.19.23074). Thus I suppose it might be a bug.

In comparison with your older build from 2020/08/18 and the current official pre-relase 0.19.23074 and older ones, in this procedure a new sketch, or another type of feature, is located at the bottom of a list of features in a body:

Regards

[Rabbit-sk]

I forgot to mention also that if a datum plane is created based on a face of an earlier feature, it is created at the bottom of list, but new sketch based on that datum plane is not placed at the bottom : I do not know if your commit f22fc4c is addressing also the problem described in the picture above, so I posted it.

[realthunder]

Can you please provide a screencast for the behavior. I tried it, but the sketch is also create at the bottom of the list. Anyway, the order of non-solid feature is not important. The order of solid feature with different tag is also not important. The only thing important is the order of solid features with the same tag.

With my new release today, you can easily reorder non-solid features by drag and drop. There is also the auto grouping capability. The only thing lacking now is that you can't easily reorder features with different tags.

[Rabbit-sk]

Screencast: 2020-11-26 14-18-18.zip

OS: Windows 10 (10.0) Word size of OS: 64-bit Word size of FreeCAD: 64-bit Version: 2020.11.16.22739 +2766 (Git) Build type: Release Branch: LinkStage3 Hash: 6730ad3b3bd841c2745ec98bf953c523dea86913 Python version: 3.6.8 Qt version: 5.12.1 Coin version: 4.0.0a OCC version: 7.3.0 Locale: Slovak/Slovakia (sk_SK)

[Rabbit-sk]

With today released build (without manual reorder of non-solid features by drag and drop), it is better. Although sketch still is not on the bottom of list (00:20), but pad feature based on it, is on the bottom of list: 2020-11-26 14-49-18.zip Thus the outcome is as it was used to be in older versions, I consider this behaviour fixed.

I tired also to reorder non-solid feature (in this case a sketch) by drag and drop, and it worked fine. Thank you. The reason I am mentioning above, the change of discussed behaviour without manual reordering, is that I was curious if manual action is needed to get the same outcome as in older versions. Thank you again for improving FreeCAD!

Regards

Sys info of the last screencast: OS: Windows 10 (10.0) Word size of OS: 64-bit Word size of FreeCAD: 64-bit Version: 2020.11.26.23076 +2836 (Git) Build type: Release Branch: LinkStage3 Hash: f22fc4cfe33a364a7d4bd0c5f89ecb11b9e192b1 Python version: 3.6.8 Qt version: 5.12.1 Coin version: 4.0.0a OCC version: 7.3.0 Locale: Slovak/Slovakia (sk_SK)

[realthunder]

I see. So which behavior do you prefer? Should the datum behave the same as sketch, or the other way round?

[realthunder]

I would think the sketch behavior is better. Imagine a very long history, and you just made visible a feature in the middle and create a datum or sketch. Adding the new object near the feature would be easier to find.

[Rabbit-sk]

Keeping related things closer together would make searching easier. But I would like to have new feature added at the bottom of list, because I prefer chronological order of features as they were created, reflecting the workflow.

If it is possible, there could be an option in preferences, if user want to add the new feature after feature which it is based on, or at the bottom of the list.

[Rabbit-sk]

I changed my mind. But I have also something else to write about this topic, I will write about it tomorow.

[Rabbit-sk]

I was thinking about this topic and exploring some new features in your branch. I admit that there are some new things that I'm discovering and getting used to, in comparison to the official branch, which I used before. As a former user of the official branch, I thought that the new way of order of new features based on older feature could lead to errors.

Adding the new object near the feature would be easier to find.

With solved topo naming problem and option to have MultiBodies, I see that your proposed solution is better. In case of MultiBody, it has sense to have features with the same tag together in order which is reflecting not the chronology of workflow, but rather the relation of features between them in sense of which feature is based on which feature.

[realthunder]

Well, I was asking about the position of non-solid new feature, like sketch and datum.

For solid feature, yes, with topo naming, it is easy to insert the feature after its base without disturbing to much with the whole history. But for sketch based features, it also make sense to draw a sketch based on early history, but create the new feature at the tail of the history. For better compatibility with the upstream, I reverted back to the original behavior. BTW, you can easily reorder the feature use drag and drop.

For non-sketch-based feature, such as fillet, chamfer, etc. the new feature will be inserted after its base. The current upstream behavior is incorrect, and you'll get the wrong shape.

[Rabbit-sk]

Well, I was asking about the position of non-solid new feature, like sketch and datum.

Oh, yes... I didn't notice it well. I put solid and non-solid features to "one group", because I was assuming they must behave the same way, now it is clear to me that it is not necessary. I will write answer to your qestion in next post.

But for sketch based features, it also make sense to draw a sketch based on early history, but create the new feature at the tail of the history.

It's true, I didn't think of that.

For better compatibility with the upstream, I reverted back to the original behavior.

Yes, backward compatibility is important and it is good decision. I also thought about it when deciding what type of behavior to prefer in my post, in my case from the user's perspective. Although I was still prefering original behavior, I decided to adapt my preferences to your proposed solution, because I do not track all changes and new features in your branch, and topo naming is making possible such behavior, so I thought you would better consider all the relationships.

BTW, you can easily reorder the feature use drag and drop.

I know, I have already tried that, but this is discussion about default behavior without manual intervention of user, so please do not get me wrong. (I'm not native speaker, my english is not the best.)

[Rabbit-sk]

I see. So which behavior do you prefer? Should the datum behave the same as sketch, or the other way round?

I would think the sketch behavior is better. Imagine a very long history, and you just made visible a feature in the middle and create a datum or sketch. Adding the new object near the feature would be easier to find.

I agree, non-solid features (like sketch, datum, ShapeBinder, SubShapeBinder...) should be added in history after particular feature on which they are based on.