Layout & Drafting: What's the plan?

It is also important to remember the usual reason for wanting to create a 2D representation of a 3D design, no matter what field of design one is working in.

In all of the cases that are being put forward both here and in other related discussions (I think!), that reason and destination is to a human, not a machine. In my experience, Rhino is very, very good at providing 2D output that is destined for e.g. a CNC router or laser. Whilst the vectors that those types of work require could be buried in a conventional, drafted drawing complete with title block, border, parts table etc, a lot of the time the CNC programmer getting their information in that way will give a dismissive sigh and a look to the heavens, before deleting all of the ‘crap’. So very often there’ll be a derivative set of 2D files that aren’t “drawings”, made solely for the purposes of porting information to a machine, not a human.

Anyone who has imported a cross-platform export of a 2D drawing created by the top tier solid modellers like Solidworks, Solid Edge, Catia etc will know that the dumb (by which I mean all of the inferred intelligence of the proprietary format has been lost), pure vector detail contained in them is about as far as one could want to be from a CNC-friendly file. Hundreds / thousands of disconnect, overlapping lines that would cause any CAM package to have a quivering fit. But that doesn’t matter, because it is humans that are the intended destination. Their associative, slick method of making a 2D drawing of 3D objects is alluring and addictive, even if the nuts and bolts of the underlying construction are a mess. But us humans aren’t astute enough to spot that, so that doesn’t matter.

Make2D is an accurate though one-way method of porting 3D to 2D (that also happens to display a few of the traits of the solid modeller’s 2D vector work on occasions :smile: ) but I’m not sure it’s necessarily the right way to solve Rhino’s associativity problem. Something needs to be done to address this core issue though as it is a major obstacle, no matter what the design sphere. It may need to be done ‘wrong’ in order to get it ‘right’. Conceptually, perhaps something along the lines of the old Section Tools add-on, at least as a WIP?


So let’s talk specifics. Sectiontools. So, with sectiontools, what worked right that we need to add to rhino? And what needs to be improved?

And do we have rhino files to show the specifics in each case?

What I don’t understand is the argument that some tools already exist as plugins or as Rhino Outside. If this is a leading argument, then why has McNeel developed numerous rendering plugins? Some of which were clearly wasted resources as they were abandoned quickly.
Yet I feel some essential tools are kept underdeveloped. You say we keep pushing things forward but in terms of page layout and drafting very little has changed in the last decade or so. Or do you perhaps mean by ‘pushing forward’, putting it on the ‘future’ list?
And now you ask what is wrong with section tools. Did you search the forum already on this topic and on clipping hatches? There are many lengthy threads on the subject already that discuss the shortcomings in detail. With numerous people including myself that have tried to make workarounds for these shortcomings, eventually to no avail because there aren’t enough tools exposed in rhino common to make it happen. In all those threads I haven’t seen a developer jump in and say: “thanks for all the efforts and attempts. I now clearly understand what’s missing. I’ll start working on it right away!”
At best it these have been added to youtrack and put on a future list.


The risks of relying on a third party’s plugin to provide powerful (and for many, essential) functionality should be painfully clear to McNeel by now. Many of us are marooned at V5 as a result. They either get bought out by the competition or get left behind over time as the developer doesn’t maintain compatibility with subsequent updates to Rhino.


My example of the old Sectiontools plugin was used in this case solely as an example of McNeel‘s producing of it’s own outlyer plugin to provide additional functionality to the core product, in a way that could be used as a sandbox to develop features (mostly in response to dialogue on this ‘ere forum).

Other examples - Fabfont (a little gem that’s been abandoned), Neon (which served it’s purpose well). There are others that don’t come to mind immediately.

So I chose Sectiontools as an example of the development method rather than the product specifics. However, as has been picked up on, many of the features of that particular product happen to be very relevant to this 3D-to-2D Bridge tool discussion.

1 Like


A first step forward, would be to make Make2d handling clipping planes better:

  • make curves behind clipped surfaces looks like hidden curves
  • fill closed cut sections with hatches
  • integrate these features in the SDK & Grashopper by the same occasion

Without these, producing technical drawings remains a real pain.

These features have been requested many times during the last years:

…but there seem to be no big improvement on that topic (from what I’m aware of…).

