3D CAD World

Over 50,000 3D CAD Tips & Tutorials. 3D CAD News by applications and CAD industry news.

SolidWorks

The failed promise of parametric CAD part 4: Going horizontal

By 12 Comments

In the early 90s, Ron Andrews, a senior product designer at Dephi’s Saginaw Steering Systems Division, became fed-up with the difficulties of editing parametric CAD models. So, he and a team of his colleagues, including Pravin Khurana, Kevin Marseilles, and Diane Landers, took on a challenge of trying to find a solution.

They came up with an interesting concept that they called horizontal modeling. Here’s a description of it from their patent abstract:

“Disclosed is a horizontal structure method of CAD/CAM manufacturing where a base feature is provided and one or more form features added to it to form a model. The form features are added in an associative relationship with the base feature, preferable a parent child relationship, but are added in a way as to have substantially no associative relationships with each other. The result is a horizontally-structured Master Process Model where any one form feature can be altered or deleted without affecting the rest of the model. Extracts are then made of the Master Process Model to show the construction of the model feature by feature over time. These extracts are then used to generate manufacturing instructions that are used to machine a real-world part from a blank shaped like the base feature.”

Here’s a picture that makes it clearer:

Horizontal Modeling

The simplest explanation I can give for it is this: You create a base feature, and bunch of datum (working) planes. You attach all the child features to those datum planes. Viola: no parent-child problems.

I admit that I’m not going to do justice to horizontal modeling in this conversation. There’s actually quite a bit to it, and it makes a lot of sense when coupled with computer-aided process planning (CAPP.)

Horizontal modeling has a handful of problems. First, it does a pretty good job of killing the possibility of having design intent expressed in the feature tree. Next, it works better with some CAD systems than others. (When horizontal modeling was in the news, SolidWorks had a problem managing the normals on datum planes, so it didn’t work too well.) The deadliest problem is that Delphi got a bunch of patents on the process, then licensed it to some training companies. From what I can see (and I may be wrong), none of these training centers offer horizontal modeling classes any more.

While, technically, you can’t use horizontal modeling without a patent license from Delphi, the concepts at its core are fairly similar to things that CAD users have been doing for years. A few years ago, Josh Mings posted on a couple of online forums that “Horizontal Modeling is just one word for it, you may also know it as Skeleton Modeling, Tier modeling, Sketch Assembly modeling, CAD
Neutral Modeling, or Body Modeling.” (It’s actually two words for it, but I get his point.)

Horizontal modeling is not a silver bullet solution for the problems inherent in parametric feature-based CAD. It’s just a best practice—a strategy for getting around the problems. It seems to be headed in the right direction, but it suffers from the complexity that comes from trying to fix too many problems at once.

Next: A Resilient Modeling Strategy

The failed promise of parametric CAD part 3: The direct solution

By 5 Comments

Pull-PushDirect modeling—a syncretic melding of concepts pioneered by CoCreate, Trispectives, Kubotek (and many others)–has shown the most promise to cure the parametric curse.

Direct modeling is today’s hot CAD technology. PTC, Autodesk, Siemens PLM, Dassault (CATIA, but not so much SolidWorks), IronCAD, Kubotek, Bricsys, SpaceClaim (and certainly some other companies I’ve forgotten) all have their own unique implementations of it.

The common thread in direct modeling is to use standard construction techniques when modeling, and feature inferencing (or recognition) when editing. It’s easier said than done. It’s taken about 35 years of industry research to get to the place we are today—where you can click on a face of a model, and the system will recognize that you’re pointing to a feature that has some semantic value. And that’s not even considering the tremendous amount of work that has been required by legions of PhD mathematicians to develop the math that lets you push or pull on a model face, and have the system actually edit the geometry it in a useful manner.

For the CAD software, figuring out which way to edit a selection is almost a mind reading trick: A user clicks and drags on a part of a model. What would they like to happen? In some cases it’s easy: Drag once face of a rectangular block, and the system will just make it longer or shorter. But if the block is full of holes, bosses, and blends, it becomes a lot more complicated. What should the system do if you drag a face so far back that it consumes another feature, and then pull it back to where it was? Should the consumed feature be lost forever, or should the system remember it in some way, so it can be restored?

There are no right answers. It seems that no two direct modeling systems handle the decision of what is a “sensible” edit in the same way.

While direct modeling absolutely solves the model brittleness problem inherent with parametrics, it does it by simply not using parametrics. Even with hybrid parametric/direct CAD systems, the answer to the parametric curse is still to not use parametrics when you don’t need to.

The solution of “use direct modeling when you can, and learn to live with parametric hassles when you can’t” just isn’t very satisfying to me.

Next: Going horizontal

The failed promise of parametric CAD part 2: The problem is editing

By 4 Comments

ErasermIn the previous post, I wrote about the failed promise of parametric CAD: problems such as parent-child dependencies and unwanted feature interactions, coupled with no easy way to either prevent, or check for them.

