Process or Results?

I’ve worked on a couple of things recently which put me on opposing sides of the same issue. One project, let’s call it the Knurl project, has some aspects that are extremely complex, and required me to make some hard decisions about what matters most: getting the geometry just right or following the proper best practice procedures. And that was immediately followed by a rescue project, let’s call it Prismatic, which I inherited from someone else who completely ignored good process on the simplest parts. They went for results without caring about how they got there. (Just so you know, this rescue project was associated with a reseller design service, so you need to really check who you work with).

In one case, a very complex model where I bent the rules a bit, and another case where it took less time to rebuild the models with proper design intent than to change what I was given, but had huge feature trees because of all the “hack and whack” modeling – what I one time called “sleazy tricks“.

The complex model was a knurl on an irregular surface (think a rolling hillscape). I tried all the normal shortcuts with swept cuts. I even tried to set up a fancy variable pattern to vary the sweeps, and one version with varying lofts, as they moved in a grid around the hillscape. Because it took a couple of hours to make 400+ loft features (lofting from a split face to a trimmed face), there was a lot on the line to get this right. All of the more automated solutions gave very erratic top of the knurl detail. Some of the pyramid tips were flat, some were sharp, and it just didn’t look clean. But as you can see from the image above, I eventually got the tops of the knurl uniform. But it didn’t come cheap.

Following great procedures gave me results that weren’t acceptable. When I say “great procedures”, I’m talking about general best practice, trying to economize number of features, editability, rebuild time, and so on. When I broke down and finally decided to take the 2-3 hours it took to make the 400+ individual loft features, the result looked perfect geometrically, but the model was a mess to work with. I have never seen a single part model climb to over 1.5 gb (that’s right, a single SolidWorks part that is over 1.5 GIGAbytes), but this one cleared that. It took 10 minutes to rebuild the model at times. So where do you go? Perfect model geometry or a proper process? Do you see my dilemma? Of course we all want parts that rebuild instantly, are simple to navigate and edit, and are geometrically exactly what we imagine.

The file size really bothered me, and I tried to get it down lower. These are the tricks we used to try to make files smaller:

• suppress all features and save
• shrink graphics window and save
• push part off side of the window and save
• set display to wireframe and save
• delete configurations
• delete extra bodies
• delete display states
• remove appearances
• use the rollback and freeze bars

I need to point out, though, that eliminating the amount of saved information just increases the amount of information the software has to recalculate. So it’s a big trade off – file size for rebuild time. In most cases, I’ll compromise on the file size, because it’s just an academic issue, and storage space is cheap compared to compute time.

But sometimes all of this wasn’t enough. I found a long time ago that multiple bodies, configurations, and especially working in rollback would balloon file sizes. On big complex models you can’t avoid rollback. I built another similar model that was only 200 mb, so there was definitely something with that one file, not something systematically linked to my process.

In the second Prismatic case, some of the models started from an imported body, and then moved through several delete face, move face, etc, etc features until you have a couple hundred features to just alter the model a little bit. In more than one case, I rebuilt the models because I know editing what I received is just going to be more of the same (move face, hack and whack). Editing a real parametric model makes a huge difference in comparison. And you know going into any project like this that the one thing you can count on will be changes.

If this were a Synchronous model, things would be different, because Synchronous tools make dealing with a non-history based model easier. But putting direct-edit type features in a history-based model make the worst of a bad situation.

Especially when you’re in a project that is essentially still in the detail design phase, the ability to change a model without destroying delicate design intent is very important. You want the design intent to work for you instead of against you. In more prismatic projects, this is easier to do (but also if I have to be honest, getting design intent that you can control on the fly by selection rather than by divining foreknowledge with a crystal ball would have been very helpful, plus the issue with imported data totally disappears – and all of that is to say that this project would have been a perfect synchronous technology project.)

So in the end, what am I saying? I think the one constant across all projects is that you must get the geometry right, no matter what. Sometimes you have to sacrifice the best practice process to do that. But don’t give up too early. On my complex knurl, I was way past best practice, and was just in the territory of “how do I make this geometry correct”. And I truly pity anyone that has to work with that model. But on the prismatic project, getting the geometry correct is totally achievable within best practice. And for future reference, recognize that synchronous technology can help you avoid a lot of bad practice. If you have read the “Synchronous Technology for the History Based User” (I’m a great one for huge titles, right?) you know that synchronous technology is also all about the end product geometry, and if you don’t have to deal with the tyranny of a history tree, it never really matters how you get there.