Technical drawings - Is LAYOUT the best way?



To revive an old thread…

I’ve just watched Mary Fugier’s Vimeo vid on Layouts which is excellent for understanding the work flow and UI.

As said above, I currently don’t use Layouts, but have always felt I was missing out on something. The associativity of a 2D drawing to the 3D model is alluring. Unfortunately, Mary’s tutorial doesn’t cover a very fundamental aspect: Depicting traditional 2D technical drawings - i.e. all line drawings, no shading (except for hatches and the occasional solid fill), no isocurves (unless requested), the option of hiding/hidden lines, and all savable in vector format to PDF and/or DXF/DWG such that the two/three formats look the same.

Is there an online tutorial that covers this, or is it simply not possible in Rhino? Is Make2D still the only way?


Matt, I’ve been trying to do what you’re talking about on my current work project. To accomplish this I’ve been using a pair of opposed clipping planes to show only what I want shown in the detail view, and then displaying the detail view using the technical display mode.

My biggest gripes with this (which may hold some people back, depending on what is being modelled, and your preferred display/print modes) are:

  1. The intersection of the clipping plane and the objects being clipped can only be displayed as the colour of the clipping plane or a single solid colour (for all clipped views). I would like to be able to use the colour of the clipped object, but this doesn’t appear to be possible for now.

  2. The technical display mode often leaves artefacts of hidden objects in the detail view, which requires a restart of rhino to clear (and that doesn’t always work)

  3. You cannot easily get a 2D dwg/dxf of each sheet., including the objects from model space flattened to layout space. That would be amazing if we could get that, but i’m not holding my breath. Currently, you CAN save as dwg and the layouts come through, but differences in the way annotative text etc is handled means that the text could be off. Also, it doesn’t appear to remember the state of layers in detail views, so you’ll probably get everything turned on by default and have to manually reset each viewports layer states :confused:.

Here’s what my drawings look like:



I have am currently using a similar approch for some mechanical parts.
I have created an assembly where each part has it’s own layer, such that I can have a layout for each part, and a layout of the assembly by switching on and off layers.
This mostly worked as I want, however using the Technical view (as noted by Iain above) some hidden objects still appear.
The image below is one component (currently in the perspective detail), all 4 details have the same layer settings, however the pin is visible in the technical views.
Looking at my file, it seems that objects sharing the same plane do not behave.
Would be great if this was tidied up.


Lain, that looks great!

I suppose your in Shipbuilding to?

For small assembly drawings this works super, but when you have 50+ frames, the 100+ clippingplanes combined with technical views, is getting slower and slower.

Besides this, if you have a curved hull, the clipped detail will have multiple curves of one plate… a section would be more clear on the drawing. Or did you already figure this out?

Al the customers work with the dwg format, so this would be awesome indeed.

For now we do all the 3d modeling in rhino and create the drawings in other programs.


What happens if you:

a) Save the layout by printing to PDF
b) Save the layout as a 2D DXF or DWG (and how do you save it to this format)
c) Compare a) & b)

Do they look the same?


Hi Iain - this is my major gripe. Layouts seem to be focused on getting something that can be printed, not exported.


Your issue appears to be the same as mine, where artifacts are left in the technical views. Pascal has logged this as a bug (see here).

For the moment, I’m am just living with it until I come to print my layout. If it is not displayed correctly, save the file with the layout page open and then close the file. Reopen the file and the problem should be gone for the moment, allowing you to print correctly. Works about 80% of the time. Hopefully this will get fixed in the near future!


Yup, I’m in shipbuilding

I haven’t figured this out fully but have been thinking about it a lot. The pairs of clipping planes has its issues as you have identified, and cutting sections also has its issues ( to show objects on the near side vs far side of a bulkhead, how to make sure lapped brackets show up etc.)

I think that the solution for ships lies somewhere in a hybrid solution, the hull by cutting sections (e.g. with section tools), and show the internal structure as modelled in 3D using the technical display. To do this, cut your hull section, and put the section on a new layer. In a detail view, turn off the hull layer and apply clipping planes to show the section and structure in question.

As for managing clipping planes, I keep my clipping planes on a layer (or groups of layers) to only show the ones I need at any time. The clipping planes will still work, even if the layer they are on is turned off. Also make sure that the clipping planes are only applied to the detail view they are affecting. I find that if you duplicate a detail view, any clipping planes linked to the original detail view will now also be linked to the new detail view.


(a) I get a lovely PDF of my layout :smile:
(b) I get a lvoely dwg/dxf of my layout, minus all the content from the detail views. Oh, and all my dimensions are fubar’d. :confounded: If I save the whole file as a dwg, then everything is there, except all the views of the model are in wireframe, and the dimensions are still fubar’d. And by fubar’d I mean that they measure in paper space, not model space, and they are HUGE compared to all the other text on the page. It could be useable if you wanted to spend the time cleaning it up, but at that point i’d be as well doing the whole thing in AutoCAD. Oh, and it still doesn’t solve the whole 3D vs 2D thing (where we want to work in 3D but present only 2D to the client).
© They’re not really comparable. (a) is presentable to a client. (b) is not.