The difference between modeling and editing in a parametric CAD system is simply the difference between creating things from scratch, and modifying things you’ve already created. The distinction may seem academic, but it is only when editing that parent-child dependencies are a potential problem.

Consider a scenario, of creating a parametric part—one that you’ve worked out in your head pretty well ahead of time—where you start from scratch, modeling sequentially, and spending all your time working on the most recent feature without needing to go back to edit upstream features.

In that context, the model’s parent-child dependencies would exist, but would be benign. They’d never get in your way. That is, until you went back to edit the part.

In most cases, people don’t build models from scratch without periodically going back to adjust earlier features from time to time. In that process, they’ll catch, and be able to deal with, some of the dependencies. But not likely all, or even most, of them.

I’ve heard experienced CAD people use an interesting term for models with hidden and untested parent-child dependencies: Parts from hell. When you’re trying to modify them, you never know when a small change might cause them to completely fall apart. I think a better, more descriptive, term is brittle: Hard, but liable to break or shatter easily.

This also suggests a descriptive term for CAD models which are not liable to break or shatter easily: resilient.

I’ve only ever seen one group of users who could consistently create complex yet resilient parametric parts models from scratch: PTC application engineers from the early to mid-1990s. Of course, they could only do it during customer benchmarks, with parts they’d practiced ahead of time, where they had worked-out and memorized all the steps, and where they had a good idea of the parameter ranges. Even then, if you were to ask them to change a dimension that would cause a topological change, the models might unceremoniously blow up.

Not to paint too bleak a picture, there are certainly CAD power users who have the skills to create resilient CAD models. I’ve met more than a few of them: true professionals, who by combining experience, insight, and education, have earned the respect of their peers. They understand how to structure CAD models to avoid any problems with brittleness.

Nah. I’m just messing with you. Power users struggle with this just like us mere mortals. It’s just that their models don’t usually fall apart until you go outside the scope of parametric changes they had anticipated. Give power user’s carefully crafted CAD model to a user who has a black thumb (I’m sure someone comes to mind), and they’ll find ways to blow it up that the power user never imagined.

Next: The direct solution

The failed promise of parametric CAD part 1: From the beginning

By 28 Comments

The modern era of 3D CAD was born in September 1987, when Deere & Company bought the first two seats of Pro/Engineer, from the still new Parametric Technology Corporation. A couple of years later, Deere’s Jack Wiley was quoted in the Anderson Report, saying:

“Pro/ENGINEER is the best example I have seen to date of how solid modelers ought to work. The strength of the product is its mechanical features coupled with dimensional adjustability. The benefit of this combination is a much friendlier user interface plus an intelligent geometric database.”

According to Sam Geisberg, the founder of PTC:

“The goal is to create a system that would be flexible enough to encourage the engineer to easily consider a variety of designs. And the cost of making design changes ought to be as close to zero as possible. In addition, the traditional CAD/CAM software of the time unrealistically restricted low-cost changes to only the very front end of the design-engineering process.”

To say Pro/E was a success would be a terrible understatement. Within a few years PTC was winning major accounts from the old-line competitors. In 1992, on the strength of its product, PTC walked away with a 2,000 seat order from Caterpillar that Unigraphics had thought was in the bag.

The secret to Pro/E’s success was its parametric feature-based solid modeling approach to building 3D models. To companies such as Deere and Caterpillar, it offered a compelling vision. Imagine being able to build a virtual CAD model of an engine, and, by changing a few parameters, being able to alter its displacement, or even its number of cylinders. And even if that wasn’t achievable, it would be a great leap forward to just be able to rapidly create and explore design alternatives for parts and assemblies.

Yet, things were not that easy. In 1990, Steve Wolfe, one of the CAD industry’s most insightful observers, pointed out that Pro/E was incapable of making some seemingly simple parametric changes.

Pro/Engineer placed limits on the range of parameters. (A designer could not increase the dimension of L2 to point that L3 vanished.)
Pro/Engineer placed limits on the range of parameters. (A designer could not increase the dimension of L2 to point that L3 vanished.)

David Weisberg, editor of the Engineering Automation Report (and from whose book, The Engineering Design Revolution, I have liberally cribbed for this article), pointed out the fundamental problem with parametrics:

“The problem with a pure parametric design technique that is based upon regenerating the model from its history tree is that, as geometry is added, it is dependent upon geometry created earlier. This methodology has been described as a parent/child relationship, except that it can be many levels deep. If a parent level element is deleted or changed in certain ways it can have unexpected effects on child-level elements. In extreme cases (and sometimes in cases that were not particularly that extreme), the user was forced to totally recreate the model… Some people described designing with Pro/ENGINEER to be more similar to programming than to conventional engineering design.”

Weisberg barely scratches the surface of the issues that can create problems.

In 1991, Dr. Jami Shah wrote an Assessment of Features Technology, for Computer-Aided Design, a journal targeted to people doing research in the field of CAD. He identified that there were problems with features:

