3D ANZ
CAD Thinking
Stop Looking for the Mythical Perfect CAD System.
Start looking for the tools that don’t get in your way.
Lessons learned from a lifetime in CAD.
Explained in Plain English
© 2026 Tim Elliot. All rights reserved.
Design and drawing are not quite the same ambition.
When did CAD stop meaning drawing?
There is a small historical argument hiding inside the initials CAD. They have been used for both Computer Aided Drafting and Computer Aided Design.
Drafting is principally about communicating a design: producing drawings, dimensions, annotations and documentation. Design is the larger activity: deciding what something should be, how it should work, how its form should develop and how its components should relate.
The distinction matters because early computer graphics were very good at demonstrating that a machine could draw. The Computer History Museum describes early CAD as essentially a better drafting tool before it became a way of modelling complex surfaces.[1]
I encountered the distinction first-hand while editing CAD magazines in London. One publication deliberately explored CAD&D - or CADD - because it acknowledged both sides of what the technology was doing.
The model can remember how it was made.
How does history-based modelling work?
Some design software remembers a model as a sequence of operations. You might create a sketch, turn it into a three-dimensional form, round an edge, add a hole and then repeat that feature elsewhere. Each step can depend on something that came before it.
CAD users commonly describe this collection of operations and relationships as a history tree. Think of it as a recipe: the computer remembers not just the finished cake, but how you made it.
History-based parametric modelling can be extremely powerful because dimensions and relationships can make later changes predictable. Those relationships also create dependencies: changing one decision can affect many later operations.
When does history become a needle in a haystack?
You need to change something that looks simple. You search for the step that created it, then discover that the step depends on something earlier—and that operation depends on another one.
Suddenly the innocent little boss you wanted to move has acquired a family tree worthy of a medieval dynasty.
Sometimes that structure is exactly what you need. Sometimes it is not. The model may not have malfunctioned; it may simply have followed its instructions. The problem is that the designer's mental model and the software's dependency model can drift apart.
And then you have a choice: find the historical cause, or fix the geometry.
A practical origin can become a design philosophy.
Was the history tree originally about design intent?
A documented CAD updating method describes an approach used by some systems in the early 1980s: replay the modelling operations instead of storing all the intermediate results.
Replay the history. Save the memory.
The trade-off was computation. Replaying the history after a change meant rebuilding the model from its sequence of operations, so the time required could depend on the complexity of the whole part rather than only the size of the change.[2]
That is different from the polished modern description of a history tree as an elegant representation of design intent. Yet something clever happened: the sequence was useful not only for rebuilding the shape. It also contained information about how the designer had constructed it.
As systems became more sophisticated, procedural history became editable, associative and increasingly rich in dimensions, relationships and features. A computationally economical way of reconstructing a model became something more ambitious: a representation of design intent.
Architecture reflects the environment in which it evolves.
Would we build CAD this way if we started again today?
It would be tempting to tell a neat story: computers were too weak for direct modelling, so engineers invented history-based modelling. The evidence does not justify something quite that simple.
Solid modelling developed through different approaches. Modern academic accounts commonly describe the progression as solid modelling in the 1970s, parametric modelling in the late 1980s and direct modelling as a later commercial paradigm. Constructive Solid Geometry and boundary representation were already established within early solid modelling.[3]
CAD architecture evolved in a particular technological environment, and that environment influenced what was practical, valuable and expected.
Then the technology improved. The architecture remained. Eventually, a solution to a particular set of problems can start to look like the natural way computers ought to work.
So what does Rhino do differently?
Rhino takes a more direct approach to an object's shape. Rather than requiring every change to pass through a long chain of dependent modelling steps, you can often work directly on the geometry in front of you. This is generally called direct modelling.
That does not mean Rhino has no History. It does. McNeel describes Rhino History as storing the connection between a command's input geometry and its result, allowing changes to the input to update the result. McNeel recommends selectively recording History when it is useful, noting that it consumes resources and increases saved-file size.[4]
If a relationship needs to persist, use it. If it does not, Rhino need not carry that relationship with the geometry. Rhino's training material is explicit that History is not the same as a feature or parametric modelling system.[5]
Three legitimate approaches. Three different questions.
Where should the design intelligence live?
History-based
How should this design behave when it changes?
Direct
What should the geometry be?
Generative
What rules should generate the geometry?
Freedom and structure solve different problems.
Where does Rhino really win—and where does it not?
Rhino's great strength is freedom to work directly with complex geometry, including the NURBS curves and surfaces for which it is well known. That matters when the form itself is the problem you are trying to solve.
You may not know the final design when you start. You may want to explore radically different solutions or decide that the original modelling approach was wrong. Working directly with the shape can be liberating: you can ask “What should this be?” rather than “Which earlier operation must I change to make it become that?”
That freedom also brings responsibility. If a relationship is important, it must be preserved deliberately. If a dimension must remain fixed, the model must express that. If another designer will inherit the file, your intentions must be understandable.
Direct modelling does not eliminate design intent. It simply does not automatically encode all of it for you.
A history-driven system can make future engineering changes wonderfully predictable. Rhino can make exploration and geometric intervention wonderfully uncomplicated. Neither wins every contest.
When rules become geometry.
What happens when the rules become the design?
This is where Grasshopper enters the story. It is a visual environment within Rhino for creating rules and relationships that generate or control geometry.
It can be extraordinarily powerful for repeated structures, complex patterns, optimisation and generative work. But there is a trap: you can spend an impressive amount of time automating something that would have taken five minutes to model directly.
Different problems benefit from different ways of thinking.
Why might the best CAD toolkit contain several systems?
The modern workflow need not be “choose one CAD system and use it for everything.” It can be “choose the right tool for each part of the problem, then make the tools cooperate.”
A designer might use a history-based solid modeller for mechanically critical components, Rhino for complex curves and surfaces, Grasshopper for generative work, and specialist applications for rendering, simulation or manufacturing.
This is not a failure to find the mythical application that does everything. It reflects the fact that different problems ask different questions.
Deep knowledge of one system is valuable. So is knowing when a different problem calls for a different tool. That is why interoperability matters: the aim is not merely to move a file, but to allow people, skills and tools to contribute without software becoming an unnecessary barrier.
What does a lifetime in CAD teach about certainty?
I have worked with computer-aided design since 1983. That gives me the dubious privilege of watching several generations of CAD orthodoxy arrive, become fashionable and occasionally become inconvenient.
When company directors first asked why we were not using computers, I laughed and persuaded them not to take that revolutionary step. I was wrong. I had judged a technology I had not bothered to understand. The company later went bust. It was an effective education in the danger of certainty.
Years later, after selling my AutoCAD reseller business, Bob McNeel suggested I talk to CoCreate. I subsequently worked with SolidDesigner 6 in Germany as the industry wrestled with the transition from workstations to the Windows desktop. By 1998 it supported Windows NT, HP-UX and SGI IRIX.[6]
I returned to England and organised SolidModelling '99, and I have continued working with Rhino from its early years. That experience has made me wary of treating any current orthodoxy as permanent.
Ask what the design needs.
Stop looking for the perfect CAD system.
History-based, direct and generative systems ask legitimate but different questions. The skill is knowing which question you are trying to answer—and where the intelligence that describes the design should live.
Sometimes the answer is a history. Sometimes it is the geometry itself. Sometimes it is a set of rules. Increasingly, it may be several applications working together.
The purpose of design software is not to make us admire the software. It is to help solve a design problem with the least unnecessary resistance.
And sometimes, after twenty minutes searching through a history for the operation responsible for the tiny boss you wanted to move, you discover that changing it will destroy half the model.
Delete the bloody thing and remodel it.
There is no shame in that. Your computer will not judge you. And if it does, do not tell the grandchildren.
References
- Computer History Museum, Computer-Aided Design. Historical overview of CAD's evolution from drafting towards complex surface modelling. Source
- Dassault Systèmes, European Patent EP2474930A1, Updating a modeled object. The document describes replaying history operations to avoid storing intermediate results and states that some CAD systems used this method in the early 1980s. Source
- Zou, Q., Feng, H.-S. & Gao, S. (2023), Variational Direct Modeling: A Framework Towards Integration of Parametric Modeling and Direct Modeling in CAD, Computer-Aided Design, 157, 103465. Source
- McNeel & Associates, Rhino 9 Help—History. Official documentation on History recording, resource use, file size and selective recording. Source
- McNeel & Associates, Rhino Level 2 Training—Modeling with History. Official material explaining that Rhino History is not a feature or parametric modelling system. Source
- Contemporary 1998 reporting on CoCreate SolidDesigner 6.0, including Windows NT, HP-UX and SGI IRIX support. Source
Bring it in. Work with it. Take it wherever it needs to go.
Cage
Taper
Twist
Maelstrom
Stretch
Splop
CageEdit
Flow
Bend
