3 Levels of CAD quality, and when to use them.
3 Levels of CAD quality, and when to use them.
Intro 00:00
Parametric CAD is incredible, a thoughtfully made model can update dramatically in just a few clicks, all while maintaining your design intent, which is awesome. But what if you don't have a clear design intent yet? Well, in that case, many of the so called Best Practices that you're following may actually just be slowing you down.
For every model and every stage of a project, there's an appropriate balance between the speed at which you're working and the amount of rigor that you apply to your model. And if you get it wrong, you're going to be wasting time. I'm going to show you in this video how we at Ovyl determine what the right level is for any particular moment in a project and how we communicate about it as a team. We do our work in Onshape. But this concept does not have any specific software that it applies to. If you're working in any parametric CAD system, Creo, Fusion 360, SolidWorks, Inventor or something else, this is going to apply equally well.
I'm Evan, a partner at the device development for Ovyl, let's get to it.
What's an ideal model? 00:56
Well, first off, what do I mean by Rigor, the best way to explain it is probably to start by imagining an idyllic perfect model that embodies all best practices that you've ever heard of. This model would update without breaking when you change something pretty fundamental. And this model, it would be organized well enough that if you got hit by a bus, then your team could come in and pick up where you left off. And it's fast enough to rebuild that you're not spending half your time at your desk twiddling your thumbs. In other words, the model would be really robust to change, navigable by guests and lightweight to compute. Those are the three elements that make an excellent model.
Nokabox model tour 01:36
We happen to have plenty of models that are an excellent example of that level of Rigor here at Ovyl. For example, the model that we made when we designed the Nokabox, which was a pill organizer that you might actually like to be seen using there for sale, there's a link in the description, go buy one. But let's take a look at that model.
At least three people collaborated on this model. But it was pretty seamless, because we took the time to name our features sensibly and put them in a reasonable order, and just generally added navigability to the model, because we know that we're not the only person that's going to be working in this space.
This model is also pretty lightweight, it comes in at around 6 seconds for the whole thing. But the heaviest features by far are the logos which are imported from DXFs which splits it up into tiny lines, anyway, it drives the rebuild time up. So we just worked with those in a suppressed state during development. And this model is also extremely robust to change that was the whole idea going into it, we intended from the very beginning to make this a configurable model so that we could get multiple products from just this one CAD model. So we have a small once a day and a small AM PM. And then large and large of both of those. And if this client, for example, wanted to extend their product line and introduce a super duper, ultra ridiculous size, it wouldn't be that hard for us to do on the CAD side like so. Or if some new supplement came out and hit the market that was really popular, and it was a little bit bigger than what we designed this one for, it wouldn't be very hard for us to modify the model to accommodate that, in fact, this model was designed from the pill outward. So our top level driving variables are actually the sizes of the pills. And if we just change that everything else will rebuild accordingly.
How to speed up 03:31
So I'm going to give this model an A [phonetic 03:24] on all three categories. It's robust to change, it is navigable, and it's lightweight to compute.
However, making all those things happen takes time and attention, which is why there's a fourth indicator of good CAD work. It's quick, it doesn't take forever to do, making a model more robust, navigable and lightweight usually comes at the expense of modeling speed. And on the flip side, speeding up will usually lead to a messier model. So I would call this the speed rigor continuum. And for any part of a project, you're somewhere along that whether you know it or not.
Now, a novice user would probably be pretty low on all four elements. And they'll take a week to make a model that breaks if you look at it funny and you know, the rebuild time is atrocious, and so forth. And that's why practice and learning are so important. Because if you watch tutorials and learn hotkeys, and keep experimenting with your workflow, you can actually get faster with no penalty to any of the other elements of good CAD work. In fact, those will improve as well. But there's a point of diminishing returns with that method of speeding up. At some point more learning just doesn't get you much faster. If you need to speed up you have to start playing with the balance between these things.
Technical debt 04:43
Software developers understand the concept of Technical Debt. Technical Debt is what you get when you make something that's quick to do today by cutting corners and you know that in the future, you're going to have to come back and clean it up. And when you have come back and cleaned it up, you'll end up essentially paying interest on your debt because it's more work than just doing it right the first time. So why not just do it right the first time. Just like real debt, Technical Debt can, when used appropriately help you get more done with less upfront investment. But the trick is to know when it's helping you, and when it's hurting you more on that later.
Collaboration and the 3 Levels of CAD 05:19
At Ovyl, we place a very high value on our team's ability to tightly collaborate. In fact, one of our core values here is harmony over virtuosity, which essentially means that we believe a well coordinated team can be way more powerful than an uncoordinated team of superstars. In order to stay coordinated as a team about what level of Rigor we are at, at any given point, we have actually taken this spectrum idea and split it into three different steps. So we have Level 1 CAD, which we use for Exploration, Level 2 CAD, which we use for Iteration and Level 3 CAD is that idyllic Production CAD. The reason that we've done that is essentially just to make it more conversationally, wieldy. So instead of saying, I'm going to be 73% rigorous at this point, we would just say that you're at a high Level 2, or something like that. So it makes it easier to talk about which is worth the loss of nuance. If you ask me.
Level 1: Exploration 06:16
Level 1: Exploration is all about searching for design intent you're exploring, you're trying out a bunch of different ideas and trying to find the ones that are going to stick. So that means you're going to have a lot of false starts, you're going to work do a lot of work that you end up not wanting to incorporate into your final design. And you're generally- you're like doing thumbnail sketches before you do your master work. So none of that is the master work itself, you're going to throw it out or file it away somewhere at the end. So to that end, it's all about speed with a complete disregard for the future of that model, or who might want to work on it. So yes, blue is in our sketches. And our features are not named organized. And our references are really unstable, because we just grabbed whatever was convenient at the time, instead of scrolling up the feature tree to grab a plane or something like that. We're just hacking it together as long as it's fast. And then when we're done with that, and it's yielded some kind of design direction, it's time to declare bankruptcy to strain that Technical Debt analogy a bit and scrap it, we're starting over. If you don't do that, and you intend to continue to massage the model all the way until it's a nice perfect production model, what can happen is you find yourself at the end of a project, and either needing to start over desperately, quickly then or just limping by with a model that's really unwieldy. And it's sort of a trap of your own making. So don't do that, plan ahead for it and do it on your own terms.
Level 2: Iteration 07:39
Let's move on to level two. Level 2 is for iterating on your found design intent. So once you have design intent, you should be working in level two. And it doesn't mean that all of your exploration is totally over. But it's not just this open ended blue sky exploration like it is with level one. So at this point, that's usually when our team begins to collaborate on the same models together and navigability starts to matter a lot more.
At this point, we'll also be naming features making more stable references, especially the ones that are easy to make. So reference the origins and the cardinal planes as much as possible. And don't just grab fiddly little edges and points here and there, within reason, but at this point, our metadata is not complete, our materials may not be assigned parts-- may not have part numbers, it's still pretty loose, we're still exploring, and there is a chance that at the end of this level two phase we scrap it again, not always, level two is kind of like the dress rehearsal for the final production model that you want to be nice. So you get to try out some workflows and different fundamental ways of structuring the model. And you might find that you picked one you totally do not want to do in production, or maybe you did it right, you got lucky or whatever. And you're able to modify that pay back your technical debt and move on to a highly robust and navigable and lightweight model.
Level 3: Production 09:01
So that brings us to Level 3; Production and this is where you should actually have that idyllic model that I talked about at the beginning. You should be able to change fundamental things without breaking the model, your features should be named and in folders and in a good order. And your references should be always as high up in the tree as you can. Somebody should be able to find their way around the part studio without needing a tour. Or sometimes I'll even record a video tour and upload it into Onshape so that our whole team can know what controls what, trying to make it as easy to collaborate as possible.
The upshot 09:38
The upshot here is that best practices are just half of the story. And if all you're thinking about are best practices, when you're doing your CAD work, you're going to take way too long to do your exploration and your iteration. And you're going to be losing sight of the big picture because you're fussing over making a sketch turn all black when you should be thinking about what makes your design good. It's a waste of your time and brain Power, both of which you only get so much of in one day.
So how do you know what level of Rigor versus speed you should be using at any given point in your process?
Ask yourself this:
Am I exploring? Or am I executing? Am I trying to find the right thing to build? Or am I trying to build the thing right?
So the more exploratory it is, you should focus on speed the more concrete your idea is you should focus on Rigor, especially as part of the team.
Words matter 10:25
Now, I think most people do instinctively modulate the level of speed and the level of Rigor based on how much design clarity that they have. But often, it's subconscious. And there's some problems with that. If you're making this decision subconsciously, instead of explicitly, it's probably going to be less repeatable for you. And just going through the exercise of asking yourself that question where you want to be, is pretty important for the accuracy of your decision.
Another reason is that if you are delivering your CAD to someone who understands CAD or working as part of a team, you might rightfully be concerned that someone who sees your work will think you just don't know what you're doing.
And a third reason is that when you're working as part of a team, you want to make sure that everyone is treating the same model with the same level of rigor at the same time. And it's really hard to do that if you don't talk about it. So by giving it a name, and defining it, you make all of those problems go away.
Conclusion 11:22
Your CAD should suck sometimes. I said it. Are you horrified at my CAD heresy? Or are you feeling vindicated? Maybe that somebody finally said it's okay to keep doing all that sloppy stuff you have been doing and feeling bad about it? Does this change how you might collaborate with your team? Let me know all that stuff in the comments. And if you've gotten this far in the video, I imagine you've gotten some value out of it. If so, liking, subscribing, hitting the bell all those things help us make more content like this. Thanks for watching!