“There are no universally applicable methods for checking the validity of features. It is up to the person defining a feature to specify what is valid or invalid for a given feature. Typical checks that need to be done are: compatibility of parent/dependent features, limits on dimension, and inadvertent interference with other features. In a study for CAM-I, Shah et al. enumerated the following types of feature interactions:

  • interaction that makes a feature nonfunctional,
  • non-generic feature(s) obtained from two or more generic ones,
  • feature parameters rendered obsolete,
  • nonstandard topology,
  • feature deleted by subtraction of larger feature,
  • feature deleted by addition of larger feature.
  • open feature becomes closed,
  • inadvertent interactions from modifications.”

The important thing to notice here is that, not only are there multiple failure modes for features, there are also no universal methods for validating features. It’s left up to the user to figure out. And that process, as Weisberg hinted, is much too difficult.

Rebuild Error

Since the early days of Pro/E, a lot of work has been done, both by PTC and other companies in the CAD industry, to improve the reliability and usability of parametric feature-based CAD software. Yet, the problems that Weisberg and Shah identified still exist, and still get in the way of users being able to get the most from their software.

Next: The problem is editing.

 

CAD in the pursuit of art: Shane McKenna

By 2 Comments

As an engineer, I often think about CAD as a tool for the engineering and design of technological products. But, every once in a while, I’m reminded that CAD can can be used in ways its makers never anticipated.

Shane McKenna is an engineer, designer, craftsman, and artist. I recently talked to Shane about how he uses CAD/CAM in his work, and he, as an aside, shared some of his art. Here’s what he said:

I always turn my tools to artistic endeavors sooner or later. It occurred to me that I could create abstract art by modeling shapes and then playing with the lighting, rendering and camera angles. I have not had a much time to play with these ideas lately, but would like to get them into a gallery at some point. I am open to doing commissioned pieces until I have created a large enough body of work to approach some galleries. These are all done in Solidworks.

If you like Shane’s work, you can contact him by email, at twoartistic@gmail.com.

Tomorrow, I’ll be following up, and posting an article about how Shane uses CAD, CAM, and 3D scanning in his (more conventional) work.

 

SolidWorks 2014: No obvious surprises

By 5 Comments

Bernard Charles, explaining where SolidWorks fits in.
Bernard Charles, explaining where SolidWorks fits in.

There was a time, years back, when SolidWorks users complained because the annual updates of the software included so many major new capabilities that it was hard to keep up.

SolidWorks is a mature product now, and the pace of adding major new capabilities has slowed down quite a bit.

Now the big emphases with new SolidWorks releases are performance, stability, and quality. New capabilities are slanted towards making making existing users happy, and seem, at least to me, to have the common characteristic that they can be added without creating stability problems or regressions. SolidWorks 2013, for example, had a fairly good number of enhancements, but few, if any, of them appeared to be the type of things that that would have required making deep changes to the core of the software.

SolidWorks 2014, due to ship later this year, is likely to continue the trend, with a variety of relatively small enhancements, designed to please existing users. The new version was previewed at SolidWorks World last week. Rather than listing the new features here, I recommend checking out Ricky Jordan’s Blog, where he did a nice job of covering them.

Still, there is one new feature that I find quite interesting: the style spline. SolidWorks splines are not particularly well suited to creating class-A surfaces. Whether it was intentional, or a mistake made long ago, it’s been a problem for users who need high quality surface continuity. I’ve wondered how this could be fixed—my guess was that if the SolidWorks programmers changed the behavior of splines to fix their continuity, they’d introduce incompatibilities with older parts files. It looks like their answer was a good one: introduce a new class of spline specifically designed to give better control and smoothness.

It’s probably risky to predict anything about SolidWorks 2014, since it’s not due to ship for quite a while. But my completely subjective impression is that this may be another good release.

Speaking of future releases: I continue to dig to find information on future plans for SolidWorks. You may know that there’s been uncertainty and concerns among some users about whether Dassault Systemes might eventually “retire” the current SolidWorks generation. Here’s my reading: It’s not going to happen for a very long time.

I figure DS is about as likely to retire SolidWorks as Autodesk is to retire AutoCAD. Neither company is run by people who are dumb enough to kill off products that make them hundreds of millions of dollars a year.

 

Update: Vajrang Parvate, Director of SolidWorks Product Development, recently made this comment on the SolidWorks forum:

“We invested several man-years in changing some of the core components of the SolidWorks source code in SW2013 – the compiler, the VBA engine that drives macros and equations, the .NET version we run on, support for Windows 8… to name just a few. This was done across the product line – Core SolidWorks, Simulation, eDrawings, Routing, CircuitWorks, etc. and we are continuing to do those kind of long-term investments in the SolidWorks source code. SW2014 development is going on right now and our Product Definition and Product Management teams have begun initial planning for SW2015.

“I hope this says something about the longevity and the future of the products from SolidWorks you know and use today. Bottom line: They are not going away.”

It’s a nice reassurance that SolidWorks is going to be around for a long time. But, it begs a question: Doesn’t this kind of investment qualify as “making deep changes to the core of the software?”

