Bill Fane moderated a recent discussion titled “Cad Smackdown – Direct vs. Parametric Modeling”, that, as he put it, was not intended as a debate of one’s benefit over the other, but a realistic discussion of the two paradigms as a whole. There was very little pitting capabilities of platforms against each other, and did prove to be an overall discussion of the two platforms and industry concerns. Unfortunately, the conversation was not designed to produce a result, and as such did not, however a few interesting points were brought up, and I’ll comment these and offer some perspective on design and the future.
Those that were on the panel were:
Bill Fane, Cadalyst contributing editor “We’ve gotten so hung up on the design tools rather than some of the design processes …”
• John Buchowski, vice president, Creo product development, PTC
• Ben Eadie, blogger and SolidWorks instructor, UsingSolidWorks.com “we’re trying to focus on whether it’s parametric or non-parametric, why not focus on what tools they need to get the job done?”
• John McCullough, vice president, product management, Kubotek “the direct modeling approach is really about centering a lot of the technology around the geometry”
• Mike Payne, co-founder of SpaceClaim, SolidWorks and PTC ”we’ve all got short attention spans, and we need systems that work the way we think …”
• Dan Staples, director of Solid Edge product development, Siemens PLM Software
• Carl White, director, digital design product management, Autodesk
(Unfortunately, little was done to identify certain individuals during the discussion, making it difficult to pinpoint who said certain things)
The Cadalyst discussion was significantly better than most in the sense that no one was trying to say this method is better than that, but instead discussed limitations more than anything, and I think that is the reality of the situation.
I agree with Mike Payne, who mentioned that the decision of which workflow to follow is really ‘the choice of the right tool for the right job’. In that sense, with today’s capabilities, these represent two different paths that don’t integrate well. While most of us logically conclude that our future should be built on a technology that merges the two, there is currently no realistic vehicle in which to do that. However it is my contention that the future will hold continuously changing concepts in design technology for all of us. There is no way we can say what the future will be. What we can do is to look as far into how we COULD do things, how we would approach those actions, what would be required, and what are our current limitations.
Entirely new systems are usually required to be implemented for such change, but we can’t develop them due to numerous factors:
- We can’t stop development and production in order to completely alter the manner in which we get things done
- We can’t develop a new system it on the side because of the independent costs and lack of return associated with a new technology
- For whom shall the technology be considered and leveraged?
- The longer we develop a product, the better it will be, and the more costly it becomes.
- The longer we wait to bring the technology to the user, the less relevant those benefits become.
Parameters and Design Intent
Until a new design paradigm is developed, Parameters are here to stay. The ability to develop a set of core values that are the basis for numerous important relationships within the design is paramount in most designs. Payne mentioned the ‘misuse’ of the term ‘Design Intent’, originally coined to indicate that a final product was designed to function a certain way. “A telephone was designed to fit into your hand”, Payne noted, and went on to describe how the industry has misused the term, and assigned it to parameters. I disagree (I’m one of the avid mis-users).
The intent of the device prompted feature relationships to be established to accomplish the goal. The design will not work if any of those relationships are overlooked. The term is not misused, but simply carried farther that originally intended. That’s the problem with new ideas, isn’t it. I contend that design intent is not ‘parameters’ as Mike indicated, but is the intended relationship between key parameters, features, and the final product. Based on these relationships, a seasoned user can understand the manner in which things were accomplished, and as such will not blindly ignore inherent limitations while adapting an existing design.
Designed for Engineers
The discussion went so far as to discuss the relationship of workflows of both Engineers and Designers, and that each should be taken into consideration. Their daily tasks require different tool and workflows, and as such, their tools need to be designed differently. The discussions touched on the lack of need for the designer as more engineers become active in the design technology, and how some people need all aspects of design technology.
Either innovate, Adapt, or Die. I deal with numerous Designers that perform all the same tasks, from concept to completed plans, and simply refer to engineers to validate and QA. I believe we will see less separation between Engineer and Designer. I do not personally think we need tools designed just for one or the other. I think the challenge should be to incorporate these functionalities into the design software, and BIAS the workflows as a function of the software to suit any particular way of operating, thinking, etc. In this manner the same tools are more useful to everyone. I think that this is an important feature, and part of our future.
Design a new platform
Ben Eadie was involved in some discussion that led his statement to the effect that we need to remove the boundaries separating design tool functionality, and start anew with no preconceived notions about how the tools should work. It’s a pretty cool thought, but that leaves us with a paradox that is not exactly new:
If I want a radically new design in modeling technology, with no preconceived notions about how it should function, and ask an engineer and a non-engineer, I will get two different results:
The Engineer will already have pre-conceived notions that have been conditioned into his mind, based on the limitations of his everyday life.
The non-engineering person (who has no clue about how things are manufactured), will create something that likely cannot be used in the manufacturing workplace.
It won’t work one way or the other, but has to be a merger of the two. That is where usability comes in.
Usability and Autodesk Inventor Fusion
I have always been a big fan of the efforts of Usability teams, and have watched their tests with fascination, knowing from experience that I’d soon see various concepts implemented in new product cycles. Carl White mentioned Autodesk Inventor Fusion, which I think is a great example of this. It is an innovation, that has evolved through testing and usability, where concern for current methodologies are not a hindrance. It is a test bed for new workflows in direct modeling, as well as user behavior within an independent technology.
I agree that we need systems that work the way we think. One problem is that we develop a system surrounded by technological limitations, and condition our habits to efficiently operate in those limitations. As a result, humans are typically near sighted, and resistant to changes . This parallels the problem that we have been plagued with: Historically the changes that were perceived as a future and benefit were built onto an existing system without enough vision to foresee the problems it would create. The result is constant alterations that run innovation into the ground.
Since Fusion began without the full functionality of a market ready tool, I had difficulty envisioning exactly how it would evolve. It’s function is not necessarily to be developed into a particular tool, but instead to approach design from a different perspective, and evaluate potential innovations through a separate process that is not limited by a production timeline or feasibility. The benefits discovered in the Fusion path can then be handed over to Autodesk Inventor without the train wreck of limited vision. Thus Fusion is not a production tool in development, it is a new and separate path that is steering existing product technology.
Direct modeling and History based Parametric design environments do not coexist to any substantial extent in technology today. Some applications offer methods to incorporate features from one into the other, but it is still a burden that many would choose to avoid.
I’m not opposed to a radically new paradigm, and I think many of us that openly discuss these things, are looking forward to the innovators and opportunities that the software developers are enabling. I offer Spaceclaim and Fusion as two such examples.
I argue not that these innovations need to have parametric relationships, but that they incorporate something that delivers a better avenue than the one that we had before. Trade-offs are not even worth discussing. Additionally,treating parametric design and Direct modeling as two separate workflows (as some mentioned) is not the future. It is an anchor to what we have right now.
We are all ready for a new approach that delivers a better way of thinking about design as a whole, with a flexible interface that can be biased towards what work is needed in any situation. Direct modeling is only one piece in a very large puzzle that can only be solved with a new level of thinking.
The Cadalyst Edge Parametric vs. Direct Modeling Discussion