I my opinion, this is real basic and useful stuff and should be implemented in the core features of Rhino, and also not rely on some third party plugin, SectionTools, VisualARQ or whatever.


Attached is an example of typical output, aimed at humans rather than machines. NDA’s get in the way of other, perhaps better, examples but we’ll live with it.

Within the working space of the drawing.
(i.e. everything you see that’s inside the innermost line of the drawing border)

Everything here was produced entirely within Rhino and didn’t use Layouts. The reason for that was (at the time) getting output in PDF and a cross-platform CAD standard (usually dwg or dxf) is a must for almost all of the clients I do work for and Layout couldn’t do that, along with (sometimes) a 3D model in STEP or whatever. Perhaps things have moved on, but from recent offline discussions with Pascal about parts balloons there is still a lot of work to do. V6 has more problems than V5, from what I’m seeing and reading.

My work is very varied: Bespoke helical staircases for the building trade, vehicles like the attached PDF, train interiors,livery drawings, Point of Sale, injection mouldings - all kinds of stuff. The above are the universal deliverables and are a core requirement, irrespective of the industry. Please get those sorted before you start on the industry-specific niceties.

Imagine that I’ve sat here for a few minutes waiting for Make2D to trot out the views you see in the PDF. Fine; apart from some parts where it has (literally) lost the plot, I can live with that - perhaps half an hour spent retouching and I’m good to go. Layer control of the results largely works and it’s fairly manageable. I model in the assembly arrows as lines or surfaces prior to Make2D. Exploded views are a pain and have to be manually pulled apart, which means a separate model which then needs to be kept in sync. with the master model. There’s work that’s been done on that more recently and things have improved in that area. I’m not sure if they are fully developed.

Callouts (the parts balloons) are universal. In Rhino, they have to be done manually and are extremely time consuming, especially if you’ve got lots of them and need to move them around to get everything to fit without the leaders overlapping. If you have to move one, the easiest way is to delete the leader, reposition the balloon and text and draw a new leader because it can’t maintain it’s perpendicularity to the balloon. Do that a few hundred times and the novelty soon wears off. A tool to treat the balloon, text and leader as one editable item that maintains alignment would be a massive help. Making it intelligent, populating the balloon text by pulling pre-defined user function off of the item that the leader tip touches would be a step forward. Options to: Have the balloon auto-resize (as an obround) to suit the text; have different shapes of balloons - round, rectangle, hexagon etc - to enable use as a means of identifying types of parts classes; assign these preference to layers. Layers are old school but much maligned in my view. They are extremely flexible and can be used and abused in many ways. They can be all things to all men with a bit of lateral thinking.

Display order: Again, provide the ability to link to Layers. Add a column to the Layers panel where one can assign numerical order to display. A radio button at the top of the column to invert the order, should the need arise. Don’t make it dependent upon their order in the Layer panel. There’s too much other functionality that people rely on in other areas where that is concerned.

Section Tools: Assign sections to sublayers of the objects they section by default. Sublayer for the fill/hatch; another for the section outline. Move the linetype and fill definitions for anything that’s ‘Section’ to a distinct column in the Layers panel, then allow Select All or whatever at the top of the column so that their collective line type, colour and and weight can be set at a stroke, or even turned off. Individual Section layers can still be tampered with to suit the user’s need. Yes, this will make the Layers panel grow considerably, but it would make perception and control of what’s going on a lot easier for us Humans. Make sure that whatever Sectiontools does produces the same appearance in both PDF and dxf/dwg exports. This is critical. Maybe svg too for a little bit of future proofing.

Associativity of the 2D to the master 3D model: The elephant in the room, as @osuire puts it. Imagine I have to change the trailer hitch in that PDF, two months after first issue. And update all of the affected 2D 2D drawings downstream of the GA. Resetting viewpoints (you did save all of the viewpoints, right?), calling Make2D, retouching the missing lines, scaling it and trying to align it with the original, erasing the old item and trimming/extending/reconstructing the surrounding line work to make it all good. If that isn’t enough to make you break into a cold sweat, then you haven’t understood the problem. Then the supplier calls a week later and tells you that hitch is no longer available…

Then there’s the stuff outside of the model space: Parts tables, title blocks (work on that is coming along well), export of BoM to Excel. I’ll have to come back to those as I have (paid) work to do.