No.  This work was certainly tedious and time consuming, but not “difficult,” in the sense that making major functional changes to SolidWorks would have been. It it was likely necessary to insure compatibility with the new versions of Microsoft’s development tools.

It’s hard to give SolidWorks major brownie points for doing something that every software developer who wants to support Windows 8 has to do.

Had Vajrang said that they’d invested the time and effort to add support for DirectX (as an alternative to OpenGL), I would have been impressed.

 

The deep secret of SolidWorks 2013

By 13 Comments

It’s been a few weeks since I was at the SolidWorks 2013 media event in Waltham, MA. There have since been several articles written about SolidWorks 2013, by Roopinder Tara, Brian McElyea, Anna Wood, Ricky Jordan, Matt Lombard, Randall Newton, and probably many more.

I already gave a preview of my observations about SolidWorks 2013, in the article Gian Paolo Bassi on SolidWorks 2013. Today, I’ll reveal more.

What I saw in SolidWorks 2013 were two distinct things. First was a focus on stability, reliability, and bug fixes. Second was a palette of enhancements that were either technically minor (not requiring tearing apart big chunks of existing code), made at the periphery of the software (not in its core), or added-on (through the API.)

Based not just on what I saw and heard at the media event, but also on comments from confidential sources, I’ve learned what appears to be the deep secret of SolidWorks 2013:

SolidWorks V1 (the current generation of product, which has been developed and sold for about 18 years) is being transitioned from active development to “maintenance mode.”

Now, before you get too excited, I’d like to point out that this doesn’t mean that the program has been abandoned, deprecated, or put on the back burner. It just means that the focus of development for V1 will be likely be bug fixes and improvements that can be made without creating regressions.

Think of the analogy of a building. SolidWorks V1 won’t be getting any new floors, and it’s unlikely that there will be any major demolition. They may move a wall here or there, but most renovation will be non-structural.

For many SolidWorks users who are essentially happy with the program, far from being a bad thing, this is probably a cause for celebration:  More reliability, many small functional and performance improvements, and no big disruptive changes to how the program operates.  What’s not to love?

DS SolidWorks Corp is exceptionally focused on their user community. While they stumble from time to time (as do all CAD vendors), there’s no way they’re going to abandon a half-million commercial SolidWorks users, and tell them “sorry, we’re not updating your program any more.” If they did that, it would kill their new product sales, but, just as bad, it would kill their revenue from subscription service contracts.

As a purely practical matter, SolidWorks 2013, 2014, 2015, and so on will need to provide enough value to existing users that they want to maintain their subscription service contracts in force. The management of DS SolidWorks recognizes this. There’s no chance they’re going to forget it.

One hint that they understand this can be found on the “jobs” page of the SolidWorks website. There are jobs open for software engineers in sketcher development and CAD assemblies. The descriptions make it pretty clear that these jobs are all about making SolidWorks V1 a better product: “Assist in removing limitations or to extend system capabilities.”

If you’re a SolidWorks user, I’d say it’s well worth looking at the 2013 release. It won’t be flashy, but it’ll help you get your job done better.

P.S. – You may wonder, what about the next generation “V6” SolidWorks products?  Yes, the developers at DS SolidWorks are hard at work on the next generation product line.  The first product in the line are scheduled to be out next year.  But it will be many years and many releases before the V6 generation products become functional and compatible enough to be a practical replacement for the existing V1 generation. My opinion is that you don’t need to worry about DS SolidWorks forcing you to transition from V1 to V6.

Dassault Systemes SolidWorks Corporation    www.solidworks.com

Gian Paolo Bassi on SolidWorks 2013

By 3 Comments

As much as I’m interested in what new capabilities SolidWorks 2013 will bring, I’m much more interested in something else: Has Dassault Systemes SolidWorks Corp invested the resources it will take to make it a really good release?

For a number of years, there’s been quite a bit of FUD surrounding SolidWorks. It’s been well-known that Dassault is working on a new generation of the program. And, among serious users, it’s been well-known that some versions of the current generation have suffered from quality (stability) problems. Given a variety of clues—from comments made by DS CEO Bernard Charles, to some high-profile defections of key people at SolidWorks—it’s not unreasonable for users to be concerned that, possibly, DS is more interested in developing the next-generation SolidWorks than in supporting the current generation SolidWorks.

SolidWorks 2013 has been in beta for a while, and today is the official product roll-out. In support of this, SolidWorks has invited a number of journalists and bloggers to its headquarters in Waltham, MA, for a grand unveiling. While the festivities have yet to begin today, last night they hosted a clambake, where the attendees could mingle with SolidWorks folks.

I got to the clambake just a bit late, and took a moment to scope out the room. There, chatting with Aaron Kelley (who manages the DraftSight product for SolidWorks) was the man I wanted to talk to: Gian Paolo Bassi, VP of R&D for SolidWorks.

So, I made a beeline, to ask Gian Paolo about SolidWorks 2013.

I didn’t want to know anything about what was new in SolidWorks 2013. I wanted to know how serious the company was in developing it. That is, whether they’d done it right.