When you say:

do you mean that all you can see are the borders of each detail, with nothing inside them? How are you saving/exporting the layouts?

I think I’m seeing the same as you, but want to make sure I understand your description correctly. Rhinos term ‘Detail’ to describe an elevation or view is confusing and ambiguous to me. Is it the correct (American) term?

I’m surprised this thread isn’t swamped with people making similar complaints/queries, as this is a very basic, fundamental flaw. Perhaps no-one’s using Rhino for production drawings?


At this point, using Rhino for production drawings is, well, not productive.


I tried selecting everything in my layout and using ‘export selected…’. In my dwg file I got all the paper space content, but nothing appeared in the viewports/detail views

When I used ‘Save As…’ dwg, I got the complete model (model space and paper/layout space)

In both cases the dimensioning was fubar’d.

I am using the term ‘Detail View’ in Rhino to mean the same as ‘Viewport’ in AutoCAD, as these are the terms used by the software. I agree that there should be commonality of these terms between software (i.e. model space, layouts and viewports)

(John Brock) #32

Perhaps a little historical perspective is in order here…

Rhino was never intended to be a product drafting application. Early Rhinos had little or no drafting tools at all. At that time there were good tools intended for production drafting and still are. Why would we spend our time writing tools that already existed?

Rhino was never intended to be a mechanical modeling application either. Same arguments. There were and still are great mechanical modeling tools.

What didn’t exist were good, affordable, industrial design surface modeling tools. That’s the need Rhino was and remains intended for.

As Rhino matured, there were tools we could add that would address the simple needs of some people that needed in-house drawings. In this way Rhino was made more useful for some people that weren’t strictly industrial designers.
This addition of tools has continued for many years now but the fundamental direction of what and who Rhino is intended for has not changed.

Perhaps the number and usefulness of some of these tools have left some people confused that Rhino is not a good production drafting application. It was never intended to be one.

We will continue to add tools that extend the broad reach of those that find Rhino useful, but at it’s core, Rhino remains a NURBS surface modeler intended for industrial design and product styling tasks.

I hope this helps.


But what percent of Rhino users are using it for this “core” purpose.

Almost every architecture student now leaves professional degree programs having learned Rhino first and everything else second. Grasshopper is like a gateway drug, pulling them in by the thousands. It is an opportunity to leverage the incredible popularity of parametrics to make Rhino the truly robust output machine it could be.

this seems like an inflection point for the product, I would hate to see you guys miss it.

(John Brock) #34

So you’re suggesting we abandon our core Rhino customers and instead focus on the architectural design market instead?

I think we’ve had this conversation before…

I all seriousness, the best route would be for a third-party developer to use our SDK to write tools to better service the architectural market. There are some now. These can be found in the Architectural category on the Rhino Resources page.



I don’t see anything written on the Rhino wrapper saying “BTW, the drafting tools we’ve included aren’t to be taken too seriously”. Looking at Iain’s drawing above, I certainly don’t think he considers Rhino unsuitable for such a task.

Technical drawings are technical drawings, regardless of the sphere in which they are produced. Rhino’s strength is that it is a Swiss army knife of a tool; it’s not pigeon holed to a particular discipline. Outputting information from Rhino in a widely acceptable, cross platform format to communicate one’s ideas should be a given. PDF, DXF and DWG are three such formats, for 2D communication at least.

(Bob McNeel) #36

We are try to improve the drawing tools in Rhino with each new release. @lowell is focused nearly full time on those issues. He can tell you more about what he is currently working on.

(Lowell Walmsley) #37

Is my understanding that this is a lot more about exporting to Acad than getting something to look right in Rhino?

The logic of that is that you got what you selected, which didn’t include model space objects. We can argue about whether that’s the way it should work, but that’s the reason now.

I read somewhere else here your definition of fubar’d dimensions.
As you see, it doesn’t work to export Rhino layout (paper space) dimensions to Acad.
What I have found to work pretty well is to zoom your layout to the scale you want it and lock it, then dimension in model space within the detail - In the layout, double click in the detail to get into model space within it and draw dimensions there.
You can use detail visibility of layers to show particular dimensions only in the detail you want them in.
Then when you export them, they will measure the right sizes.

I can understand that your first choice may be to dimension in layout space, and this is meant as explaining an alternative way that you can get something out the other end.

What is the main reason you want to export to Acad?


