Dialog Box August 2007

Readers have their say.

I love AutoCAD, and I think it is great program. My concern is that new releases, as with all great new things, are coming out too often. It is impossible to keep up with the rate. In my company, the situation is very difficult. The clients require delivered files in releases from AutoCAD 2002 to 2007, and we will not have 2008 until one of the clients requires it. And also add Land Desktop and Civil 3D . . . this is just the beginning of the problems.

On top of all that, several clients require us to use MicroStation -- a whole bunch of releases of that program too.

The biggest issue is training. People who can use both AutoCAD and MicroStation basically can get by.

Very few know AutoCAD (or MicroStation) well enough to set up projects and maintain standards and resolve everyday problems, simply because it is very hard to keep up with the great new things that these programs deliver. In my estimate, people use AutoCAD far below its capabilities, about 30-35% of its capacity . . . (on the level of last training that they have had).

My conclusion: new releases should come out every three years. Upgrade classes should be free (as it was in the beginning, with the price of classes included in the price of the software) and with small booklets describing new features (reading from the screen helps but a good old book is better no matter what).

I am concerned about what is going to happen when these releases come out so often and have so many bugs as a result of the release frequency. We already face shortage of experienced people.

Rendering in Revit
Why are you pushing Autodesk 3ds Max when Revit has its own built-in rendering engine? A Max seat costs as much as a Revit seat -- and has a vicious learning curve to boot. Why would I want to do this to myself? If you don't like the Revit renderer, what about taking the 3D DWG back into AutoCAD with its engine? That would be a more familiar environment too.

Rick Rundell Responds
Autodesk offers multiple design software solutions for architects, designers, and building industry professionals and supports multiple workflow requirements. In the "1-2-3 Revit" column referenced, I choose to highlight design visualization using Revit Architecture and 3ds Max and demonstrate the benefits of collaboration between these two purpose-built design environments. 3ds Max, when used in combination with Revit Architecture, offers a more granular approach to modeling, rendering, and animation. For those seeking fresh ideas for better viewing and understanding their design ideas, 3ds Max offers state-of-the-art design visualization functionality. This can provide users greater control with respect to global illumination, material definitions and mapping, network rendering, even and more.

As Kelly points out, Revit Architecture does offer rendering inside the application, and I did not intend to minimize the value of in-line design visualization functionality available through this workflow. Rather, I chose to highlight how improved collaboration between Revit Architecture and 3ds Max simply offered a compelling way of thinking about design for new users and existing users seeking to leverage their technology investment.

Proving Your Work
How many of my fellow CAD managers and CAD operators have found themselves seeking a new job and during process been asked, "Can you provide examples of your work?" While this seems to be a harmless question, it is in the nature of the CAD field that the details of our projects be kept secret. Although there are many reasons for keeping a tight grip on technical drawings of both an architectural and mechanical nature, ranging from trade secrets to the safety and security of a facility, it begs the question, How can we, as CAD professionals, prove our abilities?

I have had the fortunate experience to work for a large international company creating and maintaining not only architectural drawings of their various facilities, but mechanical drawings detailing secretive production processes. For all of that experience, and the experiences that have come before it, what do I have to show? When I am asked the inevitable question of proof, I am left speechless.

Standard practice in today's business world is to mandate that all technical drawings be released only to authorized contractors, and once one's position in the company is forfeited or cancelled, no technical drawings are to leave with them. . . . Some work does find its way out, but in most cases it is not work that fully expresses the abilities of the individual. In other cases, possessing information or showing technical drawings to another company would create grounds for a lawsuit.

So, how do we express our abilities for those future job opportunities? One option is to simply take the risk and hold on to those CAD files for future proof of your ability and hope that it doesn't result in a lawsuit. You may think that withholding certain information from the drawings would keep an interested company from being able to make use of your drawings. However, it has been my experience that any drawing, no matter how vague, holds enough information to reverse generate it back to its original state. The same applies to other variations such as PDFs, JPEGS, or any other seemingly harmless format. Oddly enough, I've had to do just that many times in the past. So, there seems to be no real solution here.

I ask my fellow CAD professionals to help in seeking a solution to this problem. Equally, I ask those in hiring positions to spend time thinking about this topic.

A Block Problem
I'm a fan of Cadalyst. I check the codes monthly and follow Harry's tips, which I find very informative because I don't have any background in programming. Little by little, I am learning and digging it. You guys are doing very well; keep it up.

I have seen this month's issue of codes (LISPs) and found that brp.lsp is very useful in my work, as I am preparing basemaps from other companies to be used in my company. These basemaps contain blocks within blocks within blocks within blocks within blocks. Thanks to brp.lsp, I can now redefine entities within nested blocks without exploding the drawing and changing back all of the entities' colors to bylayer.

The brp.lsp solved my previous problem, but I've encountered another problem and here it is:

I have a block, and within it is another block, and within it is another block, and at the very end is an Mtext with embedded formatting from an Mtext editor. Though this Mtext has been changed to its bylayer color, it is adapting its embedded format and color. How can I strip the formatting without exploding the block and going through different levels of nested blocks. Is it possible to do this? Kindly advise. More power to you guys.

Editors Respond
Thanks so much for writing and passing along the words of support.

Hot Tip Harry is at the ready to help with AutoLISP programming needs: Check out Cadalyst's Hot Tip Harry Discussion Forums. Use the Hot Tip Harry-Requests forum when you need to develop a new AutoLISP routine or tweak an existing one to meet your needs. The Hot Tip Harry-Help forum can provide assistance when you have problems using an existing LISP routine.

Forum use requires registration, but it's free.

Good, Bad of CAD Management and IT
I had to write to tell you how helpful your "CAD Manager" column, "Making It Work With IT," was to me.

I am the CAD manager in a department of approximately 23 CAD users in a company that manufactures cabinets for schools and hospitals. Our company has a one-man IT department. As you describe, I have found it difficult sometimes to understand his thinking, as I'm sure he finds it difficult to understand mine. I focus on speed and ease of use, and he focuses on stability and security.

In our particular environment, we both are programmers. Of course, mine is CAD related for the most part, but connecting our CAD data to our company information system involves some overlap of CAD and IT.

In our case, my working for IT could be both good and bad. Good because it would reduce any overlapping or redundant code that gets written. And it would ensure that we have a more homogeneous system. It would be bad because it wouldn't allow me the freedom to write the tools (programs) that really make our jobs easier. IT's lack of understanding of the CAD users would likely influence what was deemed valuable.

Your article made me think more about trying to understand IT's pain and helping him to understand ours. By the way, I've enjoyed your column for a long time now, as well as your sessions at Autodesk University. I always get something valuable from them.