Hey, I mentioned this feature request in the feature request thread, but I feel it got lost in the forest, so i’m re-explaining it here, so I can more easily reference and refine my requirements.
I donn’t know if i’m using the software wrong, but I use lofting a lot, and I’m doing some embossing by sketching, projecting, extruding, moving and cutting the extrusion from another shape.
As my usage is very exploratory, i really would like to be able to make easy save checkpoints without having to duplicate and rename shapr files, it’s rather annoying. Plus I need to open them to verify which one has what changes.
Don’t write posts at 1 am I guess, you’ll forget the details of what you meant.
The point of the embossing and the history checkpoints is that I would like to make a base shape, checkpoint that, do all the union parts, make the embossing text, cut it from the joined part, checkpoint that, export it as STL for 3d printing, and the be able to go back to the shape before the embossing cuts. And do another cut with a different text.
Ideally I should be able to navigate the resulting tree of without having had to create tens of copy of the file.
Hopefully you would be able to navigate between history checkpoints within the 3d view of your model so you can see the different versions as you switch.
I imagine it could be useful for architects demonstrating different room arrangement or roof styles from a base state as opposed to making separate copies.
Or designers exploring different accents on a base shape.
We totally feel your pain. This is one of the most important things that we are working on: how to make editing bodies easier, without the pain of traditional design history. Unfortunately, this is a really hard problem, but we’ve made some progress over the last few months, and some very exciting stuff is coming later hopefully based on this R&D project
Hmm, what’s wrong with “traditional design history”? Apart from appalling UIs (everybody seems to insist on a row or column of tiny meaningless icons), the concept is sound and I’d be very glad to see it in Shapr3D (so that we can have fully parametric history-based modeling!).
It’s not. History based modeling has many many flaws. There is a reason why direct modelers were invented (it’s another question why pure direct modeling why not became more popular). History based models tend to break often. Can’t follow unexpected design changes. Modifying someone else’s history based design more often leads to issues than not, thus collaboration is a pain. Changing a parameter often leads to unexpected/not wanted changes in the design. This is even worse when you have dependencies between parts in an assembly. You have to follow obscure rules to make your history more stable, but often not even that helps. The entire concept of history based modeling is basically a very crappy programming language, with all the drawbacks of programming without any of the benefits. Doing it right is actually just as complex as writing code, but it is not even close to be as general and expressive as programming.
History based modeling is a pain in the neck, often even for highly skilled CAD users. We strongly believe that there must be a better solution for the problem that it is trying to solve
The way I see it, direct modeling is a subset of history-based modeling. You could use a history-based modeler and hide the history from the user, and it would behave like a direct modeler. I do agree that history could be implemented better and that we have a long way to go, but I don’t think saying “just do direct modeling” is the answer (please see my other long post with examples of how I can’t really use a direct modeler).
Let’s take a spreadsheet analogy: you could say that “direct modeling” is when you copy/paste the VALUE of a cell somewhere else, instead of referring to it via a formula. Yes, it’s simple, and it doesn’t break down, but it drastically limits the usefulness of a spreadsheet. So, even though we have to follow obscure rules, deal with painful debugging, costly mistakes, and annoying breakage, we still prefer to use formulas and refer to other cells, because it makes the tool much more powerful and flexible.
