Monday, December 22, 2008

2008 - The year of Direct Modeling?

I started out this year as an independent consultant doing design and engineering work.  I also did some process consulting for a few manufacturing companies, and even some consulting for some software companies as well.  As an independent I was able to get exposure to a variety of different design tools, CAD and CAE.  It was a good year for this as technology continued to move at a great pace.

During my time as an independent, SpaceClaim came to market (almost 2 years ago now).  I had much fun with that product. They’ve done a nice job at making history-free b-rep modeling simple, fast and flexible and they continue to be a strong advocate for this direct history-free technology.  They seem to be focused on a complimentary, or coexistence strategy and getting CAD into the hands of the non-experts.  In 2008 SpaceClaims’ unique user interaction model and geometry interaction methodologies were “leveraged” by another CAD company, bringing further validation to their place in the industry.

Just prior to 2008, PTC acquired CoCreate, adding direct modeling to their suite of products and raising the awareness again for history-free direct, or as they call it “explicit” modeling.  I watched this closely as I used to work for CoCreate.  Back then PTC was of course our biggest competitor.  CoCreate Modeling remains to be the most matrue and capable of the history-free direct modeling systems on the market - after all they were developing it inside of HP long before CoCreate, the company, existed.

Then came Siemens and Synchronous Technology.  It was great to see all the new attention, again, on history-free modeling.  The marketing buzz from Siemens was that they were the first to combine history-free modeling with a synchronous constraint solver.  Although they weren’t the first, they certainly made some good progress in integrating the two technologies in a useful way.  I still think they have a long ways to go to bring maturity to their history-free modeling environment and the intelligent model, but they certainly have a good start.

There were also many advances this year in direct editing within the history-based environment.  Most all of the history-based CAD vendors now have this capability.  It’s seems a little flakey tracking direct edits in a history tree, but it does further validate the need for more flexibility in our 3D CAD tools.

Now we have Autodesk getting into the fray with Inventor Fusion, another validation that this is where we are heading with regards to 3D CAD.  I still can’t tell what this thing is though.  The demos that I have seen are very trivial and simple, but they do present some nice user interaction tools and methods.  So, is this a history-free CAD tool, or more direct editing within a history-based system, or some weird combo-deal?  Hard to say so far.  I suspect a new history-free environment that will strip away all the history and parameters of an Inventor file, similar to that of SE ST and NX6 ST.  We’ll find out soon enough.  They do show some nice new user interaction concepts and tools. 

While I enjoyed my time as an independent consultant, this last June brought a significant change for me in that I took a job with PTC.  So now I can no longer claim to be one of those “credible independent consultants”.  I guess I’m now a pesky “software vendor”.  It’s been a bit of a strange transition for me.  Not that I haven’t always been a bit bias to history-free modeling, and specifically the CoCreate product, it’s just that now I’m supposed to be. J  I still hope I can be more factual than salesy though.  I think that once someone knows the facts and knows their process and user requirements they will be able to make the right alignment with technology.  History-free modeling is not the answer for all design requirements.  (Not yet anyway).

So what’s coming next year in the world of history-free or direct modeling?  You know, now that we have a few more capable history-free tools out there, we could greatly reduce the interoperability issues that come standard with history-based tools.  Models can now be fully editable across several different CAD tools.  The next step is to be able to transfer history-free features, 3D annotation and parameters between these systems.   The STEP protocol actually has much of this built into it already.  Imagine transferring fully parameterized, intelligent, editable parts and assemblies from one CAD system to another via STEP.  Could it be possible?

Merry CHRISTmas and Happy New Year!!


Wednesday, December 17, 2008

History-Free Bolt-Hole Pattern

Here is a quick addition to my previous post about history-free parametric modeling. This is based on a question about bolt-hole patterns.

To get the video I just animated the variable that controls the outer diameter of the ring. (During the animation, only the faces that are affected are displayed) The bolt-hole radius, number of holes and the inside diameter is based on the outer diameter. As the outer diameter changes the bolt-hole radius changes as well as the number of holes and ID.

I realize this is reasonably simple stuff with a history-based system, but most people assume that it can't be done with a history-free system.

Again this is a history free model. There is no history tree and no parent/child relationships.  A feature was defined from existing faces, a pattern of the feature was defined, and a few parameters and expressions were added for control.  It is solved synchronously.  (and yes, I did it with CoCreate)

This can be done with an IGES file.

Monday, December 15, 2008

History-Free, Parametric Modeling (Part II)