My first question was about the team that worked on SolidWorks 2013. Did they put their best people on the project, or did they outsource the development, possibly to contractors in India? I sometimes wonder what people must think of me when I ask such aggressive questions, but Gian Paolo had no problem with it—possibly because he had a good answer. They did the work in-house, using their “A” team. And they actually added resources, to make sure it was done right. Further, they improved their QA processes. The result, according to Gian Paolo, is a version of SolidWorks that is more stable than any in recent memory.

Gian Paolo pointed out that the number of beta testers on this version of SolidWorks was far greater than on previous versions. I believe he said it was around 4,500 users. They held three events, where testers flew to Waltham, to beat-up and shake-down the software.

Beyond improvements in stability, SolidWorks 2013 includes about 350 enhancements. I imagine we’ll hear much more about those today.

I actually had a rather extensive conversation with Gian Paolo on the issues of quality and performance. I didn’t take notes; My intention was to see if he was really giving SolidWorks 2013 the attention it deserves, or if he was so focused on the next-generation product that he was giving 2013 short shrift.

Here’s my take away: the current generation of SolidWorks is being actively developed, and is getting serious attention. Even though Gian Paolo may be excited about the work he’s doing on the next-generation product, he’s still putting major resources behind the current-generation product.

If you’re a SolidWorks user, I’d recommend getting your hands on SolidWorks 2013, so you can put it through its paces. My bet is that this release will be a good one.

Hitting the reset button: Building the next generation of SolidWorks

By 14 Comments

Suppose you were a CAD developer, and you wanted to build a next-generation CAD system. How would you do it?

I’ve thought about that question for quite a while. Nearly 30 years, in fact. I’ve watched a bunch of attempts at building next-generation CAD systems. I’ve been involved in a few too. I can tell you this much: It’s not as easy as you think it is.

The folks at Dassault Systemes have also been thinking about it for quite a while. A few years ago, they previewed a new generation version of SolidWorks, called SolidWorks V6. They showed it in public one time, then shut up. And speculation about it has been rampant since.

Although I’m not a fan of the confusion that the name brings (See SolidWorks V6 is not SolidWorks), it’s possible that I might be a fan of the actual product, when it comes out.

Might. Because I’ve only seen one glimpse of it, and don’t know its details.

What DS has told us

Here’s what DS has been willing to say (or show), so far:

  • SolidWorks V6 is built on CATIA/ENOVIA V6 technology.
  • SoldWorks V6 uses the DS CGM (Convergence Geometric Modeler) kernel.
  • SolidWorks V6 can be delivered as a cloud application
  • SolidWorks V6 can run on Windows, OSX, or Linux
  • The team that is creating SolidWorks V6 is being headed up by Gian Paolo Bassi

These slim facts, though, are enough to provide some useful clues to with which to speculate on the nature of SolidWorks V6.

A few guesses on architecture

Let’s start with the CATIA/ENOVIA V6 technology: DS spent about $2 Billion to rebuild their V6 technology on a service oriented architecture (SOA.) You can read all about SOA on Wikipedia, but suffice it to say that it’s a good way of modularizing a CAD system, so you can deliver scalable capabilities and scalable performance.

With SOA, the back-end of the CAD system is delivered as a set of loosely coupled interoperable services, which can be run on a remote server or cluster, on a private or public cloud, or even locally, on your own computer.

One of the nice benefits of SOA is that, if implemented properly, and run in a virtual machine, the back-end services can run on top of nearly any operating system or hardware.

The front-end user interface (or client) for SolidWorks V6 could be built in any number of ways. DS has some impressive technology in its 3DVIA Studio (formerly Virtools) product. The 3DVIA Player, which is a browser plug-in, seems to be capable enough to be a CAD client. Yet, there are clues that DS may not be going this way.

The first clue is the inconsistency of platform support with 3DVIA Player. For example, there’s no 3DVIA player for Linux. And, while 3DVIA Mobile HD (which only supports static models) is available for the iPad, it’s not available for Android. And there is no 3DVIA Composer mobile player yet – despite DS having talked about publically two years ago. Take all this together, and it’s not hard to infer that it’d be difficult for DS to build a multi-platform CAD client using 3DVIA.

The second clue is that fat clients, such as 3DVIA Player, have fallen out of favor in recent years. Consider that Adobe has divested Flex and deprecated Flash. Microsoft has moved from Silverlight to Metro. Even Apple, long known for its proprietary proclivities, has become an HTML5 advocate.

A more modern approach to building a CAD client might be to use HTML5 and WebGL, in a compatible browser. You can see an example of this type of client in Tinkercad (or Sunglass.) While not nearly a competitor for SolidWorks (as a professional tool), Tinkercad does a nice job of demonstrating the feasibility of a browser-based CAD interface.

