One of the big-ticket features of AutoCAD 2010 was parametric constraints. This was old hat for many applications, even some based on AutoCAD like Mechanical Desktop. Parametrics and constraints already existed in vanilla AutoCAD in the guise of dynamic blocks, but this was the first time ordinary AutoCAD allowed ordinary AutoCAD objects to be constrained and linked to parametric dimensions.
Contraints mean that you can draw some objects and tell them that they are only allowed to behave in certain ways. For example, two lines have to remain parallel to each other. Parametrics mean that objects can be tied to special dimensions such that the dimensions drive the objects, not the other way round.
How good a job has Autodesk done with creating and improving this feature in AutoCAD? Has Autodesk done its usual trick of releasing a half-baked feature and then ignoring it to death? In one vital respect, the answer is a resounding yes. AutoCAD’s parametric constraints can only be applied to 2D objects. Draw a shape using a polyline, apply constraints and parameters, and adjust them to make things work properly and appear correctly. Now extrude the polyline to convert it to a 3D solid. Your carefully applied constraints and dimensions are instantly exterminated. This was a huge and obvious hole in the feature when it was introduced, but on the fourth iteration of this feature in AutoCAD 2013, that gaping hole remains resolutely unfilled. I guess Autodesk is keeping AutoCAD’s parametrics in this flattened state in order to protect Inventor from internal competition.
This 3D failing is very obvious, but I’m interested in more subtle aspects than that. As my experience with parametrics in other applications is limited, I’d like to encourage you to provide us all with the benefit of your knowledge. How does the AutoCAD 2013 implementation compare with that found in Inventor? Solidworks? Mechanical Desktop? How easy and efficient is it to use, in terms of creating usable parametric drawings and manipulating them? Is it logical and reliable? Are there any missing capabilities? The Devil is in the details, so has Autodesk overlooked any?
I’d also encourage less experienced users to comment. If you don’t want to enter a new field with your own drawing started from scratch, have a look at this sample drawing courtesy of Autodesk’s Dieter Schlaepfer. Here’s what Dieter has to say about it:
For your amusement, here’s a backyard deck that I whipped up a while back as a parametric design. It’s saved in R2010 format. After you turn on the geometric and dimensional constraints, open the Parameters Manager and try changing the value of Angle from 90 to 120, 130, and 140 degrees. Also, try changing the value of Tread from 18 (inches, sorry) to 16 or 20.
No question that this takes a bit of experience and it’s not for everyone.
If you prefer to embark on your own journey of discovery, here are some deliberately vague instructions. As always in AutoCAD, there are many ways of doing the same thing, but this will do to get you started:
- Draw a closed polyline describing an open L shape (let’s say it’s a metal plate). Make sure the corners are square, but you don’t have to make the sizes totally accurate.
- Use the AutoConstrain feature on the polyline.
- Perform a few grip edits on the constrained polyline so you can see what difference the constraints have made.
- Use Dimensional Constraints Aligned to dimension the plate in four key places: each overall plate width dimension and each of the leg width dimensions. Hint: press an initial Enter to use Object mode before selecting the object. When you are prompted for the dimension text, either press Enter if it’s was drawn accurately or enter the correct size if it wasn’t. The plate should change to the size you enter.
- If you want these dimensions to show up on plots, you will need to make sure their Constraint Form is set to Annotational. You can use the Properties palette to do this. You may also need to use DIMEDIT Home to put the dimension text in the usual place.
- Try using a few normal editing operations on the objects (e.g. STRETCH, COPY, ROTATE, TRIM, grip edit) to see how they react.
- Try modifying the objects by double-clicking on the dimensions and changing the values, then using Parameters Manager.
So, how was that? Easy? Difficult? Useful but awkward? Any areas where efficiency could be improved (e.g. too many clicks required for common operations)? Can you use this in your work or is there some problem lurking that appears to be a dealkiller?
Edit: Here’s a more complex example from Dieter: https://www.dropbox.com/s/n5hng961nj1dkzy/gasket1.dwg?m
Here are some basic tips for those of you who are not familiar with parametric drawing:
– Check out the overviews in the Help system (search on parametric).
– Turn on the display of geometric and dimensional constraints on the Parametric tab. Click the Show All button for both types.
– You can double-click any dimensional constraint in the drawing to change its value.
– “Tread” is a variable that can be changed from the Parameters Manager (PARAMETERS command).
Parametric drawing is most relevant for designs that go through numerous small design changes or versions. And yes, it supports 2D designs only.
I have stayed away from parametrics for layout of civil work. I essentially do not trust that things will be stable through time if made parametric, and have not seen any killer use for them yet. I’m wondering if anyone has done street knuckle or cul-de-sac layout with them. Unfortunately, the way adesk has handled the fancier features in last 6 years has set my attitude of keeping things simple.
I will respond more fully Steve to this topic when I can.
In relation to Dieters drawing I am disappointed, I thought we were going to see a real drawing.
No Apoligies for being rude but hey, parametrics do have something to offer and though the implementation currently in AutoCAD does not do the functions potential, justice, nor would/does it encourage exploration.
Given the experience and the past implementation of parametrics available for use in AutoCAD Autodesk should be ashamed to so poorly present a useful tool
That’s a bit rough. There are many ways to demonstrate a concept at varying levels of complexity. This is a simple example, which is probably appropriate for concept introduction.
For me, even for 2D there are still many rooms for improvement. For example we can’t control objects in a block from drawing level (imagine that you can change feature size when you are working in part level in Inventor). And we don’t have project level parameters when we work with reference files.
To me, this is pretty much for conceptual design, in 2D. And many of us don’t even use AutoCAD for conceptual design.
From a high level, you can think of parametric drawing as “geometric programming.” That’s why I never use autoconstrain. You are imposing a layer of logical machinery onto a set of clueless geometric objects to create a behavioral relationship between the objects. The relationships are more important than the geometry.
When I was learning the feature, I created a more complex design of a gasket, which included formulaic relationships. Theoretically then, if the engine design changed, the gasket would automatically adjust. Now, extrapolate these relationships to several levels of subassemblies–something that it sounds like Edwin is familiar with–and you begin getting the sense of the organization that’s required.
This can get very complex very quickly, so the results have to justify the time spent. In the case of my admittedly simple deck design, I can sit down with a client and make real-time adjustments to the design as part of our discussion.
Early in my career, I worked for GE Calma on their DDM (Design Drafting and Manufacturing) product where I saw demonstrations of how this concept of data-driven geometry was implemented. In one case, our customer’s client provided the electrical properties of a high voltage insulator and the customization provided several alternatives involving different diameter fiberglass cores, lengths, and endcaps. A drawing and cost proposal was produced on a while-you-wait basis. I could describe several examples that involve machine design.
So, parametric drawing is just another a tool that you have available in AutoCAD. It may not be relevant to your work. But for situations where you need rapid iterations on similar designs, it would make sense to investigate the tool, and it might turn out to be profoundly beneficial to your work.
Dieter, do you have a more complex example? Something closer to the real-world drawings my readers deal with every day?
I’ll see if I can find the more complex mechanical-design example that I created, but it’s been a couple of years so I can’t promise.
Historically, parametric design has been more of a mechanical design tool and not commonly used in other disciplines such as AEC or civil engineering. Do you know what type of drawings that your readers typically deal with?
I have about 30,000 readers a month (most of them Autodesk customers), so I imagine that between them they will deal with pretty much all possible drawing types. I think a mechanical design example will do just fine.
Well unless I’m missing something, and I might be, if I were going to use it I would want it to be much more like the Inventor sketch environment. I don’t want to have to create something and then apply geometric constraints afterwards, I want them to much much smarter than they are now.
I admit to never using the Autocad parametrics, heck I have barely touched Autocad in over 3 years, so maybe it can work like I described but if it can it wasn’t obvious to me.
You don’t have to do what I described above, can turn on an auto-constrain mode first and then draw the objects.
I4ve been playing around with parametric constraints in Autocad for some time now. It’s not always fun but (trying in anger)you can achieve fancy things. Not being able to appy constraints directly in 3D is a huge limitation. There are some ways to work around but that’s just too much work. Here is one example (3-parts videos) where constraints, parameters and surface modeling are combined to build a 3D mechanical part:
– http://www.youtube.com/watch?v=9fCdRUSOnsg (Part1)
– http://www.youtube.com/watch?v=34nm2UuRo5c (part2)
– http://www.youtube.com/watch?v=a9sQ5mi_k3k (part3)
The technique is not mine, I learned it from Guillermo Melantoni’s presentation at AU2010.
Bottom line : fun to play with at home (and yet very fustrating) but not a good idea to try it at work, except if you’re asked to or paid for.
greg (not my real name!)
PS: sorry for my English
So, the most announced improvement in AutoCAD 2010 is a weak feature, useless for most users. That’s why I almost never taught this at my classes and only applied it with dynamic blocks.
I totally agree with you Steve, I was expecting this to be extended to 3D, but it is another not-so-good innovation due to the need to present something new every year.
And a side note. Constraints have been removed from AutoCAD 2013 Professional Certification Exam:
There are a lot of features in AutoCAD that are used by subset of AutoCAD users with specialized requirements: 3D solid modeling, rendering, object transparency, tool palettes, and geometric tolerances come to mind. Would it be fair to characterize these as “a weak feature, and useless to most users” as well?
Just as with any AutoCAD feature, if you can be specific about shortcomings or requests in the 2D parametric drawing feature, *I promise you* that I’ll make sure our product design team receives your feedback. Adding 3D support to parametric drawing has definitely been such a request!
> Adding 3D support to parametric drawing has definitely been such a request! <
Designer added 3D parametrics to R12 way back when. It evolved into the late, lamented MDT. Restoring 3D parametrics…
I've been asking for negative radius fillets since 1992. Pocket milling, and fluted edges aren't considered specialized in many mechanical disciplines, but ACAD can't do it directly. I can, but the addition of a little "-" would save a lot of steps – like toolbars do over ribbons.
My offer to whine (professionally) for cash – that not wasted on buying DOA companies for tax break money – still stands. -Bill
Adding well-thought-out and implemented features that are only useful to a subset of users – good.
Adding dumb and/or half-baked features – bad.
Guess what else is incomplete! FLATSHOT. Massively random basepoint, Reversed creation defaults that don’t get saved anywhere – BYLAYER is more useful than BYBLOCK for my many needs – and wouldn’t it be nice if it allowed you to simply select/set user specified default layers instead of having to edit the components every time. Could be a time saver instead… Parametrically speaking. -Bill
FLATSHOT? Get with the times, Bill, that one’s seriously out of fashion. If there’s one thing that says everything about the half-baked feature syndrome in AutoCAD, it’s generating 2D views and sections from 3D objects. There are about 12 ways of doing it, each (I guess) developed by a different team that wanted to start afresh rather than finishing the work of those who went before. As a result, none of them work perfectly. Most of them don’t even work adequately.
To be fair, the latest, Model Documentation, seems to work pretty well. Although it was too half-baked on release to use in production, at least it was baked some more the next year. It wasn’t instantly forgotten and ignored to death like so many other potentially useful features.
Model Documentation ain’t what I’m doing. Since Dynamic Blocks are also unfinished, incomplete, orphaned, and otherwise Autodesked… I need the nicest 2D representation possible, so I FLATSHOT (instead of SOLPROF like in the old days) my lovely 3D bits and chunks to assemble ’em quick(ish) and dirty. Certainly, multi-view parametric 3DSolid Dynamic Blocks would be better – but instead of waiting another (please see reference to 1992 above) twenty years for a feature to either be finished or dropped I’ll soldier along pretending that this is professional level software.
I just searched 2012 help for ‘model documentation’…
> I just searched 2012 help for ‘model documentation’…
Ah, that explains a lot. What were you thinking?
Instead of that, start with a simple 3D model (must be all solids) and stick a title block in paper space. Don’t make any viewports. Enter the VIEWBASE command and follow your nose.
Other relevant commands you’ll probably be able to find in the stupid Help system: VIEWPROJ, VIEWEDIT, VIEWEDGE, VIEWCOMPONENT, VIEWUPDATE, VIEWDETAIL, VIEWSECTION, VIEWSTD, VIEWDETAILSTYLE, VIEWSECTIONSTYLE, VIEWSYMBOLSKETCH, VIEWSYMBOLCLOSE. I made a toolbar with this stuff on so my users can attempt to use it.
Don’t use 2012, that really was half-baked; use 2013. It’s still not 100% there, but it might possibly be cooked enough for you to use on some jobs. If not, SOLPROF is still there, along with SOLVIEW and SOLDRAW.
Uhhhh, VIEWBASE makes pretty prints but offers nothing to help my dynamic block projects. Are you saying that 2013’s output from the ModDoc tools are adressable? I didn’t notice that in the 2013 New Features Workshop. Not in the help file index either. These display/print tools in Inventor were the only reason I kept it loaded – quick ACAD modeling and then lovely Inventor output
I’m not sure what you’re doing with your dynamic block projects and I’m not sure what you mean by “addressable”, but my guess is that Model Documentation won’t help you because the views generated are their own thing rather than normal objects. Play with it for 5 minutes and you’ll know.
VIEWBASE! Where have I been? This has been around all this time and this is the first time I’ve heard of it? I must admit, I like it WAY better than FLATSHOT. Especially the way too easy section view feature…
“Adding dumb and/or half-baked features – bad.”
This sounds simple and good, Steve, but what you’re describing is actually profound challenge. Obviously, any company wants to deliver the perfect product, but it also needs to make revenue before the company goes out of business. Reality lies somewhere between the former and the latter.
Was the first iPad half-baked? How about the first laptop?
Design luminary and someone who’s ideas I admire is Alan Cooper (author of The Inmates are Running the Asylum and several other books) gives a talk in which he states “best-to-market always beats first-to-market” and then shows several first-to-market products that no one’s ever heard of such as the first mobile phone, etc. I believe he’s right and I deeply appreciate well-crafted products. But much as I hate to say it, sometimes sooner is better.
I could state something like “when you buy AutoCAD, you’re not just buying a product, but you’re also buying into a development stream.” This is true, but then your drawings are not “a development stream.” They need to be done in a reasonable amount of time. Similarly, I sometimes find myself silently cursing some of the software that I need to use to create your AutoCAD documentation. But I’d rather have the software than not have it.
From direct experience, I know that internally, there’s a lot of effort to avoid building “a four-lane highway halfway across a river.” This is where Beta programs, your constructive feedback, CIP data (with all its caveats), internal initiatives, and many other sources combine together to guide the product. The effects are not immediate, but I want you to know that your feedback does make a difference!
It shouldn’t be a profound challenge. It’s called “doing the job properly”. Without the 12-month cycle it would be very straightforward. Nobody’s forcing Autodesk to keep churning out a perpetually undercooked product every year; that’s a self-imposed problem and I have no sympathy.
From out here, and even from within the Beta program, there is no evidence of any effort to avoid building highways halfway across rivers. In fact, it looks like that’s the standard operating procedure. Neither is there much evidence of any amount of feedback from any source making any significant difference. Once somebody’s decided that some incredibly dumb idea is the best thing since sliced bread, or that it’s perfectly OK to supply a half-baked feature that’s more trouble than it’s worth, then that’s exactly what happens. The feature gets dished up, dumb and/or unfinished, and ends up in the product, no matter what anyone says. Exceptions to this rule are vanishingly rare; I can only think of one minor example. The rest of the time, it’s like bashing your head agaist a particularly stubborn brick wall. Eventually, even the thickest-skulled among us work out that it’s a pointless and painful exercise, and give up. That’s why the Beta program is a sad pathetic shell of its former self.
Why is it Dieter software products should be seen differently to others. If a kettle I buy won’t boil it is replaced; should a car company deliver a vehicle which keeps stalling it’s replaced; if Boeing thinks about getting it’s software sorted out after it comes to market, someone dies, this will also apply to cars you don’t drive!
Now Direter your arguments may have some validity in a companies early stages. Autodesk was supported by quite a few in 1983 knowing we were getting into something new needing support and patience. Autodesk’s managment and personel however have seen this early support as being the norm forever and that is plain stupidity. Autodesk is a mature organization being staffed from top to bottom with people who beleive they have a right to treat customers as crutches to support them endlessly and to pay for the privilege of “assisting” Autodesk to fix their failings.
Come on Dieter, we’ve rolled around this several times and, it’s long over due for Autodesk, as a whole, to grow up and start providing the software products we pay for. Not incomplete dreams we are expected to help fix, that alone mature.
When I joined Autodesk back in 1988, our release cycle was 18-24 months long. Carol Bartz changed it to the yearly cycle beginning with AutoCAD 2000. I believe it was Tom Gilb in Principles of Software Engineering Management who noted that any significant software required at least an 18-month cycle. However, he warned against megalithic software projects that lack short-term deliverables and what’s sometimes termed “failure criteria.” I was amazed at some of his real-world examples, including a billion dollar effort to automate vehicle registration in the State of California, which turned out to be a spectacular failure.
The other side of the equation, the customer side, involves integration. Implementing any major software application is disruptive and results in a short term productivity loss. So, given a choice between infrequent but much larger changes in AutoCAD or more frequent but much smaller releases, which would you prefer? Let’s assume for sake of argument that the level of quality meets your expectations in both choices.
Paul, you’re reminding me so much of the issues presented in Alan Cooper’s The Inmates are Running the Asylum. Have you read the book? In it, Cooper suggests that software is a “dancing bear.” When people see a dancing bear, they don’t criticize how well the bear dances, but rather they’re amazed that it dances at all! He gives some astonishing examples of physical products (including an expensive sports car) that involve software and the disastrous consequences that followed.
So, unless you enjoy a nice tango with a grizzly, I’d advocate for more, not less, customer involvement. Wouldn’t you agree?
> So, given a choice between infrequent but much larger changes in AutoCAD or more frequent but much smaller releases, which would you prefer?
The former, easily. Many companies skip the yearly releases anyway and implement only the 2nd or 3rd release. I just moved my users from 2010 to 2013. The effort and disruption in moving from 2010 to 2013 was about the same as it would have been moving from 2010 to 2011, so why treble the pain?
> Let’s assume for sake of argument that the level of quality meets your expectations in both choices.
No, let’s not. Instead, let’s be truthful and acknowledge that the 12-month cycle seriously damages the product. It’s a cash grab; let’s not pretend otherwise.
Between late 1982 and 1988 ten (10) releases equates to roughly seven month release increments. This was followed by Release 11 and Release 12 with a two year increment in the first and I believe an 18 month increment for the second. Looked at from an overall perspective this I believe this would mean an average release date rate of nine and a half (9.5) months.
Now the ”pedantics” have been dealt with No I have not read the book mentioned Dieter and probable don’t fit as I would be more concerned about the bears welfare; neither the quality of its dancing or that it was even possible.
Yes I would agree more customer involvement may benefit the development of AutoCAD and other Autodesk products. But the implementation and execution of CIP was and remains an unconscionable act and a very foolish decision by Autodesk personnel. As a corporate sanctioned and executed Trojan it forces its installation, without choice, onto customers’ critical business computers and sits there waiting for “surreptitious” activation. While that situation prevails CIP remains a blight on Autodesk reputation and integrity as a trustworthy business partner.
If Autodesk feels more customer participation is warranted and of value it needs to put its customers first; NOT BY ASSUMING WHAT AUTODESK WANTS AUTODESK HAS TO RIGHT TO TAKE!
CIP is Off topic but having raised it needs addressing.
Returning to my question though why Dieter should software products, in particular one pushing thirty (30) year old be treated differently to other products?
I’m intrigued by individuals/companies who talk about moving forward and the positive values of change and how it is inevitable; and yet those same individuals are LOCKED into thought processes which are years old and cause grief; Parametrics in its current form demonstrate this “to a tee”. When there existed history about how to do it and, how to do it properly; Autodesk chose to do it all wrong!
“So, given a choice between infrequent but much larger changes in AutoCAD or more frequent but much smaller releases, which would you prefer? Let’s assume for sake of argument that the level of quality meets your expectations in both choices.”
I take a slightly differing view here (maybe) to Steve. I see, and always have, CAD as a platform for incremental development. One which should build on existing capability changing earlier functionality only with cost effective PROVEN changes which add to existing capability. The time increments, long or short, are less relevant than what is returned to the customers in increased productivity.
As an example (again), the changes made to menu systems were simply a waste of time and money for both Autodesk and their customers. The original (DOS era) menu is still the most cost effective system of screen based input – for several reasons.
There exist an obvious way to take products like AutoCAD forward in leaps and bounds Dieter and it’s not the customers who are preventing this, it is Autodesk’s management and staff; locked into outdated thinking about who is responsible for the success of their product aided and abetted by a subscription program which has disabled and disconnected product improvement from customer value. Easy money it appears = poor product development.
I quote, “Developing new products is difficult. I know – we’ve done * since 1892, but if we apply the same humility we had during the evolution of AutoCAD, I believe we’ll continue to develop products which solve new problems and create new markets for the personal computer. In 1983 people used to ask us about “our vision of the future of CAD”.We used to say in all candour, “we don’t really know enough about CAD to have one”. But we have a secret. We knew somebody who did know – our customers.”
Who said that I wonder, was it an Autodesk person?
Taking it out of context I offer it as a prophecy. “We knew somebody who did know” seems to be what Autodesk now truly believes; it is they who know better than their customers.
Would I agree with you Dieter and advocate more not less customer involvement. The simple answer would be yes; though I would do it differently. However with the attitude outlined above radiating out of every pore of Autodesk and its channel those customers who may be best placed to provide that which is needed are highly unlikely to participate.
During AutoCAD’s early history there were many rapid-fire releases that were justified because they brought significant improvements (OK, except maybe Version 2.6). Since 1999, the rapid-fire releases have not been justified in anything but financial terms.
Ignoring the OT stuff.
So, bringing this all back to Parametric Design . . .
a. Do you think the 2D feature set is reasonable for customers who need constraint-based designs for families of parts or designs that go through numerous revisions? If not, what’s missing? Or
b. Do you think Autodesk should not have released ANY portion of the Parametric Design feature until it at least matched the feature set offered in competitive products?
a.) Yes Dieter I think parametric controls for 2D are as important as they are for portions of 3D and, should be an integral part of CAD systems used for design and documentation.
b). That is partly correct. It needed to more seamlessly part of the existing draughting and dimension scheme.
In terms of integration in b.) above, are you suggesting that PD needs improvements specifically to annotational constraints, rather than using dynamic constraints together with standard dimensioning?
Or are you suggesting that we add an inferred dimensional constraints feature to the existing inferred geometric constraints?
Or maybe you’re thinking of something entirely different.
Dieter, for openers just make it part of dimensions at style level (along with long overdue Multi Leader integration).
I cannot provide customer data for obvious reasons and some very good examples of a complex dust filter plant and a library of components created many years ago using AutoCAD and Mechslide are no longer available for use due to the Genius became AutoCAD Mechanical debacle.
The file I have put in Dropbox, for those who may be interested, is a simple head tube connection of two round sections.
The file was created in response to questions received simultaneously from three individuals. One who has long made his own racing motor bike frames and was just starting to use AutoCAD to “think” and document. The other just simply wanted to know how parametrics worked in AutoCAD and, the third, was a TAFE teacher asking about the possibilities of incorporating AutoCAD into his fabrication course teaching development and possible ways of automating the task.
Using this file I “killed all three birds with one stone”. It’s a demo, done quickly for a purpose: it is not fully constrained, will give some absurd results and can be simplified. It also shows some of the foibles of the system one being the visible shift in para’ dimensions
The three main drivers for the frame were the tube diameters (dia1 & dia2, top plan view) and the head tube to up tube member (ang9 shown as 110 degrees in side view).
Have fun at my expense 😉
Thanks for the great example!
While I’m not a mechanical engineer, I can see what you did. Starting with a top view of two intersecting tubes of different diameters, you generated the side view in 30 degree increments at a 110-degree intersection angle, which you then used to generate a flat pattern for fabrication, as you might do for sheet metal. Nice.
Here are my general observations:
o It takes a lot of effort to fully constrain a model in a way that makes logical sense from an engineering point of view.
o Displaying constraints sure makes a model look complicated. There are probably clever ways to mitigate the effect, including making the dimensional constraints tiny (it would be nice if the selected dimensional constraint was highlighted in the Parameters Manager) and geometric constraint icons more transparent.
o Don’t rely on AutoCAD for solutions in models that are not fully constrained. While those solutions will be geometrically correct, I’ve found them rarely to be what I want. I’m not faulting AutoCAD, but it’s definitely like trying to pick up Jello with a knife.
o In general, try to use more dimensional variables, user parameters, and parameter groups. No, I’ve not taken this advice either. 🙂
o Use few fixed constraints, if any at all. One will prevent general translation, two will prevent rotation in a fully constrained model.
o I also ran into the migrating dimensional constraints, which I found really annoying. I’m not sure whether these problems originated from a pre-release version or a shipping version, but the defect seems to be fixed in 2013.
o If you change dynamic dimensional constraints to annotational dimensional constraints, they will adopt your current dimension style. I think this is what you’re asking for. However, I don’t think this is always desirable because the way we design things is not necessarily the way we document them. The most obvious example that I can think of is the side view of a wheel with three solid “spokes.”
Thanks again for sharing the model! I’ll see whether I can get an ME around here to have a closer look at it. Also, I’m still looking for my parameterized gasket model.
Smiled when I read your reply Dieter thank you.
“If you change dynamic dimensional constraints to annotational dimensional constraints, they will adopt your current dimension style. I think this is what you’re asking for.”
In response to your question, “In terms of integration in b.)” etc; what I said was “make it part of dimensions at style level (along with long overdue Multi Leader integration).”
We have (std. for want of a better term) dimensions driven by styles, annotative dimensions driven by styles, we have parametric dimensions driven by one style(type) or another and we have multi leaders (a type of dimension if I’m not mistaken.) All of which should be driven through dimension styles.
Add to that we have another whole system in play in AutoCAD Mechanical just to mess with users heads I guess.
Integration = One system, one dialogue box – dimension styles, as they exist, extended to embody the lot, controlled and manipulated in the same manner.
Yup. Mleader styles in particular are a terrible kludge. They should never have been introduced the way they are, separate from normal dimension styles. I suspect we’re now permanently stuck with them in this state.
That’s the problem with the argument that it’s a good thing to introduce half-baked features so they get tested in the real world and can then be improved accordingly. In many, many cases, they are left half-baked permanently. This can be either because of “focus drift”, or because the original half-baked implementation stands in the way of doing the job properly.
Multilines, anyone? 18 years of crapness. In two years, I’m going to hold a 20-year MLINE celebration. With a brown cake and everything.
The difference between “half-baked” and “limited scope” is whether you can do useful work with a feature. As I alluded to previously, this can be compared to the difference between a four lane highway halfway across a river an a one lane road all the way across. Autodesk feature teams now refer to something called MVS, Minimum Viable Solution as a baseline. This was not the case when MLINE came out in R13 (walls and highways can be curved).
Personally, I prefer the DLINE command in AutoCAD LT. Are you familiar with DLINE?
My above comments about half-baked features also apply if you want to call them limited-scope features. If they mess up the prospects for a fully-baked, full-scope feature then they shouldn’t be in there, useful work or not. But they keep getting added anyway, so unless this MVS thing is a new initiative, it’s safe to say that it ain’t working.
Yes, I vaguely remember DLINE. I seem to recall that it was a simple crude version of something I had written for real AutoCAD some years previously. I thought it was in real AutoCAD too and assumed that it had remained there ever since, but I just looked at 2013 and it was gone. But that’s not a proper solution either.
I’m glad to hear that I’m making you smile, Paul. I just hope that it doesn’t come along with the “sadly shaking my head” part. 🙂
Just to confirm what you’re saying, you’d like to see a dimension style property added to dimensional constraints (it would make sense to restrict it to annotational constraints), right?
If a dimension style also included multileader style settiongs, wouldn’t that create other problems? Let’s say you want to create reference notes, reference labels, and detail callouts in the same drawing. You’d have to switch dimension styles, to create each one, right? Or maybe the solution would be to split the MLEADER command into three commands: MREFNOTE, MREFLABEL, and MDCALLOUT, each with their own style settings (you’d probably want to keep certain settings separate from dimensions style settings, such as arrowheads).
Back again to Parametric Design. I finally found the drawing that I mentioned previously. You can download it from here:
You can see why not all dimensional constraints can or should function as dimensions.
Back in the R13 timeframe, somebody who was concerned about the future integrity of the product developed the concept of child dimension styles. Much later, somebody else with a tight timeframe and/or less interest in the future of the product ignored all that work and threw together the separate-style Mleader kludge we are stuck with today. It would have been perfectly feasible and much preferable to integrate the features of Mleaders into the existing structure. It may have had to wait until a DWG format change, but that would have been fine.
The point I’m making is that it’s much, much better to implement something late than it is to do it badly and damage the product.
You can still create child substyles based on the type of dimension that you specify, Steve. It seems to me that the design was simplified from that in the original release. Could you describe the complaints you’re receiving from your users?
Also, I’m not sure why you want to combine multileader styles with dimension styles. It seems like it would be needlessly complex to require that every dimension style include a substyle that applies only to multileaders. Maybe I’m missing something here. Please let me know if I have.
Did you have a chance to look at my parametric drawing?
> Also, I’m not sure why you want to combine multileader styles with dimension styles.
Er, because they’re dimensions every bit as much as traditional leaders are?
> It seems like it would be needlessly complex to require that every dimension style include a substyle that applies only to multileaders. Maybe I’m missing something here. Please let me know if I have.
Is it also needlessly complex for all the other types of dimensions?
> Could you describe the complaints you’re receiving from your users?
Sure. “Why the f*** would Autodesk do that? That’s f***ing stupid!” – direct quote from a user after I explained that multileader styles were stored separately from other dimension styles and had to be manipulated and selected independently. I have more, but they’re similar and I’m sure you get the idea.
> direct quote from a user
When did you talk to my Mom?
Dieter, “Just to confirm what you’re saying, you’d like to see a dimension style property added to dimensional constraints”
No, what I am saying is parametric dimensions should be part and parcel a part of the existing dimension style format. Quite simply I see dimensions as dimensions with potentially differing functionality. We can currently work a “normal” dimension several ways, adding the two forms of parametric dimensions to the format would simplify matters.
It would extend the capabilities (and complexity) of the dimension style dialogue but heh, if we, our customers and students can contend with the Options dialogue and the Standards in Inventor an extended Dimension Styles dialogue is still going to be less of a hassle to learn and or manage.
As for the leaders and Mleader it is the same argument: similar but different functionality all controlled in the same area in a similar manner. The fact you may have variations in what is, or is not, included at the end of a leader is irrelevant.
Had a look at your drawing, thank you, and given what I say above I see no argument in your drawing to vary what I believe should happen.
MVS = a measurement of what and measured how?
However, “So, bringing this all back to Parametric Design” I beleive you said 😉
What is your response to my last post which was in response to your question, “If you change dynamic dimensional constraints to annotational dimensional constraints, they will adopt your current dimension style. I think this is what you’re asking for.”
To which I replied NO, etc…..
Let me ask you the question. If a software feature was under your direct management, how would you make sure that it was not missing any critical functionality?
My response to your previous questions was delayed, which I believe was due to my including a URL. It’s the one that’s dated 1 November at 11:09 pm, and it includes a parametric design that I created a while back. Have fun! 🙂
If you’re using a dark background, you might want to change the dark colors that I used.
Dieter” Let me ask you the question. If a software feature was under your direct management, how would you make sure that it was not missing any critical functionality?”
Well, how long you got, have you got your order book ready and, how deep are your pockets 😉
An interesting question, given it is in reply to a question of mine. Suffice to say having been/are in the position (of “If a software feature was under your direct management, how would you make sure that it was not missing any critical functionality?’) I do know how I go about ensuring customers’ requirements are met.
It is my impression some of the “software issues” we have been discussing are a result of Autodesk staff failing to carry out adequate value analysis and development/product validation. From your comment, I thought, MVS may be part of the validation process, which is why my interest was sparked and why my question was asked.
Are you saying you’re not in a position to reveal how MVS is applied only that it exists as a “process”?
Why does everybody keep answering questions with other questions?
Steve and Paul,
I suppose you could make a case for creating annotative constraints (which use the *current* dimension style as any dimension object) that double as dimensions.
But, I’m not sure everyone would agree, that the above is a good idea. For one thing, dimensions are sometimes symbolic (think of the three-spoke wheel that I mentioned previously), and in mechanical design, dimensions also represent aspects of manufacturing (think tolerances and tolerance stacking) that might differ from the design constraints for an object.
I’m honestly a little surprised that you’d want to combine the approximately 80 dimension variables with the approximately 30 multileader settings into a single style style when there’s less than a 7% overlap in their settings. For example, if you use architectural ticks for dimensions, wouldn’t you want to use a different arrowhead mleaders?
But I’m certainly willing to be corrected . . .
What you say about mleaders applies to leaders too. Either Autodesk is wrong to include leaders in the dimension style structure, or it is wrong to not include mleaders in the dimension style structure. Choose one. For me and the users I’ve asked about this, it’s the latter. It’s moot now anyway, as we’re stuck with it.
What happens when we make a substantial improvement as was done when multileaders were introduced, is that the legacy feature is left in place (leaders) to minimize disruption and preserve legacy data. Do your users prefer using leaders over multileaders?
Also, since this thread is a critique of parametric constraints, is there anything that you want me to communicate to our product design team regarding this feature? So far, I’ve heard 3D support for solids and surfaces, and annotational constraints being driven by dimension styles.
Finally, I do want to say that I appreciate the opportunity that you’ve provided me here to get feedback on the parametric design feature set (as well as additional feedback on a variety of features including about negative radius fillets, 2D views from 3D objects, multileaders, and dimension styles).
I also appreciated the videos that Greg posted and the constrained model that Paul shared with us.
I’m acutely aware of the need to avoid breaking existing features and data when introducing new or improved features. I have yet to see a valid reason expressed as to why that could not have been done to provide mleader-style enhancements within the existing dimension style family structure. Feel free to put forward some technical reasons, if you think it’s worth beating this particular equine corpse.
My users have avoided mleaders because of the style issues causing substantial inconvenience for them. I had to do a fair bit of coding to make things work for them with mleaders almost as seamlessly as they were used to dealing with other dimensions. Now I have done that and pointed out the various features of mleaders, many of them are using mleaders. None of them understand the reasoning behind having mleader styles non-integrated with dimensions in the same way leaders have always been.
There were various irritations and inefficiencies I noticed when using parametric constraints, but nothing that’s not obvious to anyone who has spent more than a couple of minutes using them. The 3D thing is a vast gaping hole that I’m sure has not escaped anyone’s attention. I’m not expecting Autodesk to take serious notice of what people have to say here, in the Beta program, or anywhere else. Autodesk does what it wants; customers are expected to put up with it or go away.
In the Dieter I agree with Steve’s last comments – all of them.
You said, “Also, since this thread is a critique of parametric constraints, is there anything that you want me to communicate to our product design team regarding this feature? So far, I’ve heard 3D support for solids and surfaces, and annotational constraints being driven by dimension styles.”
Correct me if I am wrong Dieter, are you separating “parametric constraints” from annotational (parametric) constraints? If so why so?
Yes, Dieter there is something to communicate; all that has been mentioned, and thank you – particularly the obvious inclusion of parametric dimensioning and multi-leaders into dimension styles!
Hi Steve and Paul,
As promised, I’ve condensed and quoted everyone’s observations, requests, and criticisms here regarding the Parametric Drawing feature, along with those for dimension style support and multileaders, and I communicated them to the AutoCAD product design team. What they find particularly helpful is when I can provide scenarios that support your feedback.
For any of your readers who are not familiar with parametric drawing, I’d like to belatedly clarify some terminology:
Parametric drawing includes two types of constraints: geometric and dimensional. Dimensional constraints come in two flavors: dynamic and annotational. Dynamic constraints are meant for engineering and design purposes: they automatically (dynamically) scale to your current view, are often hidden, and do not plot. There’s no dimension style associated with them. In contrast, the annotational type is very much like a dimension. It adopts the current dimension style, is never hidden, and plots like any dimension. The difference is that regular dimensions are “driven” by values derived from geometry, but annotational constraints “drive” geometric values. You can easily convert any dimension constraint from dynamic to annotational and vice versa through the Properties Manager.
Paul, the reason that I’m assuming that you want to add settings to dimension styles specifically for *annotational* constraints is to be able to apply different dimension variables to them in any dimension style. But maybe I’m assuming too much.
Are you saying that you want to tweak the visual appearance of *dynamic* constraints such as color, text style, and arrowhead style? Remember that they won’t plot and that most other dimension variables (especially scaling) would not apply.
Again, thanks for all your contributions!
Dieter, thanks for communicating our feedback, but there’s absolutely no chance that, for example, mleader styles will start to make sense. It’s way too late for that. The time to ask for, and listen to, feedback on that subject was more than 5 years ago before a line of code had been written. Permanent kludges will be standard procedure until Autodesk gets a Bad Idea Filter expert customer panel in place and drops the 12 month cycle. Neither of those is going to happen between now and the time when we are forced to either commit to the Cloud or abandon Autodesk altogether.
You’re welcome, Steve. While you know that I don’t share your dark view of the future, I’m always available to accept and communicate your input.
Speaking personally, I believe in a hybrid future with more choices rather than fewer. So by analogy, “cloud shopping” has not replaced brick-and-mortar stores, but augmented them. But you’re covering that topic elsewhere.
Do look me up the next time you find yourself in California.
My view of the future is a direct extension of what has happened in the past and what is happening (or not happening) right now. Can’t beat history as the ultimate teacher.
Please don’t complicate what is being requested here by thinking substantial change, to functionality, is being requested, it is not.
Dieter, think of the dimension style manager dialogue box as an interface in which settings relating to the dimension style/type being used can be selected from a list. Sound familiar?
Out of the box when in AutoCAD 2013 dimension style manager has Annotative, ISO-25 & Standard styles. Selecting one of these options allows it to be used, abused & modified etc. In relation to modification or the creation a new style the appropriate tab is selected, the change is made and saved to the style.
(To a user) The machinery in play behind the dimension style manager interface is simply not seen; that is the intention behind using the interface style is it not? The addition of the two parametric dimension “styles” to this list (and that of the properties styles listings) is all that is needing to be done. No need to change that which is driving (at this point – maybe).
This same scenario follows for multi-leaders: their style selection should be from the list in the dimension style manager with their settings being selected from the appropriate tabs within the existing dimension style manager interface.
Again, for a user that which is going on behind the scenes is not of their concern. Their concern rests entirely in being able to learn, use and access similar functions, in a similar manner.
No, I understand what you’re asking and I think I represented your requests clearly to our product design team. Incidentally, having taught AutoCAD for many years, I’m a big proponent of “being able to learn, use, and access similar functions in a similar manner” as you put it. If you have the chance or inclination to pick up Alan Cooper’s book, “The Inmates are Running the Asylum,” do so. I think you’ll enjoy it.