In Part 1 of History-Free Parametric Modeling I attempted to present the reality of adding intelligence to a history-free model such as constraints, parameters and feature information. With Part II I hope to show what is possible with respect to assemblies. Getting a part to behave as intended (design intent) is equally important as getting an assembly to behave as intended. By capturing intelligence about the design at the assembly level, we can begin to use 3D to design products/systems/solutions rather than just parts. Using synchronous solvers on history-free part models is nothing new, nor is it new at the assembly level.

Similar types of relationships can be defined on an assembly level as on a part level. Most common may be coincidence, distance, angle, parallel and perpendicular. There also may be special assembly relationships such as gear or cam.

Again I am using CoCreate Modeling just because that is what I know the best. I am sure some of the other history-free modeling systems are capable of some of this functionality as well. The first example I will show you is of a fishing reel. A fishing reel has some reasonable mechanisms in it. While you are reeling in the line the head is spinning, and the spool is moving in and out to keep the winding on the spool even.

In this case you can see that I have several coincident relations and a gear relation. The gear relationship is used to represent the ring and pinion gear used in the reel. The rigid relations keep the subassemblies constrained as units. It took maybe 15 to 20 minutes to setup the necessary relationships for the fishing reel.

Once relationships have been defined, you can use the added intelligence to analyze motion, functions and identify interferences. In this case an animation of the solution was also captured with rendering, although my rendering is not too good. I took the cover plate off and put a mirror on the side in hopes that you can see both sides. Here is another video without the housing.

As with part relations, CoCreate Modeling allows you to have multiple relation sets on the assembly level as well. In this case you could have one set to simulate the assembly process and one set to simulate functionality. Mathematical equations are also allowed within the solution set. The equations can also include logical expressions such as if, then, else, and mathematical expressions such as equal, not equal, less than, less than or equal and others.

Here is another simple example. This one uses both a cam relationship and several gear relationships. This is the eject mechanism for a CD drive in a laptop.

Assembly relationships can be used for several purposes. They can help keep mating parts in the correct position as other parts are moved or modified. And of course they can also be used to represent mechanisms or perhaps the assembly process. Really no different than what you can do in a history-based system. The only difference is that with a history-free modeling system, the relationships can be added any time during or after the design process, and they are solved synchronously. It also seems to be a bit more intuitive and forgiving when you don’t have to be concerned with order.

I have often heard people make the mistake of assuming that by using history-free modeling you are giving up the ability to capture design intent. So I hope I have shown with these articles and simple examples that design intent can be fully captured with history-free modeling. I would even argue that it is much easier and more intuitive in a history-free environment. You certainly cannot capture how the model was created – but since when did the model creation process align with the design intent?

Wednesday, December 10, 2008

CAD Interoperability: Native Files vs. STEP

Matt Lombard has an interesting article on his blog titled: Best way to translate Catia Files into SolidWorks? Use Inventor. It spurred a lot of good comments and questions. Check it out at: It spurred some thoughts of my own, and now I have a related question, and it is a bit of a loaded question: Why is it important to load native files versus STEP? I think these are some of the possible answers. They may all apply, but which one best describes your need or problem?

1) Speed and convenience - no translation required
2) Managing risks - don’t want to create and manage another document of the same object
3) Must have a valid solid model - good 3D geometry
4) Must have an editable model - history tree with sketches, features and constraints
5) Must have round trip translation of editable models with no data lose

If you answered #1: Maybe this means that you have to go back to the owner of the native file to request a different format. This can create delays in the process. It should not take too long to actually create the file, but the communication and extra effort would not be necessary if you could just use the native file.

If you answered #2: If you must create a STEP file, you now have another file (document) that represents the same part. Do you know what version the STEP model is connected to? If you send a STEP model out, are you (or the receiver) confident that it is the correct version? Managing another document just adds more complexity to the process and presents a higher risk for mistakes. By using the native file risks can be lower and there is no need to manage another document.

If you answered #3: With STEP perhaps you get erroneous data/geometry – missing faces, gaps, and other geometry problems. You assume that by loading a native file you will get better geometry translations. This assumption is probably wrong, however. There are several issues. If the sending system is a history-based system, the native file may not even contain the 3D geometry, but rather only the receipt, or history-tree, with sketches, feature definitions and parameters (another issue covered later). If the native file does contain geometry, the resolution or accuracy of the geometry will be based on the CAD systems operating model resolution. For some strange reason all CAD vendors have chosen different model resolutions for their CAD system to run at. For some it is adjustable, for others it is somewhat dynamic. Translating a model from a high-res CAD system to a low-res CAD system is not a problem. Going from low-res to high-res is a huge problem. Do you know what model accuracy your CAD system is using when creating 3D geometry? Solid Modeling is all about connectivity. If it cannot connect, it is not a valid solid. The big problem with this geometry accuracy issue is that the people that are creating low-res geometry probably don’t know it. It’s the ones on the receiving side that know it – unfortunately they usually blame the problem on their own CAD tool, when in fact the geometry issues are most likely a result of the junk data coming from the sending system.