The important thing here is that the client front-end and services back-end in an SOA CAD system are logically separate, and can communicate using standard web services protocols. If a computer, tablet, or phone has the capability to run a sufficiently good browser, it can be used as a front-end for such a CAD system. If it has enough memory and computing power, it can be used to run the back-end. If it has both, it can run the entire CAD system. At that point, a modern SOA CAD system would be pretty much indistinguishable from a traditional desktop CAD system.

This, incidentally, is one of the slickest ways to get platform independence in a modern desktop application: Implement the front end in a browser, the back-end as services running in a virtual machine on the same computer, and use web services to connect the two. Using this technique, DS could theoretically deliver SolidWorks as a cloud-based SaaS (software as a service) app, as an enterprise network app (with a federated database), or as a standalone desktop app. All using the same code.

The modeling kernel

It’s no surprise that DS is planning to use CGM instead of Parasolid in SolidWorks V6. If they wanted to, they could actually use both, for backwards compatibility with SolidWorks V1 (that’s what they call the current version), though at an additional cost in licensing fees. (IronCAD, for example, uses both ACIS and Parasolid. And, though they don’t talk about it in public, DS almost certainly had internal test versions of SolidWorks running both ACIS and Parasolid many years ago. They would have been nuts not to, if only to cover their downside risk were their relationship with Siemens/Unigraphics to have soured.)

The real question with CGM is whether it will be compatible enough to Parasolid to provide 100% (not 99%) downward compatibility with SolidWorks V1. No one outside of DS’s development labs really knows the answer to that question.

Compatibility will come at one of two levels: Boundary representation (Brep), or feature-level.

CGM does support foundation-based tolerant modeling, so it should, in theory, be able to read Parasolid Breps accurately. But it’s not that simple.

Paul Stallings, VP of R&D for Kubotek pointed out the problem for me last year: “The most difficult problem with tolerances is not that one system uses one tolerance and another system uses another tolerance. The biggest problem is that some systems depend on curves in three dimensional space, and other systems depend on curves in the different two dimensional parameter space of the surfaces that they are on. The mis-match between parameter space and three dimensional space is a very big problem with ACIS and Parasolid using three dimensional space and Catia and ProE using parameter space.”

There are other problems on top of this. Parasolid and CGM likely define topology and geometry in different ways. Even seemingly simple shapes such as cylinders and spheres can be represented and parameterized differently. (I understand that CATIA represents cylinders as two half-cylinders.) Advanced procedural surfaces can involve many undocumented, cryptic, or even unimplemented options. When these surfaces are near-tangent to neighboring NURBS surfaces, fitting can be very difficult. And then there are problems with multiple flipping flags, for faces, edges, and curves. If you get one of them wrong, all is lost.

Still, DS has had some of their best people working on CGM for a long time. Their Spatial division has a really good understanding of Parasolid (they support it in their 3D InterOp data exchange products.) So, I give DS the benefit of the doubt, that they can work through any CGM/Parasolid Brep interoperability problems. At least to the 99% level. For the last 1%, technologies exist, such as Capvidia’s CompareWorks, which 100% validate translated model integrity.

Feature-level interoperability between SolidWorks V6 and SolidWorks V1 may be a shakier proposition. It depends on whether, given a feature’s recipe as an input, CGM is capable of generating the same exact same result as Parasolid.

Consider blending (or filleting.) Blending functions in CAD systems, no matter what kernel they’re based on, are often unpredictable, counter-intuitive, and prone to failure. No vendor—not Siemens, not DS, not PTC, and not Autodesk—has “solved” blending. Here are a few examples of Parasold blending problems:

Parasolid blends

CGM will have its own blending problems, but it’s unlikely that they’ll be the exact same ones that Parasolid has. SolidWorks users are a hardy bunch, and have spent the last 17 years or so finding ways to work around strange blending behavior. So, even if CGM is actually technically better at blending than Parasolid, it could create problems when users are actually relying on getting identical results.

The important question may be: does it really matter?

If SolidWorks V6 doesn’t have feature-level compatibility with SoldWorks V1, it’ll be in good company. No other CAD system does either. Unless the two products are used in an iterative workflow, it’s likely that Brep level compatibility will suffice. And, while SolidWorks V1 doesn’t have advanced direct modeling tools for editing dumb Breps, that’s no reason to assume that SolidWorks V6 won’t. In fact, DS does have interesting direct modeling technology in CATIA V6. It would make sense that it might show up in SolidWorks V6. If that happens, SolidWorks V6 users may be able to import and reparamaterize SolidWorks V1 models. That opens up interesting possibilities.

Not just another CAD new system

So far, everything I’ve been talking about with respect to SolidWorks V6 is speculation, based on the small amount of information that DS has let out about the product. And this last bit is speculation too.

Gian Paolo Bassi, who is in charge of developing SolidWorks V6, is not a stranger to people in the CAD industry. If you check his patents, you’ll find that he’s one of the inventors of functional modeling. While I’m not going to explain functional modeling here, I will say that it’s a step beyond traditional feature-based modeling.

My guess is that DS wouldn’t have put Gian Paolo in charge of the SolidWorks V6 team if they were planning a me-too product.