Chassis 17Feb11a.pdf (992.8 KB)


Slight tangent, but apart from basic hull lines, does orca3d provide other drafting capabilities?

All this should be obvious to devs working on a modern CAD tool, but I still read the occasional “could you be more specific about your needs with regard to drafting ? We will do our best to bla… bla… bla…”.

The problem is that Make 2D is just not the proper direction. It can be polished at it wants, it will never reach the reactivity and robustness of hidden line view computation as has become standard for the past 20 years.

When I saw the “Technical” display mode arrive in Rhino a few years ago, I suddenly had a glimpse of hope as it seems to be the same the approach used elsewhere.

But it just falls short :

  • Many missing edges
  • No way to print to PDF as vectors, or export to DWG for that matter
  • No useful hatching of sections (no need for gradient hatches, the run of-the-mill ones will do !)

My guess is that the others manage to leverage the mesh edges and silhouettes computed by the algorithm in a smart way, projecting them instantly on a virtual plane, and converting them in into simple entities when relevant (circles in particular).
This makes it possible to snap to silhouettes, (and even to section edges !) and to export the views as vectors.


My understanding is that the parametric modellers do not work this way. They cheat by using the feature sketches for the drafting results, hence why they are far more developed than Rhino can produce from a “dumb” model with no sketch based feautures. I might be wrong though.

This is obviously wrong, the simple proof being that many people export “dumb” geometry from Rhino to these tools, expressly for them to make projected views.

By chance, all the workshop drawings for our steelwork are done by our sub-contractor this way : we send them STEP models (which get imported as parts /assemblies since we use nested blocks), and they do all the drafting with Inventor or similar.

reminds me of the old Autocad command ViewBase hardly anyone knows about. Great for quick hidden line perspectives and hatched sections.

exactly, and (SW) produces these 2d drawings instantly vs extreme slow make2D

1 Like

And, of course, there’s this lovely thread:

How many of the requests made in that one have been addressed?


I think the message, that Rhino currently is not fullfilling the needs of people who would like to do 2D Plans has come accross.

The main problem, is not the fact, that you can’t create 2D drawings, but the fact, that it takes to long to create and alter a 2D drawing to make it presentable.

I personally believe, that the “AutoCAD” approach with layouts and mixed Files with 2D and 3D Data is not a good and clean solution. Most of the software packages got rid of this approach by now.

I believe, since a 2D Drawing in is derived from 3D, the approach Inventor or Solidworks with a clear seperation between 3D Model and 2D drawing is a good thing - a .2dm File with an assosiation to a .3dm File would be something I’d like to see.

In an effort to get rid of 2D Plans completely in the workshop, it would be great to support the PMI capabilites of the STEP Format.



but as was mentioned above, these programs still need extensive cleanup to go to a typical cnc machine.
and are extremely restrictive. In rhino/gh you can quickly generate 1000’s of accurate clean drawings that programmers love as well as the documentation. Really not even a contest.

Generally Dimensioning is hard to automate - possible but hard.

So what you are saying is correct, as long as the demands on the drawings are not “too” high, and the geometry is somewhat similar.

Once you come to the point where parts are very different from each other, and dont’ follow similar geometric rules, dimensioning thousands, is quite hard to do with GH.

1 Like

I do not know every feature, but it is an example of storing the process to refresh the drawings. Saving which surfaces are hull, station/waterline position, names and layers etc for quicker updates.

STEP 242 standard looks very interesting. Thank you for that link :slight_smile:

@DanielPiker Is there anything in there that Rhino can jump on? I’m thinking about your sketch constrainer, or whatever you want to call it, here. I think you might get a few user’s attention if you can send models to someone with Solidworks etc and they find that the model comes complete with inferred PMI.

I also like the idea of a .2dm format, especially if it could pop open in a floating viewport when prompted.


Oh, I’ll have to try that. But my experience of SW models of boats is that it doesn’t produce useable drawings. There’s too many “artistic” decisions to make. For example, a simple section of a boat model is useless, too much information is missed or included. Adding depth to the section doesn’t help. The drawing is a representation of the design to describe it to humans, not an exact detail of the 3D model. I suspect architecture drawings are similar. This is the crux of the problem we’re discussing, how to program a computer to streamline the decision making.