If you answered #4: If the sending and/or receiving side of the exchange is a history-based system and you need editable models, you must have the history-tree with all of its components. This is a very tall order. The technology to translate one history-tree to another exists but it is very complicated and expensive. Basically the history-tree, and its contents contain a CAD systems competitive advantages. Things like a special modeling feature or perhaps a unique rounding feature are all contained in the tree. A new version of a CAD system will certainly have enhancements and new features that are captured in the tree. What if one of these features (competitive advantages) does not exist in the receiving history-based CAD system? How will the receiving system handle it? What happens when you upgrade to the next latest and greatest version?

If you answered #5: Go out and purchase a history-free CAD system, now. If this is a requirement and you don’t have one, you are wasting HUGE amounts of money and time. (and/or putting reducilulous requirements on your suppliers.) Just make sure your suppliers are deliverying good high accuracy geometry. Set some standards for it - after all you are paying for it.

So the next time you have a discussion with your CAD vender about interoperability and data exchange, don’t just tell them that you need to load native files, tell them what it is that you really need in order to support your processes and requirements - describe the problem. Too often we tell them how to solve a problem rather than telling them what the problem is that needs to be solved. They are actually good at solving problems, once they know what the REAL problem is. (Also, while you are at it, help your CAD supplier understand your need for higher resolution/accuracy geometry. I am continually amazed at how much junk geometry comes out of our modern CAD systems.)


Thursday, December 4, 2008

Getting Expected Results with Direct Editing

I received a few questions about an earlier article with regards to getting expected results from direct geometry edits. When you start pulling on various faces of your model you may or may not get what you are expecting. This applies to both history-free direct edits as well as history-based direct edits. To show this in its simplest form I will use the simple model shown below. In this case we are pulling on the yellow face.

With a linear pull there are at least four different possible solutions to this edit.

  • #1 - The pull face changes size as the adjacent faces are stretched
  • #2 - The pull face size is maintained, the adjacent faces are stretched and the angle of the top face is changed, topology is unchanged
  • #3 - The pull face size is maintained, the angle of the top face is unchanged and topology is changed – a new face is created
  • #4 - The pull face changes from a planar face to a b-spline surface

There are certainly other possible results if you pull around an axis.

With history-free modeling there may not be any relationships or conditions built into the model that would drive any one particular result. As such the results are completely based on the type of command or command options that may be available to the user.

For direct edits in a history-based system, the result may be completely dependent on how the model was originally created, as with any other edit in a history-based system.

In the history-free category, with their instantaneous graphical feedback, SpaceClaim certainly leads the way in helping the user understand the results immediately. I just personally struggle in SpaceClaim finding the right options to get different results, but I’m no expert with SpaceClaim.

Siemens is following SpaceClaim with the instant feedback, but again getting different results seems difficult for me. #1 and #3 are easy to get with the Pull Face or Move Face commands. The others???

CoCreate Modeling provides all the options for getting any of the results above, but it does not yet have the instant graphical feedback for case #1 and #2, although I am sure this is quickly changing.

As with any CAD tool, it takes some practice to understand what is possible and how it’s going to work, but don’t assume that just because it is or is not possible in one system, that it will work the same in others. There's a lot of progress being made in direct editing technology. The nice thing about history-free direct edits is that the results are completely independent of the how the model was originally created. You decide, right at the time of the edit, what results you need and “make it so”.


Monday, December 1, 2008

History-Free, Parametric Modeling

History-Free parametric modeling? Is there such a thing? To some it may sound like a contradiction in terms. The term “Parametric Modeling” is often used to describe history-based modeling. Certainly parametric modeling came of age within the context of history-based modeling, but in fact, parametric modeling is not reserved for the history-based CAD products.

For me “parametric modeling” simply refers to the addition of persistent geometric relationships, constraints and parameters to 3D models. This added “intelligence” is then used to control the behavior of a model. The following are some common examples of relationships, constraints and parameters:

  • Parallel
  • Perpendicular
  • Tangent
  • Coincident
  • Planar
  • Distance
  • Angle
  • Radius
  • Diameter

History-based modeling provides a nice platform for parametric modeling in that you can easily add parameters to the 2D sketch. It is also common to have predefined parameters and constraints associated with 3D modeling features, such as the depth and diameter of a hole feature. During the creation of these features, users are given the opportunity to specify the value of the parameters. Once the sketch is defined and/or the modeling features are defined, they are captured in the history tree. Users are also given the option to add dimensional parameters to the sketch and/or modeling features. When changes are needed, a parameter or constraint can be adjusted and the history tree will be replayed to form a different model based on the modified parameters. The model is actually recreated from the point of change each time the tree is replayed, or regenerated. The parameters are similar to variables in a software program. Change the variables and replay the program to get different results.

