History and Sketching
Ok, let’s take a break from talking about the cloud and business aspects of CAD. You’d never guess it, but I really hate that topic.
From the frying pan into the fire. I just can’t avoid controversy, it seems. I’ve been thinking a lot about history modeling, and history-free modeling. I’ve also been thinking about why sketches in history modelers are somewhat hypocritical about the whole history deal. I mean, the sketch entities within a single sketch are not history based. The relations aren’t history based. Technically, on some level that the user isn’t meant to know about, it does matter what order things are drawn in, but even if we knew about that, it would be pretty esoteric.
Just imagine for a second that all of your sketches were history-free as they relate to other sketches. They have to have some relation to history as they relate to solids and surfaces, because of the whole parent/child thing. But all sketches would be basically just one big sketch on several different planes.
Let’s be even more theoretical for a second. Let’s make believe that 3D sketches in SolidWorks worked perfectly. Let’s imagine that the 3D planes within a 3D sketch work as they should, and sketching on planes in a 3D sketch didn’t have any of the penalties that they have in real SolidWorks usage. If all of your sketches in SolidWorks were piled into a single 3D sketch, you would have the advantage that there would be no history conflicts between sketches. You know, like you want one entity to drive another, but in order to make that happen, you have to remove a bunch of relationships, redo a plane definition, and then reorder a sketch and a plane and recreate a pile of sketch relations. Sometimes a feature gets thrown in there, and a sketch is dependent on a feature which is dependent on another sketch, so reordering becomes even more tedious.
Think about it. What advantage do you get from your sketches being “history dependent”? I don’t think you get any. In “classic orthodox SolidWorks”, you have one sketch, one feature. A sketch on a different plane means an additional sketch. You have one sketch for a sweep path, and another for a guide curve, even if they are coplanar. But “classic orthodox SolidWorks” has been going by the wayside, if you haven’t noticed. Multibodies, regions/contours, the SelectionManager, extruding from a 3D face or 3D sketch, they all work to undermine the “classic orthodox SolidWorks” to the point now that people are only orthodox out of habit, or a belief in “best practice rules”.
And then we can take the argument one level further to assemblies. Assemblies are only history-dependent in special circumstances. If Part1 makes a sketch relation to a Part2 edge in the context of an assembly, and later the referenced edge of Part2 is removed by a fillet, you’ve got a dangling sketch relation. That’s because there is no such thing as inter-part history in an assembly. And thank goodness. How complicated would that be?!?
I think there are a lot of aspects of history-based modeling that are worthwhile and a big improvement over direct editing, but I don’t think any of those apply at all to sketches. Solid Edge has this thing called the Blue Dot, which puts all sketches it touches on an equal footing, history-wise. So if you make a mesh of sketches to create something like a Boundary surface in SolidWorks (Blue Surf in Solid Edge), the order of the sketches doesn’t matter at all if you put a blue dot where they intersect. It’s a beautiful idea when you run into it, and you realize the freedom you gain, and that you have lost nothing. It’s hard to find reference info on this function, but here is some I wrote a while back.
I guess what I’m saying is that if SolidWorks 3D sketches were more reliable from the sketch relations point of view, and if the 3D planes functionality were dependable enough to use, you could throw away the entire concept of individual history-based 2D sketches altogether. It seems to me that when SolidWorks introduced the Layout assembly feature, someone realized this, but they had more faith in the 3D sketch tools in SolidWorks than I do. Layout to me is an implementation failure, not just because of the shortcomings of the 3D sketch relations and planes, but also because of the crazy way they substitute assembly mates for sketch relations. In concept, the Layout is brilliant because it bridges all the difficulties in this history and in-context business, but it is far, far, far from usable. When they introduced Layout a few releases back, I actually questioned someone about if they were preparing for the eventual demise of the 2D sketch. Whoever I asked said no, but you know how that goes.
If I were to create a new CAD system from the ground up, the first thing I’d do would be to just allow sketching where ever you want to sketch, and to eliminate the concept of curves as we know them in SolidWorks (all curves would be sketches). So there would never be any history-based conflict between sketches, and all of the special-case problems we see with the neglected Curve feature type would disappear. Sketches also would not be “modal”, that is to say that they would always be “on”. And sketches would be able to have both parent and child relationships with the solid, which would create the same kind of circular relation possibilities that we now have with assembly in-context modeling, but there would be some fast and easy visual way to identify parents and children.
How much time do you waste exiting one sketch, waiting for the model to rebuild, then opening another sketch, waiting for the model to build back to that point, making a change and exiting again, rebuilding the model yet again? That’s a huge amount of wasted time. How about make a change to the sketch, make several related or unrelated changes to sketch geometry, and when ready, click on an update button. All the features related to changed sketch entities update. Nothing updates until you tell it to, and you don’t have to jump “in” and “out” of sketches, waiting for unnecessary rebuilds. That would be a huge improvement in workflow and time, even with a fully history-based modeling system.
What SolidWorks has done in 2012 with being able to freeze the feature tree is a HUGE first step toward gaining control over the history-based system, but it’s just a first step, and its tiny in comparison to how much work there would be to do if they were planning on going all the way with this scheme. Direct editing is not going to fully supplant history modeling (ever) because there are a lot of great ideas left to explore to keep history modeling more powerful, and less wasteful of resources (mainly time). It seems to me that in the years since PTC pioneered history modeling, the basic scheme hasn’t been questioned. Most of the available improvements would have had more impact years ago when hardware wasn’t as capable as it is now.
@Dan Staples
Dan, re. your observation that most CAD players adopted a variational (or declarative) approach to 2D sketch and assembly, and a historical (or procedural) approach to part modeling. I think it primarily came about because in the 90’s we couldn’t handle 3D variational solving. Since then, the machines have become much faster, and there has been some improvement in the algorithms. It is almost universally accepted that a declarative approach is better. That we would all embrace a system which finds one solution when an under-constrained model is presented. But I am not so sure if a declarative solution is always superior. One issue is that it’s not enough to find _a_ solution to the problem, but the solution presented should be “good” or a “right” solution. Of course, one might say, that the answer is to add additional constraints to force a desired solution. In theory, it ought to work. But in practice, users would be trying to second guess how the solver works, thus defeating the inherent value of declarative modeling. But a bigger problem, is that this forces us towards models which are over constrained. The solver at this point is simply required to confirm that there is no feasible solution. But a human user wants to how he could get a feasible solution. I think that finding a solver that would do well on this score is still some distance away. This has not been a huge problem, for the most part, with sketches and assemblies which use variational solving, since the problem “size” tends to be smaller. Even then, you still hear about users struggling with assembly constraints. So, I think there are some virtues to the simplicity and predictability of procedural modeling, which are often ignored.
Have you checked out 123D? (based on Inventor fusion). This uses sketches as you describe, however – like Rhino the sketches are currently non parametric.
I would love to see solid primitives and clipping sketches used together as you describe.
Some random thoughts:
I have a suspicion that most of the history inflicted on CAD users has been implemented to break the model into bites that processors of the 90’s could handle. Obviously, it’s time for that to change in a big way. I think there is still a need to manage dependencies with an eye to performance though.
I use a lot of 3DSketches for manifold plumbing layout. (Incidentally, sketch relations and planes in 3DSketches make perfect sense to me. If only the planes were properly respected outside the sketch.) Some of these layouts are large, and rebuild time becomes significant very quickly. It seems to increase with something like the square or cube of the number of entities, probably depending on the relationships. I suspect that solving all the 2D sketches simultaneously or as a 3DSketch for complex parts could lead directly to performance problems. I don’t know if threading can be brought to bear on that problem or not. Probably not unless the a threaded solver has already been written. I think some kind of intelligence that makes sketch groups behind the scenes would be necessary. How much do you want to bet that mate groups are still with us, only hidden?
To get back to agreeing with the general thrust of your post… I can’t tell you the number of times I’ve had to fight with the artificial history, or roll back into features to expose sketches for historical tricks I wouldn’t want to have to diagnose in a year. I think that getting rid if this artificial history is the future of parametric modeling, and I can’t wait for it. SE seems to have been leading the way, though I didn’t like how synchronous modeling was marketed early on. From what I’ve seen, there’s still work to be done too. I hope we can see some progress on SW v6 at the next SWW, because SW is behind the curve. SE could be the SW killer, if SW doesn’t get something done in the next year or so.
Sketches are very important, they control the geometry. I arrange the controlling dimensions so that they make sense for the project. Relations are intentional not an accidental alignment. Some dimensions are used later for structural optimization. I would like to have some text notes in the sketch. Colors would be nice.
@Dan Staples
Dan, yes, you just drag a bar, and everything above the bar is frozen. Everything below the bar is active.
It gets weird when you have a sketch made out of order or shared between features. If when you totally flatten the tree (show the features and sketches in a totally history based order), a sketch is above the line, then you get the weird situation where a sketch is frozen, but the feature is not.
I know when SW was doing some testing on this with users there was some discussion about what we wanted vs what could be delivered with a given amount of resources. This function was supposed to be in SW2011, but didn’t make the cut, so its showing up in 2012 as it is.
I agree, it would have been better to be able to select chunks of the tree or individual features to freeze rather than a single bar to move.
I’ve also been advocating for some time that SW should enable a mode where the tree is displayed in straight history, to help you make sense out of crazy things like this that happen frequently.
On topic, I think Matt hits an interesting point that we noticed when first doing the groundwork for Synchronous. Sketches are solved simultaneously, not sequentially — have been since Pro/E first came out. Assemblies are solved simultaneously, not sequentially – since at least mid-90s and surely before that. Why are parts — which bridge the gap between sketches and assemblies — sequential (ordered)? There is value in ordered in certain situations, but it is conceptually odd that both ends are simultaneous and the middle is sequential, eh?
So not to hijack this, but what about this “Freeze Feature” thing. Our research shows its not really freeze feature but “freeze upper part of tree above this point”, which seems quite a different (and less useful) thing. Can anyone comment on whether and how it freezes features within the tree while recomputing those “around” it?
Sketches are useless. The only time you need a sketch is to create a starting point for 3D geometry. After that the geometry should stand on it’s own. If you need to change the geometry then sketching could be generated on the fly. it’s very possible to generate features without sketches.
I’m not saying Rhino is the answer to this specific problem, but being able to sketch whenever you want and being able to use said sketch entities for whatever you want whenever you want is certainly nice.
Biggest downside though, sketches are not parametric and don’t get married to features, so there’s no going back to the sketch change a few dimensions and have everything else update. Still if you are doing concept work it can be a much faster less restricted workflow.(I know there’s history in Rhino, but it’s not like SWX history)
I could see these two workflows merged being very beneficial. Don’t have any experience but is that what Spaceclaim is doing to some degree and Solid Edge with Sync Tech?
History with sketching has one very important purpose… To allow geometrically and dimensionally constrained sketches to be workable by breaking them up into logically small and digestable sets of geometry that can be solved serially. Have you ever tried to do one massively large and detailed sketch involving hundreds of entities and hundreds or thousands of relationships that must all be solved in parallel? It is extremely slow to say the least, making them unusable…
I find that the “master” sketches need to be uncorruptable by changes in the detail sketches. I make these sketches at the highest level and place them mostly on principle planes or parallel planes. I make derived sketches to not allow a feature to absorb the master sketches.
Curves are both inaccurate and unduly limited. We should be able to project an entire sketch onto a surface or a logical surface determined by a single valued sketch.
Features should not consume sketches and curves. We should group those local sketches in folders that make sense to us. Strangely parts of a 3D sketch are independently selectable and used nicely in lofts, and boundary surfaces. Solidworks creates some parent child history that does not need to exist but makes changes much more difficult.
3D sketches are difficult to control. Splines and arcs are particularly troublesome. I think it would be much easer to move 3D points by allowing mouse motion only in the view plane. 3D sketches are difficult to dimension.
One example of the shadow history in sketches I see frequently is the sudden overdefinition of the entire sketch by trimming offset entities. Suppose I’ve got a box-shaped face where I offset three sides of the box shapes once, and then another time at different offset distances. I then offset the fourth side one time. When trimmed, I get a U-shaped profile of sketch entities. However, when trimming, I often get a sudden seizure of all entities being overdefined—in which deleting relations produces nothing but an entirely blue sketch.
I don’t know why, but to defeat this, you can carefully trim the entities in the right order (whatever that happens to be—this is subject to the shadow rules of order), or you can split the single fourth offset entity into two pieces before finishing trimming, and somehow that makes everything OK. Odd. For cases like these, it would be nice to know the rules (or, even better, to eliminate the rules), since my sketch should never be overdefined based on the order in which I trim entities (and not overdefined if I guess wisely).
You are right of course the tree is a chore. I wonder how good feature freeze is in reality?
I have yet to see a decent review of it. Hint 😉
At one time I suggested SW rejig the code such that there were shadow processes running on other processor cores to handle simultaneous creation, rebuilds, undo etc in the background to the tasks being set up in the UI. I suppose in some ways that is a bit like a cloud on a PC but the intention was to get around those annoying waits.
More recently I thought of siamese twinning two SW installs across two PC under a tied license to keep the user productive.
Well of course imaginative and original rearrangements of tasks vs hardware like that disappear into the abyss.
I think Ron Chin, SW curator of great ideas that never saw the light of day, writes those type of innovations off as indulgent fantasy but I wonder how many good ideas go unexplored because SW are distracted with a particular mission DS management have sent them on or how likely their brainstorming is to produce worthy projects with a throng of departments to please.
Come to think of it another one of my opinions I shared here and now lost to the hackers was that SW as a large corporate cant innovate effectively but that fight for better thinking has now been superceded by the war on the cloud obsession…oh well…
If SW was still being actively developed I am sure much more could be done structure wise to make using is easier/faster/better.
I guess feature freeze is something that we ought to be grateful arrived better late than never.