Rhino is a fantastic tool, and I’ve been using it for the last 10 years. I love it because its so intuitive to use, and avoids many of the difficulties that other packages (e.g. AutoCAD) present when working in 3D. As @MattE says, it’s flexibility is it’s strength. However, I also see @John_Brock’s point about developing specific tools for specific industries - don’t do it. Let people write add-ons for that. One of the pitfalls of big corp software is the huge amounts spent tailoring features to specific user groups - there are so many features available in AutoCAD that I simply never use. All these additional features drive costs up for the end user.

In Rhino, I only want to do two things - model objects, and present the results of that to the client. And with the tools and functionalities that are in Rhino right now, I can do that. Sure there are a couple of bugs here and there, but who hasn’t used software that has bugs in it? That’s why we’re here at :wink:

One thing I would argue that people are doing is finding new ways of doing things that haven’t been tried before, and Rhino provides a great platform for doing that, due to its flexibility and the ability to develop so many tailored add-ons. This kind of environment also helps keep costs down, as you only pay for the features you need. (I’m not an Architect, so I’m happy I don’t have to pay for the architecture add-ons :smile:)

As for additional features, being able to export into a set of 2D autocad layout sheets would be fantastic; however it is not something I desperately need.


@lowell, What we want to achieve is to have 2D drawings in autocad format to provide to clients, as that is something they sometimes request.

Think of printing to PDF file, then convert that PDF file to a DWG file, and you’ll be close to what we want - we don’t want to give the client 3D models - that’s our hard work and our bread and butter - but we do want to give them drawings that the can e.g. measure dimensions on.

What I have seen other software do is to produce literally a dxf of the paper space (so that what is on one Rhino layout sheet appears in the model space of a single dxf file, with all the objects visible from Rhino detail view flattened onto the paper space too. The model space objects in the dxf are therefore drawn to scale (not 1:1)

Q14-9913-LAY000.dwg (2.1 MB)

Another option I have seen is to produce similar to the above, but so that the model space objects are drawn 1:1, and the layout border, text etc is scaled to suit.

As for my dimensions being fubar’d, this is the technical term to concisely describe not correctly importing/adopting an AutoCAD dimension format. Can the Rhino Annotation format be translated to an AutoCAD dimension format? I can see there being some challenges with this when you start to think about annotative scaling and so forth.

As for the dimension measuring in paper space rather than model space, I see that it would be difficult to maintain the association of the paper space dimension to the model space object - however, could you not apply an AutoCAD ‘dimension scale’ to the dimension, based on the viewport space it is linked to, as part of the export process? I can see how this export to dwg process is so complicated.

Going back to the file I provided above, I think the analogy of ‘printing to dwg/dxf’ would be a simpler route to produce the above file type. Text is text and everything else is just lines.


Funny you should ask that, as I’ve just been looking back through work for past clients to illustrate the point.

Of the past 11 clients that I’ve produced work for, 8 have had the following as their deliverables (I’m just talking about CAD formats now):

2D Technical drawings of a standard suitable to pass to a supplier for the manufacture of the items in question in PDF and DXF formats (some ask for DWG instead of DXF).

7 of them also asked for 3D CAD files of the assembly in their own format (i.e. the same as the CAD package that they use (typically Inventor, Solidworks etc) OR a cross platform format, so I give them STEP files.

Of the remaining 3 clients, one is a native Rhino user and they only ever want my Rhino files (no need for drawings) and the other two were start-up businesses that didn’t have a clue about CAD, so I could have given them something drawn on the back of an envelope and they’d have been none the wiser.

My work covers a very wide range of disciplines from high spec steel helical staircases for large private dwellings, to injection moulded parts, to railway vehicle interiors, to medical equipment to, well, you get the picture. So my output covers a number of different industries; no matter what the sector, a very large percentage of them want 2D drawings - in PDF so that the non-techies in the business have something to look at and clean CAD drawings for them to actually get the stuff made. Because I’m not usually supplying direct to the manufacturer, they want formats that are portable so that they can change suppliers at will and still expect the same product in return. This is why I disagree so strongly with @John_Brock 's assertion that this is a ‘specialist’ aspect. You can speak the most brilliant language in the world, capable of expressing things that no other language in the world is capable of, but if nobody else can understand you, what’s the point? It’s all about communication of design and design intent, often to people that you have never met and never will.

I have made production drawings in Rhino that number well into the 1000’s. Rhino 4 was the breakthrough that made this viable. Before that, I had to move stuff over to some horrible release of AutoCAD that made my skin crawl every time I used it. On each occasion, going back to Rhino was like coming home. But I have NEVER produced one of these drawings using Layout, because it can’t depict things equally in PDF and DXF/DWG formats. Make2D and all of the post process aggravation and clean up that goes with it has been the tool of choice, along with the depths of despair that brings, every time a client asks for a design revision. I would LOVE to be able to use Layouts and the associativity that brings. Because of the above, it’s simply not viable. It is the Forbidden Fruit.

If this comes across as an impassioned plea, that’s because it is.