In total, I’m guessing that SolidWorks V6 is going to be a really interesting product, but, at the same time, it’s going to be a very different product from SolidWorks V1. Giving up one for the other probably won’t make sense for quite a while.

User concerns

Over the last couple of years, I’ve watched a number of forums and  blogs, where users—often smart and experienced users—have expressed serious concerns about SolidWorks V6.

The concerns seem to come in several areas: compatibility with SolidWorks V1, cloud hosting (particularly of data), and SaaS licensing.

The compatibility issue is a technical issue driven by a business need. The choice of CGM over Parasolid is a strategic decision for DS. It doesn’t make business sense for DS to build a next major generation product on a competitor’s core technology. It’s true that this choice is going to impact users. The question that can’t be answered is how effectively DS will be able to minimize the impact.

But the other issues—cloud hosting and SaaS licensing—aren’t even technical issues. They’re business issues driven by technical capabilities. If Gian Paolo Bassi and his team build the V6 product right, it will open up the option of cloud hosting and SaaS licensing. It won’t close down the possibility of the software running on the desktop, with standard perpetual licensing.

Over the last few years, I’ve seen a lot of concern about the performance, reliability and security of cloud hosting, with respect to SolidWorks V6. They’re legitimate concerns—but they’re not inherent to SolidWorks V6. Consider this example: You can run the MySQL database or Apache web server on a cloud. Or you can run them right on your own computer. It’s your choice. You never see anyone fretting about their reliability, because experienced people recognize that the programs themselves are rock solid, and it’s the choice of hosting environment that can create issues.

The issues of performance, reliability, and security are key for SolidWorks V6. But, guess what? The core technology underlying SolidWorks V6 is already proven in CATIA V6. DS spent a couple of billion dollars to make sure it was up to the task. Now the question becomes one of hosting environment. That’s not a technical issue. It’s a business issue.

Business issues

I certainly have technical concerns about SolidWorks V6. But my biggest concerns have to do with business issues. Even if they get the product right, business decisions DS makes about deployment and licensing could create big problems.

To understand why this is an issue, you have to look at the shift in how DS has managed SolidWorks (the company) over time. Up until about 5 years ago, they pretty much left SolidWorks alone. Many SolidWorks users didn’t even know that the company was owned by DS. But, starting in about 2007, that began to change. Today, SolidWorks is very much a part of DS. While many of the same people are there, it’s become clear that the company’s strategy is driven by the DS executive committee, in France.

In the past, SolidWorks management was exceptionally open and transparent in their communications (at least, compared to most other big CAD companies.) Over time, SolidWorks management earned their users’ trust.

DS management, however, has a reputation for being notoriously tight-lipped when it comes to talking about anything they perceive might weaken their competitive advantage. It seems to be cultural, possibly born out of competing for the largest aerospace and automotive accounts.

To the extent that DS retains that tight-lipped tendency when engaging with SolidWorks users, it may not serve them well.  DS top management, particularly the people driving strategy, haven’t paid their dues, and earned SolidWorks users’ trust.

There are a million plus existing SolidWorks users, and many of them seem to be imagining the worst possible scenarios about SolidWorks V6.

While in many cases, FUD (fear, uncertainty, and doubt) are sewn by competitors, in this case, the FUD comes, in part, from DS’s reticence to reassure users that SolidWorks V6 is going to be a good thing (and not a tool to lock them in and bleed them dry), and, in part, from users’ legitimate concern that DS might be losing interest in SolidWorks V1.

SolidWorks 2013

It’s possible that the best answer for the concerns of existing SolidWorks customers will be in SolidWorks 2013. To the extent that the new release improves stability, and adds significant value over the previous version, users may be willing to relax their concerns that DS might be losing interest in the existing SolidWorks product line.

While the 2013 product is now in beta, SolidWorks will be officially launching it in September. I understand that they’ll be sharing their product roadmap at that time. This may be SolidWorks CEO Bertrand Sicot’s best chance to quiet the concerns, and build anticipation about SolidWorks V6—a product that could ultimately turn out to be a truly great next-gen CAD system.

Cloud CAD is really difficult

By 26 Comments

If you believe the buzz in the blogosphere, there are a lot of engineers and designers who are not at all happy at the prospect of some day being forced to use cloud-based CAD.

The public lashback on cloud CAD started building several years ago, and it’s hardly abated since. The conversation has taken on political/religious overtones.

In the best of all worlds, clould CAD could be a revolutionary tool, allowing people to work where, when, and with whom they desire. The troika of cloud, mobile, and social offer intriguing possibilities.

Yet, there are potential problems with cloud CAD, at multiple levels.

The issues are substantial enough that it’s not practical to address them all at once. So, with this article, I’ll dig into with just one issue: the difficulty in actually creating a cloud CAD program.

CAD is difficult

CAD, even without being cloud-based, is difficult to create. Mike Riddle, one of the best known CAD architects, estimates that CAD is about an order of magnitude more complex than typical Office type applications. He ‘s not talking about lines of code (though CAD programs do clock-in with tens of millions of lines of code.) Rather, he’s referring to the Chess-like complexity and difficulty of creating a CAD program that can actually model the things that its users want to model.

