Hey Istvan,
Glad to see you chime in on this. There was a lot of discussion over the past few days haha. Some you’ve addressed, but think a lot of it may have been missed.
No, the question is why a Move/Rotate/Align operation applied to a body will not ALSO apply to the sketches that defined the body? It will not change the body, just re-position them WITH the body.
After all currently you can select all the sketches that define the body, and collectively, they maintain their spatial relationships to each other. This means you can Move/Rotate/Align them under the current system and the body follows along with it. This doesn’t change history order or any of the operations that come after. You can even change those sketch(es) independently in this new location to alter the body.
My question is, why CAN’T that also work in the other direction when re-positioning the body so that visually and cognitively connected when you adjust those sketches the moved body and NOT have them separated like the current paradigm? ie. currently you CAN do as I described above with selecting just the sketches but CANNOT select sketches and bodies at the same time and Move/Rotate them. This was never the case before. Why can’t it be done now? Especially now that there are these dependencies in place and the sketches are no longer throw-away, they’re integral to making HBPM work, it makes sense to have them linked and together fully, not just in a partial and potentially very disconnected (visual) manner.
Even if you were to say “we can’t/won’t implement this because you can just do as you described by selecting the sketches anyways”… that would require labeling every sketch and creating folders to organize everything manually, very time consuming and tedious to ask users to do. See below where we discussed potential solutions to this issue…
When a sketch is used for multiple bodies, a copy would be made when that body moves. That new sketch, just like other copies even in the current format, get’s it’s own unique sketch plane and name. That can now move with the body independently of the other sketch. Having all the items within the Items list in a tree would mean that selecting them and moving them would be similar to prior versions. If this is implemented with how @Justin074 and I were discussing here navigating these could be easier as well.
This is not what we’re discussing and is no different to how things are now. If you’re speaking to the history order and adding in steps, I discussed that further up the thread^^^.
This concern is also negated if the unique sketch (as described above) moves with the body. It’s the same as it was before moving it. The only thing that will have changed would be the spatial coordinates of the sketch plane(s) that make up that body at the very beginning of the history. All the other features would still maintain their place in the history order. This won’t add steps. It just applies new values to the basis for the first steps, since after all the original sketch plane needs to be defined. It’s just asking to change the values of that definition.
I believe you missed discussion where the movement of the sketch(es) would only apply to the original body created from them. Copies would just be copies of the body. That’s how the history works now. You can have copies of bodies and moving one doesn’t necessarily change/move the others UNLESS you specifically change the history order. (thanks for the tip @Shaun !!!)
If you’re talking about feature selection order, ie. which edges are selected to make a feature like a filet/chamfer, yes you would have to select only edges associated with that particular body, not multiple bodies. That way the Move/Rotate doesn’t affect other bodies. Doesn’t seem like such a huge ask from users when they’re being told to re-learn how to do things to begin with.
If you’re talking about features like replace face, so that faces from one body to another are now coincident, that never stopped the ability to Move/Rotate a body independently previously. I don’t see why it would now unless HBPM is so dependent on order of operations that it always has the potential to make itself a total mess or a ton of errors with such a basic function like Move/Rotate/Align.
I disagree, I believe that implementing this in tandem with the implementation of adding the feature tree/dependencies/links (whatever you choose to call them) in the items menu would actually streamline the process and make it easier to navigate. Especially for older users currently upset about the changes. The History menu itself, as many others have pointed out, is rarely used unless specifically necessary. But as we’re brainstorming these ideas this also wouldn’t affect the history if the changes can be implemented as described.
It would create less problems, be more visually connected, and act more as a natural extension of what Shapr was and how it functioned. Potentially bringing more people on board with the HBPM way of doing things since that’s now the standard we all must follow.