Parameters and constraints in a history-free environment can be a bit more complex in that they are all 3D and must be solved synchronously. They must control conditions in 3D space that are typically controlled in 2D space within the history-based 2D sketch, such as tangent or parallel. Due to these complexities, the history-based platform may be the ideal platform for fully constraining a 3D model. However this is quickly changing with continued advancements in 3D parametric solvers and new intuitive methods for applying and interacting with 3D parameters.

Today there are only a handful of history-free modeling systems on the market, and only a few of those have full parametric capabilities. PTC CoCreate Modeling (Formerly HP SolidDesigner) has had this capability for many years now and probably has the fullest set of capabilities for managing 3D parameters within history-free geometry. As such I will use examples from CoCreate Modeling to highlight some of the challenges and benefits of history-free parametric modeling.

One of the key benefits of history-free parametric modeling comes from the fact that these parameters can be defined anytime during or after model creation. Parameters can be added and removed anytime regardless of the completeness of the model. As a matter of fact, an imported IGES or STEP file can be fully constrained and parameterized with a tool like CoCreate Modeling.

Below is a picture of a wheel that has been constrained using CoCreate Modeling. It is probably not fully constrained, but may be close. This wheel started out as an IGES file from some other CAD system, so all parameters were added after the fact. In this case there are basically three key variables identified in the solution. One for controlling the width, another to control the outer diameter, and another to control the bolt hole circle radius. The parameters are organized and managed in what is referred to as a “Relation Set”. Relation sets are owned by the part. In the picture of the Structure Browser you can see a part called “Wheel”. Underneath Wheel is a relation set called “Wheel_Set1”. Within the set is the list of all the parameters that have been assigned to the part. The first parameter in the list is a Radius parameter that is the driving parameter for controlling the outer radius of the wheel.

With a parameter set like this, it takes CoCreate Modeling maybe 12 seconds to solve the complete wheel when a change is made. It will not make a difference whether one variable is changed or all three are changed. It takes the same amount of time to solve, as you are solving the entire solution set simultaneously.

To reduce the amount of time it takes to solve a set, CoCreate Modeling allows you to have multiple relation sets per part; any number of sets with no limit. However, only one set can be active at a time. Multiple relation sets also gives you the opportunity to capture multiple studies or scenarios within one part. Something that is not possible with history-based modeling without building a new part. In the example below, I separated the parameters into 3 different sets. One set to control the width of the wheel, one set to control the outer diameter, and one to control the bolt hole circle. Each set is now independent and will not impact the other. In this case now, to solve for example a width change, the solution will take about 5 seconds to complete. (Of course this depends on the machine you are using). The change has no impact on the other relation sets. Notice how all other geometric conditions are being maintained within the model, conditions such as tangent and concentric.

You can also include equations into your parameter definitions. For example in the Wheel_Width set there is a simple equation that will drive the location of the hub based on the width. If you look closely from image one to image two you will see that the position of the hub changed relative to the front of the rim, as the width changed. The equations can also include many logical expressions such as if, then, else, and mathematical expressions such as equal, not equal, less than, less than or equal and others.

Here is another simple example of a history-free parametric model. In this case it is a plastic connector body. There are a few features and patterns that have been defined. Parameters are then used to define the number and placement of the features. One of the parameters is used to define the number of pins for this connector. Based on that number, features are added or removed and the geometry is adjusted.

As with any parametric modeling tool, it is possible to over constraining a part. If this situation happens in CoCreate Modeling the system will highlight the parameters that are involved with the over constrained condition to help the user quickly resolve the situation.

Parameters are only as good as the underlying geometry engine is at making the actual geometrical change. If the system is not capable of making complex geometrical changes, driving that same change with a parameter will also not work. As mentioned in an earlier blog article titled “Key Capabilities of History-Free Modeling”, properly managing adjacent faces and topology changes are critical to history-free modeling.

Of course adding parameters to a model is only good for one thing; controlling the behavior of the model. This type of control is not always necessary however. With history-free modeling you have complete flexibility in adding constraints and parameters to your model. Users can focus on the task of design, and only apply parameters and constraints where and when it makes sense and adds value. Keep it “Lean”. Don’t waste time on creating data that adds no value to the actual design.

So, history-free parametric modeling is a reality and it is VERY cool. It actually works like most engineers think – unless they have been brain-washed with history-based modeling. History-free parametric assembly modeling is also a reality. Maybe I will cover that topic in a later blog.