I have a completely different mental image of how history should work, which probably explains why I’m a lot more comfortable with the current implementation. I think of each sketch as an operation that occurred at a point in time – perhaps after some operations and definitely before others. As such, it is intended only to make adjustments or changes that would have been appropriate or even possible at that (and only that) particular step in the entire sequence of operations.
In other words, the only purpose is to be available if I later decide to experiment or perhaps correct a mistake. It’s position in the sequence cannot be arbitrarily moved because many or even all subsequent operations directly depend upon the state of the design as dictated by that sketch and its constraints – at that point in the sequence of operations.
In your example, it is not feasible to literally move the original sketch to a different point in 3D space and try to make changes to it. If you were to try, the results would be exactly the same as if you had deleted the sketch in the first place – any extrusions, cutouts, etc. would no longer be there.
Remember, each step/operation occurs at a point in time – in sequence after some steps and before others. You can’t make changes to the sketch at two different points in time and expect Shapr3D to know which is which. Your only option is to make a copy of the earlier sketch step and modify it if you need to make changes at a different point in time in the sequence of operations.
I agree that it would be helpful if it were easier to find the sketch associated to a particular body, but you have to keep in mind what the ability to modify a sketch can and cannot accomplish. They can appear magical, but they are not magic. You can only make changes that would have been possible at that particular point in time. And even then, some changes may break subsequent steps.
My background is in programming and I think of this as a series of programming steps or functions (which is pretty close to the truth). Every single step depends on the results of the previous step. You can change or adjust the inputs (parameters) to a program step, but every following step might change a little or a lot. And if you remove a step, bad things will probably happen.
I understand the desire to “keep sketches and bodies in sync” but that is not really practical, especially since the end state of most bodies are usually a combination of sketches and direct modeling manipulation. The only practical solution IMHO is to rely on the drawings feature.
And I think this is where the fundamental difference will come into play. I will say that you and @TheBum having these backgrounds in programming/software tend to think, or are at least expressing these opinions, in a very particular sense and for you this process is easy to adapt to.
But, no offense intended, your entire description of the process reads more like a complex math equation than a creative design process haha. I’m very much on the opposite end of the spectrum (formal Industrial Design background, but a tattoo artist for 15yrs so). I have no clue when it comes to programming, the language is not even foreign to me, it’s alien. Writing macros for my 3d printer takes me 50 tries and even then I’ll give up more often than not. It’s just not how my brain works, and it’s definitely not how I design. This seems like a left brain, right brain conundrum.
Correct me if I’m wrong, but this entire update has been predicated on the ability to modify sketches to change bodies and the supposedly infinite benefits that offers. If there are such huge limitations placed on even moving or rotating and having sketches/bodies/relations kept in place with each other, I’m failing to see those benefits now more than before.
I guess i’m really failing to understand why exactly the sketch can’t move? Who determines that? Is it just an overly complex programming issue within the program that can’t be solved? Or just one that would be too difficult/time intensive/costly to solve?
If it can’t be solved, then that kind of defeats the purpose of having the dependencies of this brand of parametric to begin with. Modeling everything perfectly in place from the get go, to potentially make any use of the parametric features later, is more of a huge limitation than a benefit. If, as you said, my example won’t fly, then that means I’d need to perfectly place a plane in order to sketch the part exactly where it needs to be to have everything visually sync up.
This is starting to sound more and more like it removes creativity from the process to design and adapt on the fly and becomes more of an engineering program with strict limits that must be adhered to to make benefit of like other programs I’ve used and chose not to continue with.
If this is all the case then I sincerely regret updating and pray the new release to collapse history comes sooner rather than later.
The issues I’m seeing here is that direct modelling had you making something one way and then parametric modelling has a ‘trust me bro, this is better’ way of doing things. And you really have to trust that bro to believe it.
I’m seeing huge benefits in engineering style models that I’ve created in the last couple of days. I’m forcing myself to use constraints and iterations are a breeze. But, it’s a different style and much less free flowing.
If you want free flowing, then the option is still there but I think in this case that parametric can either be a burden or a godsend depending on your model. I’ve said it a few times but I’ve been thankful when direct modelling that I can change an extrusion to a New Body very easily but using parametric on projects that have multiple of the same parts, especially when they’re in varying positions/locations, you might as well just ignore parametric altogether.
I think the curse of direct modelling was that it allows us new to the game (or from different modelling backgrounds to what parametric is really aimed at) to completely ignore sketches and constraints and go with the flow. I am seeing the benefit of using constraints now but it’s certainly a different workflow and I have to think ahead. Is it better going forward? I really think it is. But looking back and working on old models, I’m completely ignoring it.
Yes, and i know that changing the order will change the final look. However… If you selected all the layers in photoshop and simply move them to a different point on the canvas everything still functions the same way as before. Why is that different here?
Perhaps it’s too simplistic, but if that’s the case I shouldn’t need to be a programmer to understand how to use a product fully. Especially since this wasn’t the case until HBPM came into play. Prior you could easily select everything in a folder and move it and rotate it seamlessly, without the connections. Now with them, that’s not possible? It just doesn’t make any sense to me.
No. If you change the sequence of the layers you’ll get different results. The order of the layers matter. Just like in 3D modeling, if you have two boolean operations, their order matters. In the example below, I have the exact same 3 bodies (two cubes and a cylinder), but the order in which I created them and the order of the boolean operations is different. Same operations, same geometry, different order.
Yes I understand, what I was getting at, is in photoshop, if you have multiple layers to create an image you can select all those layers and move them around in unison NOT altering the image but changing it’s location.
For example, you’ve compiled an outdoor image and put a tent into it. You’ve then added layers to change lighting, shadows, color, etc on the tent. You can still select all the layers associated with the tent and move it within the full image of the the outdoor scene. They will not change the order or look of the tent but everything will follow it to it’s new location within the canvas.
This not only maintains the final look, but also the connections that were applied to make the tent look that way, thus maintaining the visual/cognitive connection since they are all now in the same location. Does this make it clearer?
LOL, it’s not a programming issue – it’s a Life issue. I promise I’m not being flippant, but you think the issue is a lot more complicated than it really is. My hope is that once you understand the elegant simplicity, you’ll be less annoyed by any inconveniences and maybe even see some benefits.
At the most basic level, all CAD and drawing programs (and life itself for that matter) work exactly the same. You perform a series of actions, one after another, applied to the current drawing (or Universe if we’re talking about life in general, lol) – in a specific sequence to accomplish a desired goal.
For example, draw a shape, extrude a body from that shape, make a cutout, fillet some edges. Often, the order is important – you can’t make a cutout from a body that doesn’t exist yet, but you might be able to fillet the edges of the main body if you don’t need to change the cutout.
Shapr3D has always had (as well as many other programs of any type) a limited form of history with the undo function. If you needed to make a change, you could always undo back to that step and make your change. But, you then you had to manually redo every “erased” step to get back to the current state of your design.
In some circumstances, this could be a lot of extra work. Say, for example, you make a “starter” body shape, then make several copies and proceed to make different changes to each copy. If you later discover that it would be better if each (now different) shape needed to be just a little bit larger, with the old undo only history command, this could be a real pain. With the new capability, it can be as simple as finding the “starter” body shape (or sketch), making the adjustment and watching the change propagate to all of the copies.
It is important to realize what is really going on here. Shapr3D has always had to do basically the same thing under the covers. Every time you do anything, Shapr has to understand and remember where every drawing element is located in 3D space and how it is related to every other element. Every time you do anything at all (even just changing the view), Shapr must recalculate every relationship and decide whether each element is affected by the operation – if it must be modified or moved, or if it is even visible in the current view.
Shapr has always “remembered” the list of operations to allow the undo function to “step backward in time”. It is fairly easy to do this – whatever under the covers mathematical operations were required to move design elements to their new locations can be reversed to restore the drawing to its prior state. And you can redo the operations as well if you back up too far, unless you make a change to the earlier stage of the design – then all bets are off (this still works the same way).
However, with the new version, we are now allowed to at least try to redo the operations even if some changes were made to an earlier stage of the design. This is possible because from Shapr’s point of view (at least before it does it’s mathematical magic), we give a command by selecting something (one or more, points, lines, faces, or bodies) and doing some action with those things. As long as Shapr can still identify the something, it will be able to redo the action(s) requested.
The current state of your design is nothing more or less than the end result of your commands executed in the order you requested them. As such, changing the order can be very useful or disastrous. Regarding sketches in particular, they don’t necessarily have to be considered part of the command history. For example, with the old way, they were basically one-and-done. Shapr just had to keep track of the vertices of any extruded bodies to know how to apply any future commands.
But sketches can provide so much more power and versatility if you can make them “live” and part of the history chain. It’s true that Shapr must spend a few more compute cycles to “consult” each sketch to see if anything has moved before a new command is applied, but that effect should be minimal compared to all of the other far more complicated calculations which are constantly happening. But it does mean that sketches must be always “available” in their original location. If they aren’t, then everything that was derived from that sketch will disappear.
I think the biggest misconception (and fear) is that history must now be used for everything. Which is absolutely not true. There are some situations where it can provide a huge advantage (such as the copies of a body example above). But there are also situations where there is none. Which is fine.
I apologize for this long explanation, but I’ve tried to give an explanation of how to take best advantage of history in situations where it might be useful. Like any tool, it is not appropriate for all situations, but also, like any tool, it is most useful if you understand how to use it efficiently.
Regarding your specific example:
I don’t understand how the new way is more difficult than whatever you did in the past. If you reused the old sketch, then you know where to find it. If is most convenient to make an adjustment to the sketch, then do that and it will show up on the body wherever it is located. Or, if you need to add new features, then make a new sketch on the face of the object where it is now.
As I said, sometimes history can be useful, but sometimes not. Just use it where it make sense. Even in my example of the copies of bodies, it might be easiest (and smartest) to select the current bodies and scale them if that can meet your needs.
This is just one additional tool in the toolbox, and anyone can mostly continue to use their old tools in whatever way works best for them – especially once the “collapse history” is implemented.
I think your concerns are fair and legitimate, but, as I’ve mentioned to some other people, I don’t think the history feature was ever intended to be the only or even the best solution to ALL problems. Take advantage of the new capabilities when they are useful, and ignore them when they aren’t.
Istvan has always maintained that history would only be added to Shapr if it could be done at minimal inconvenience to current users. Personally, I think they’ve succeeded admirably, but obviously a lot of people disagree and would rather not break any eggs to make the omelette – no matter how delicious it is claimed to be.
But there is one very specific type of problem that almost everyone encounters on occasion. Which is:
I wish I had done something a little bit different in the beginning
because now it is going to be a lot more work to fix -- if it is even
possible at all without completely starting over.
The above situation happens to all of us at one time or another, and having the history steps available to fix your mistakes can be a game changer – even if you never do anything else with it. Which is why I recommend that people don’t go crazy with the upcoming “history collapse” feature. Once the bugs are squashed and code is optimized, I really doubt there will be much, if any, performance impact.
Steve, I appreciate your time and thoughtful response. I do believe we have many points of agreement, but we also just have different brain wiring when it comes to this. I’m not saying that HBPM doesn’t have it’s benefits, on the contrary I’ve said repeatedly it does/will. I’ve simply pointed a few basic things…
1: A lot of the benefit of HBPM means very little to legacy models no matter the stage they’re in without completely re-doing the work already put in.
2: That there have been obvious defects with the rollout so far.
3: That certain decisions on the new process don’t make much sense to the more artistic people out there.
4: A lot of HBPM will be used only by certain users, or for certain purposes. ie. engineering based modeling vs a more organic process.
5: That the drastic change from direct to parametric has caused a lot of stress on certain users. Not out of fear or a willingness to learn, but about the immediate disruption to the workflow that they became accustom to over the years. The line that it’s not that different should have been left behind the moment the complaints grew and shapr announced collapse history.
6: More recently in this thread as well as another, trying to explain how, or at least exploring options, to make the organization of the new system easier to understand and navigate.
7: Even more recently in this thread as well as others, trying to explain (especially for visual learners) that the disconnect of having dependencies, but only partially having them is actually a major issue.
This is the crux of the issue and lack of understanding on the matter. In the past it didn’t matter at all. As you’ve pointed out previously sketches were throwaway, on that we agree. The issue is, now it does. Prior, if you wanted to move a sketch and a body at once it was a simple operation, now it’s not possible at all. The simple fact is, I believe, if there are bodies that are based on sketches and dependencies involved. To keep those in place, they should follow that body (or at the very least the first body created from them not copies). I’m not asking to re-order the entire history of that part. I’m simply asking to have them coincidental.
Changing a sketch that’s on a completely different plane, angle, rotation, to the visual object is a HUGE disconnect between the two, making me much less likely to actually make any benefit from HBPM. If they’re right there, where they should be, at the very least visually I can make those adjustments and have them be seen.
Obviously this is not a big deal to certain users, but most definitely to others. I’m simply trying to explain how by implementing that it might actually bring more people onto the HBPM train vs placating them with a collapse history function. (to be fair i’ll probably take advantage of this especially for legacy projects which I have numerous with hundreds of hours into).
Currently the system is asking the user to have it half way and be happy about it. If we’re gonna have these dependencies, then those items should be grouped and follow each other. If we’re gonna go this route, lets whole ass it, not half ass it haha
Take a look at my comments to @Shaun directly above. I don’t think anyone is claiming that history is the best solution for every problem. Obviously, a lot of workflows won’t get much benefit from the new features, but it is potentially a lifesaver if you ever encounter a situation in which a mistake early in the design process could be corrected with minimal difficulty if the history steps are available.
But that only works if Shapr can literally “replay” (either forward or backwards) your own actions to get to the correct stage where the change needs to be made. Unfortunately, that only works if every object (including sketches) maintains the same basic relationship to each other object. Think of it like you are asking another person to recreate your design, but you can only give that person the exact same information you gave Shapr in the first place. You have some flexibility to make a change because a lot of the commands you made to begin with are something like “move this particular body until it aligns with that body”. But if one of those bodies (or sketches) is missing, then the person will be unable to perform the command.
Regarding your particular concern, I can see how it would be confusing and more difficult to make changes when the original sketch and the body are now in two different spatial orientations, but moving the original sketch is not the best way to solve that issue because it breaks the history chain. At first glance, it would seem like Shapr could automatically make a copy of the sketch and move it with the body, but that is not a good solution either because then every move would generate a new sketch (most of which would never be needed or used) and the number of sketches would grow uncontrollably. Probably the best way is to recreate the sketch by projecting from the body in its current location when you need one and just go from there.
Anything created with the earlier version of Shapr won’t have any history steps except for any new additions after importing into the new version.
So my question would then be, IF this isn’t a net benefit to a lot of workflows, only a potential benefit in the worst case, just in case scenario, or only beneficial for (at least how I know and perceive most parametric modeling) making items easily adjusted to say a particular set of parameters (like fitting X number of organizers in a specific drawer space type of scenario)… Why the implement it with only the option to use it or lose it?
I’m asking it to maintain those relationships even more As it stands now, at least visually, and in your hypothetical. That person re-creating the body would now have to consult a sketch that is nowhere near the body making it less likely for them to succeed. Again, I understand what you’re saying, but I just think it’s a fundamental difference between the way certain minds work. I’m trying to give feedback to make it easy for visual learners, and i’d bet a large majority of at least non corporate users are, to help implement the HBPM into their workflow easier.
How though? Every other move, rotate, align is recorded in history now. I fail to see how this would break the history chain? Rather logically, at least to me, it would simply add a step to the history for the sketch that matches with the corresponding step with the body that’s currently recorded.
Think of Shapr3D as a visual learner!! LOL It must SEE each step of the design in the correct order (and just as important, correct spatial location) to be able to re-apply each successive command to be able to correctly create the new, adjusted design.
And yes, every operation IS recorded --WHEN it happens. This works like a video camera. You can film yourself executing each command from the beginning of a design. Rewind to where you want to make a change, while also using the undo command to match the exact number of commands you rewound. Now you could let anyone else sit down, follow each of your video commands, and they would end up with exactly the same drawing.
But now, since the video is all caught up, turn the camera back on, go ahead and move some sketch to match the current location of a body that has been moved. And then do the same thing. Rewind the video tape to a point before the last time you used the sketch and make sure to undo the exact same number of steps. Ask your helper to follow your video instructions. Things are fine until they try to use the sketch – which is no longer where it was when you made the tape. Things come to a screeching halt. Sure, it’s technically a history step, but that is in the future and your volunteer can’t possibly know that. Even if the sketch wasn’t moved very far and your helper finds it easily, when they try to use it, the results will be different because the location is different.
It must always be available in the original location because the following operation(s) use it as command input and won’t work if it isn’t where it belongs. But suppose we get clever and ask Shapr3D to magically let us see the same sketch in both places – original location and with the moved body.
What happens when we try to make a change? Where would it be applied – the past body or the future or both??? What if the intervening steps modify the body in such a way that the “changed” dimension was also modified along the way? Does the “future” sketch undo the changes? Are changes impossible (thus breaking some or all intervening steps)?? Nope, this won’t work, and even it did it would be far too complicated to understand.
We could always just make a copy and move it ourselves, thus leaving the original alone so nothing breaks. But that seems like a lot of extra work, and besides, how do we even know it would still match the body which may have been modified.
Well then, let’s just ask Shapr to do the work and give us a free sketch, guaranteed to be in sync, every time the body is moved or modified. Although that might create a lot of extra sketches which might never be used at all, and I imagine at least a few people might complain about filling up the items list.
Or we could just project a new sketch when needed.
Steve, I appreciate your trying, but your explanations not only leave me with more and more questions as to why this isn’t possible, they just confuse me and admittedly frustrate me for not being able to understand your thought process.
Even your analogy makes little sense to me. You use the example of a volunteer helping and then changing the location of the sketch and now they’ll suddenly have no idea how to do the rest of the steps because of that change. I kind of get it, but at the same point don’t at all. The position of the sketch has changed, but hell you’re the one that told shapr/the assistant to change it in the first place meaning they’ll know exactly where it is now. Why wouldn’t the history steps and all the subsequent commands that followed to create the design, NOT follow to that new location?
What you’re describing is changing the first steps and everything else falls apart. Maybe that’s how the program works, I’m not a programmer. I’m describing taking those first steps, and all the subsequent ones, picking them up, and moving them.
I’ll give you an analogy now, maybe it will make sense, maybe not… You live in a location and love your house, you built it from the ground up, it’s appearance and all your belongings and history within, but hate the location. You take your house, with all your stuff inside and put it in a new location. Everything inside the house, the exterior of the house is exactly the same as it was before INCLUDING the history of all the items within the house. It’s just now where you wanted it to be from the start. The location has changed, the neighbors and hookups (alignment with other bodies) have changed. But FUNDAMENTALLY it’s the same house inside and out with all the history associated to every part of it. Where you and your wife conceived your children, the rooms the kids grew up in, where you cooked and ate family meals, etc etc.
Perhaps it’s a difference between software development vs artistic expectation. Perhaps it’s that coding that in would be to much work. Perhaps it’s that coding that in would be impossible.
If it’s the case of it being too much work and not cost effective, then that should be be made plainly clear!
If it’s the case of it being impossible to put into the program, then that should be made plainly clear!
I still don’t know how the coding in the program can’t say take the WHOLE history for this body and move it to this position.
Almost every other graphic program I’ve ever worked with you can change the location of items but still keep their relations to other items since they are also re-located. Sure I get the issue of it’s after certain steps… but it’s fundamentally not changing those steps in any way, it’s just re-positioning them at the same time.
All this has done is reinforce to me that Shapr is now no longer a design program but has now become a rigid engineering based program where certain limitations must be adhered to and things must be designed in place or else. I almost feel like we’re talking past each other as we both have 2 very different ways of thinking. It’s not a bad thing, but I don’t know how productive it’s being to this conversation or if we’re the only 2 people having it, and/or paying attention to it anymore haha.
We get all that. A visual learner? Really? We aren’t stupid.
My problem is that legacy projects have real issues. I opened up a project today, and left the room, and then my laptop started sounding like a jet engine. I closed Shapr, and it was back to normal. I exported all of the bodies individually, brought them back to a new project, and all was good again. This has been a recurring theme with me. I can’t find a pattern. The project from today was a boiler controller that had only 5 bodies, but each contained multiple “openings” that were not symmetrical at all, but it was definitely not complicated. All I know is that exporting to get rid of sketches seems to clean it up.
I have been writing software for over three decades. I’m a DBA. I know how stuff works. This version might be great for some people, but it is a colossal fail for some of us. Unfortunately I don’t have their source code, so I can’t say why. I guess is I scrapped everything and started over, maybe everything would be fine, but that isn’t happening.
Sorry if I didn’t make it clear that YOU changed the sketch while the assistant is out of the room, then ask them to follow the commands exactly, in order, on the video recording. I was trying to explain that Shapr does more or less the same thing as the hypothetical assistant. It literally is only capable of replaying the commands you have given it, in the same order. It can’t read your mind.
Sure, it seems like Shapr should be smart enough to remember that the sketch was moved, and act accordingly. And of course, it is still in computer memory, but as I tried to explain, there is NO good way to act accordingly. No matter what you do, it causes far more problems than it could possibly solve if a sketch is accessed from two or more different times in the history file.
I used the video recorder as a simple metaphor to (hopefully) help you understand how to take best advantage of the history feature. But it is pretty much the only way it could work. Each step literally operates on the results of the previous command. Exactly the same as if you (or your hypothetical assistant) were entering them with a pencil or mouse.
I said earlier that it is the way life works – elegantly simple. One step after another until you each your goal. Which is exactly what you do with every design. One command after another, building it up from an empty workspace. Usually, each new command will do something to an earlier design element. Maybe an extrusion or movement, whatever. But the point is that there is a specific sequence required to get the results you want.
If you’ve carefully recorded each step, another person could follow them precisely and be able to recreate the exact same design. Or possibly make a few small size changes, and as long as they follow all the instructions carefully, still have a functional but customized design. The is really the essence of the Shapr history feature. Simple, elegant and easy to understand (at least once it finally Clicks)
With a little foresight, this can be tremendously powerful. Take a look at some of the videos by Bevelish Creations on furniture design. Even if that is not your thing, it is very helpful. Instead of hardcoding a size (or eyeballing it), he shows how to easily make drawers automatically resize if you change the cabinet size, etc. It is actually less work (and calculation) overall than if you hard code everything.
Back to the actual POINT ( I promise I have one). Whether it is Shapr playing back the history commands, or your hypothetical assistant, if a step is missed, bad things might happen. And it is not just missing sketches. If any body is missing or even just moved too far out of position, or if a mirror plane is accidentally removed, or really anything that a future operation expects to see – you’re going to see the yellow warning sign.
As I said, it’s not just sketches that are necessary for history to work (although they certainly seem to have caused the most concern) – it’s everything (bodies, planes, etc.) that any future operation expects to see. But live sketches are probably the most powerful new feature. To be able to see changes in real time as well having the ability to use constraints to control your bodies is very powerful.
Regarding your point about relocating items in graphic design programs, sure, I’ve seen the same thing. But it is fundamentally different. To be able to implement history in a useful way (not to mention humanly understandable), Shapr needs to be able to USE each design element regularly, and to do that, it can’t be moved around arbitrarily. Remember, sketches are live now. You can adjust edges on the fly. And even move it if you want to ( in the same plane), BUT, any associated bodies will move with it – and every other touching or intersecting object will also be affected – which may not be what you want.
It sounds like the upcoming history collapse feature may allow you to move things around after you’ve removed the association between sketch and body. If so, great. But I strongly recommend you make a further effort to wrap your head around this stuff. Once it clicks, you might find that it can save you some time. There is a reason that so many people have been begging for this, and that so many popular CAD programs offer it. You already learned Shapr when you switched from whatever you were doing before. I can’t believe it would be any harder to get used to the changes and maybe even get some benefit.
I sympathize, but (hopefully) they’ll get it sorted out soon. Sounds like there may be a bug in the Parasolid kernel causing at least some problems. Also, Istvan mentioned something about UI code differences between the platforms.
As I lay in bed last night kicking myself for not being able to explain this more clearly, this point finally sunk in. I apologize for not seeing it sooner. Most people don’t need to know the WHY or the HOW. They just need to understand the WHAT. As I said, it is a simple concept but I’ve managed to over-complicate things by focusing on how it works.
In a nutshell, for the history stuff to work correctly, sketches have to be promoted to first class citizens, with all the same rights and responsibilities. So they behave exactly like every other design element. With direct modeling, you can add or change things at any time, and the rest of the design responds immediately. Which is the main thing that everyone loves about Shapr.
Now, sketches are also live and are ALSO able to be direct modeled. Which actually makes perfect sense and is even more useful than the old way. Just like before, if you change something (now including sketches), everything that touches that thing is also updated automatically and immediately. By itself, the change in how sketches are handled is just an added benefit. It just makes Direct modeling even more powerful.
Now sketches operate exactly like everything else always has. You can make any changes you want and everything adjusts automatically. If you delete or move a body, everything associated with the body is also deleted or moved (all the holes, fillets, etc.). If you change a sketch, the change is reflected in the drawing immediately – and if you delete a sketch, anything you created from the sketch is deleted.
Note: just like always, you don’t need to USE history to do direct modeling. Everything (now including sketches) is live and interconnected at all times. But, for history to work at all, Shapr has to be able to completely roll back commands, make the adjustment, and then roll forward.
I hope this makes it more clear. As I said, it really is elegantly simple, but it may take some time to wrap your head around it.
As it stands now, at least visually, and in your hypothetical. That person re-creating the body would now have to consult a sketch that is nowhere near the body making it less likely for them to succeed. Again, I understand what you’re saying, but I just think it’s a fundamental difference between the way certain minds work. I’m trying to give feedback to make it easy for visual learners, and i’d bet a large majority of at least non corporate users are, to help implement the HBPM into their workflow easier.
)