Understanding CAD architecture

CAD programs are built up out of a large number of software components. Some, such as geometric modeling kernels, constraint managers, graphics pipelines, and translators, are developed by fairly well-known companies, and licensed to a large number of CAD developers. Other components, such as those for manipulating raster images, zip files, or unicode characters, are available through open-source repositories, such as SourceForge. Many more components are created by CAD developers themselves.

The real magic in creating a CAD program comes in how the software compenents are arranged and connected. This is the essence of software architecture. It is largely what distinguishes great programs from lousy programs.

Once the architecture for a CAD program has been set, it can be really difficult to change.

Consider, for example, how CAD programs, almost as a rule, seem to take very poor advantage of multi-core processors. This isn’t because the CAD vendors (and the programmers who work for them) don’t want to provide good multi-core support. It’s because the architecture of their software, and of the component libraries which comprise their applications (particularly the geometric modeling kernel, if we want to point fingers) were not initially designed to support concurrency (the underlying requirement to support multi-core processors.)

Though CAD vendors could rip their software down to the ground, and re-architect it to support concurrency, it’s not so easy as just putting a team of programmers on it, and giving them a budget for coffee and Red Bull.

CAD software architectures generally creep, in an organic fashion, from release to release. Initial versions of CAD programs are often architecturally consistent because they are created by small development teams comprised of very experienced CAD programmers. Yet, over time, demands to add new features and capabilities on too-short schedules, and the addition of more programmers to development teams, can lead to hacks which compromise the architectural integrity of later versions of the software.

The result can be a CAD program that works pretty well in most cases, but which has persistent instabilities that can’t be easily fixed—either because no one actually completely understands the CAD program’s architecture, or the instability has become “baked into” the architecture. (Not to point fingers, but there are a number of well-known CAD programs which suffer from persistent instability.)

For a CEO of a CAD software company, the prospect of embarking on a re-architecture project has got to be chilling. Too many of these projects (the most infamous being AutoCAD Release 13) end up being expensive disasters.

Cloud CAD architecture

There are two ways to approach cloud CAD. One way is to use an existing desktop (e.g., Windows, OSX, or Linux based) CAD program, and run it, mostly unchanged, on virtualized servers. This is the approach that companies such as Citrix and CloudSwitch enable—and it’s nothing new. The other way is to build a CAD architecture that’s optimized for use on the cloud.

An optimal cloud CAD architecture would support scalability, both in the number of concurrent users, and in the size of CAD models. That means, essentially, breaking the CAD software down in to a number of interoperable services, which can run concurrently on multiple loosely-coupled server instances.

The problem that CAD developers run into is that, even though their existing desktop CAD systems are built from a large number of software components, those components were never designed to work in a loosely-coupled environment, and they were not, except in rare cases, designed to support concurrency. It’s simply not practical to take an existing CAD program, break it down to its components, then use those to build a cloud CAD system.

The only practical way to build a scalable cloud-based CAD system is to start from scratch, with a new architecture. While some components from existing CAD systems may be reusable as is, most are not.

Where are the cloud CAD programs?

The buzz about cloud CAD started in early 2010, with DS SolidWorks Corp previewing the cloud-based SolidWorks V6 at their user conference, and Autodesk opening up Project Butterfly, a cloud-based CAD application, on their Autodesk Labs site.

SolidWorks V6, despite its name, is built on the Dassault Systems V6 platform. It won’t be available until 2013, at the earliest, and even then, it won’t be entirely compatible with today’s SolidWorks program (because, among other reasons, it will be using a different geometric modeling kernel—one that’s quite different from the Parasolid kernel used in SolidWorks for the last 17 years.) SolidWorks V6 will be a functionally different program than SolidWorks.

AutoCAD WS, the released version of Project Butterfly, is the only notable cloud CAD application currently available. Despite its name, it’s not based on AutoCAD. It’s based on technology developed by PlanPlatform, a company acquired by Autodesk in 2009. While it does read and write AutoCAD compatible DWG files, AutoCAD WS is not a functional match to AutoCAD.

What of the other cloud CAD products?

There are none that are notable. (Or, rather, I don’t know of any that are particularly notable. I expect someone will send me straight on this if I’m wrong.)

While it’s possible that Siemens PLM or PTC have secret projects to develop cloud-based CAD programs, it’s likely that, if they do, those programs won’t be a functional match to their existing desktop CAD programs. Just like DS SolidWorks and Autodesk, they’ll need to start from scratch with cloud-based CAD.

Desktop CAD is here to stay

There are many CAD-related things you can do well on the cloud, including storage, rendering, CAE, and collaborative markup. But CAD itself? It’s easier to say than to do.

Cloud CAD is really difficult, if you want to do it right. As much as CAD company CEOs might like to talk about their visions of the future, they know that cloud CAD won’t replace desktop CAD for a very long time, if ever.