Rhinoceros replacing AutoCAD

Thanks, all, for chiming in.
A review of existing items in YT shows that this wish is recorded several times already. Most of these are only visible to the developers. Here is one that sounds like it covers what is requested in this thread - RH-12718.

1 Like

the ability to add different dimension styles to different layers would also be a great addition :slight_smile:

1 Like

Copy-Paste, huh? :wink:
Have you used the test command in the Rhino 7 WIP? That should be a step into that direction…
Please add your comments about that command and functionality in the original thread:

We are testing Rhino 7 mac Beta and are more and more happy with the funcitonaliy.

The only downturn point is speed. Drawing in 2d is still slow and laggy.
You just need some floor plans and hatches and the system slows down immediatly.
I think for being able to replace Autocad now (2020) the most important thing for Rhino is to be just as fast and smooth as possible. It has gotten better and better over the last months. I hope it keeps improving.


I’ve been V7 Beta over the last couple weeks on a live project, it’s definitely laggy with 2d geometry created using Make2D, once I add a couple of threaded fixings it really struggles with Make2D, and then dragging the curves created with the Gumball is painful 🤷

1 Like

I did not notice any difference in performance if the 2d geometry was generated via make2d, drawn directly by curves, hatches and dimensions or imported via dxf/dwg.

@milezee and @OXII There are a number of variables that can impact display speed and performance in any version of Rhino. Could you make new posts to the forum with a sample model, the steps before if becomes slow for you and include the results of your SystemInfo command in Rhino? If we can reproduce the issue we have a good shot at improving things or may be able to offer a settings or configuration change suggestion to help.

1 Like

Dear Brian, I can send you a new AutoCAD reference file for your testing if you want. We have seen consistent imrovements in display speed over the last versions, let’s keep improving. We are now using Rhino mac 7.2

Dynamic blocks are grossly overrated.
You can use free program called tinySpell. tinySpell corrects your spelling while you type text inside any program.
You can trim any hatch - this is new feature of Rhino 7.
Hatches may have transparent colors - this is new feature of Rhino 7.

BlockAttributeText is a text field that is used as block attribute - this is new feature of Rhino 7.

I am former professional AutoCAD user. The only thing I miss is AutoLisp. (Lisp is the only programming language which does not stink.)

“Lisp is a programmable programming language.
Not only can you program in Lisp (that makes it a
programming language) but you can program the
language itself. This is possible, in part, because
Lisp programs are represented as Lisp data
objects, and partly because there are places
during the scanning, compiling and execution of
Lisp programs where user-written programs are
given control. Contrast this with the C compiler,
where the only user input to the compilation
process is the ability to define macros that do
simple string transformations on the source code.”

John Foderaro (in September 1991)

“C++ template programming is to… Lisp
macros what IRS tax forms are to poetry.”

Christian Schafmeister

“Lisp is a programmer amplifier.”

Martin Rodgers

“If I had a nickel for every time I’ve written
“for (i = 0; i < N; i++)” in C I’d be a millionaire.”

Mike Vanier

As student I have worked with AutoCad and remember the large and unoptimized amount objects, some dwgs contained, with the tendency to store way more data as required in one single file.

Later when working with Catia, I noticed that Rhino in comparison has problems with loading and displaying large sets of data. While, on an average industrial CAD Workstation, you can load a complete (real) car model, including all technical components within Catia, Rhino couldn’t even do the same with a 10th of the data.

While I’m comparing Apples with Oranges now, I just like to add that Rhino indeed is not fully optimized when we talk about data and rendering performance.
However, as it has been said by Brian, issues could arise from so many other points. Just alone the fact of being on Mac instead of Windows, or maybe having unlucky hardware specs, can increase that problem.

Not only the amount, but also the quality of data could be a problem. E.g. By accident a circle could be imported as polygon or a heavy Nurbs curve, while you usually would represent this much lighter. Dashed lines could be evaluated as single curves etc… Repeat that for thousands of objects and you break it.
So there are many things which can decrease performance rapidly if there is something not done correctly by the user, which has nothing to do with the App itself.

But, CAD is nothing new, and people could do their jobs decades ago, so the question is also do you need to work on large data sets, or could you decompose and recompose files after editing them? And how does it behave then? At some point, things have to be made different to your old habits, but unless you are not missing vital functions, I would definitely see if you can bypass current issues, by adapting to a slightly different workflow.

Of course you can decompose drawings you get, the issue is that it takes time. It would be better if you can open directly the dwgs they send you and correct or manipulate them. Just like they do on their computer. Often you get dwgs in the size of 20-40mb which contain technical plans of several stories, details, hatches dimensions and contain quiet some set of blocks.

Having to decompose all the time works but is just inefficient.

1 Like

There are many free 2D cad softwares similar to Autocad

The biggest issue i have with replacing Autocad with Rhino is DWG import/export. I need to exchange DWGs with consultants, and i cant send them drawings with a wrong annotation or hatch scaling. This would have to work a 100% without me checking drawings in TrueView constantly.

Another thing is performance with big 2D DWGs with a ton of linework, text and hatches. Works fine in autocad but its slow in Rhino.

I would also miss the sheet-set manager. For projects with a ton of sheets its quite error prone and easy to miss a sheet, the way the current Rhino layout panel works(but nice that its finally there at all).


i also thought i would replace autocad with rhino but it is not possible for 2d documentation because: no xref clipping, no dynamic blocks (windows doors), dwg export destroys annotation formatting, no batch plot, no advanced annotation tools. The best combo for smaller aec jobs seems to be Rhino for 3d and Brics for 2d which is 4 times cheaper than acad lt


I think a mix of CAD is probably the best solution anyway. The question is always, does anyone need the full potential of an expensive CAD system, or can you use floating licenses and use these features on demand. Usually the price of a CAD system is justified, usually the more expensive the more specialized tools you get. This way you save up money by reducing drawing time (in theory).

Regarding Autocad, I remember dealing with reference images and associative parametrics was also something I missed in Rhino, although for both features there are simplified equivalents available.

But my experience is also that many users are extremely picky, arguing for not to do certain work in a different system, just because of preferences. The advantage of using specialized CAD daily makes only sense if you really need that feature all day. If a dynamic block can be replaced by copy-and-pasted-and-history applied shapes in Rhino, or if you change a dynamic block only once a week, its questionable if these extra features are worth to have.

But of course, its always up to what you are doing…

As a fun fact, I remember using Rhino to cleanup .dwg files occasionally, since it had better selection tools than AutoCad (10 years ago) + the ability to code such things. Many files being received from other offices or governments were actually absolute messy. Could be that they this changes and probably differs from country…

Since Rhino 7 mac is out, we’ve got already most of the functionality. We have layouts, detail views, hatch transparancy, hatch trim and so on. All tools with which you can draw your execution drawings for buildings and interiors. And do your building permission drawings. I actually prefer drawing 2d in Rhino, since I can do everything with one software now, which safes me time and effort.

The most important tasks for Rhino 7 mac as of January 2021 in my opinion are:

  • imroving display speed (once you have many hatches, lines, cuvres, blocks, dimensions - the classical execution drawings for buildings and furniture which get realized) the software becomes laggy to zoom, click and pan. Meanwhile Archicad or AutoCAD can handle the same amount of curves just fine on the same mac
  • supporting AutoCAD dimension scales, linetypes, hatches & layouts
  • supporting AutoCAD dynamic blocks
  • support of xrefs (external references)
  • batch print of layouts

When we all togehter can make that work well, I think many software developers will start programing plugins for architecture & furniture, since Rhino is a great base.

Rhinoceros is an insanely great piece of software, thank you McNeel for all the years of giving us such a great tool to work with!


I’ll second the dynamic blocks. Pretty much every auto cad file I have has hundreds of dynamic blocks and I (we / the company) use them for pretty much everything. They’re in all our schematics, elevations, floor plan details, they’re all over the place. That is the single thing that’s precluding me from using Rhino for day gig work stuff, because trust me, I have no love for autoCad. At all. There’s bugs there that have gone unaddressed for literally decades. On occasion we need to send stuff off to GC’s and Architects, etc, but for the most part our output is for our field techs and installers, and they’re just looking at PDF’s of the prints. Stuff could be in Visio for all they care as long as the information is there. However because there’s so much replication, we tend to cook a dynamic block the first time we have to drop in some 3rd party device just so we don’t have to do it again. That then gets shared with everybody else to minimize repeated overlapping efforts, so while the block authoring mechanic in AutoCad is pretty horrible, and can be really difficult to understand at times, once cooked, they DO work, and because of that we utilize the hell out of em.

If Rhino had the ability to read & resave them intact, that would be a huge step forward.

If it had the ability to author them (in a less kludgy fashion than AutoBad) that would be absolutely stellar.

Finally a similar functionality in Rhino even if it didn’t play with Autocad would really be useful.
Hell there’s one furniture manufacturer who does modular built to order stuff for entire buildings, and every single widget they have is a dynamic block. There’s a reason those things exist, and a reason the dynamic blocks exist by the thousands in this case if not more.


We have a mixed environment in our architectural office. ‘Traditional’ AutoCAD, Revit, and Rhino.
As much as I personally would love to work solely with Rhino, many colleagues are ‘veterans’ that are still used to an AutoCAD workflow. Also, we still exchange plan data with contractors as .dwg. So, looks like ACAD is going to stick a little longer. (Revit is another story - genius and madness. The situation might improve now with RhinoInsideRevit)

There’s a grown workflow with ACAD here, which is pretty sophisticated, with custom tools and all. Which does not mean that I like it - I am relatively new to the company and fortunately never had to deal much with all this. I try to stick to Rhino, and I advocate it to those interesed.
I’d love to tell everyone how obsolete ACAD is, and replaceable with Rhino. Yet admittedly, there are still things that simply work not as good.
It’s really cool that Rhino7 now has hatch trimming / transparency, so things are improving. One remaining problem is performance!

Speaking of which… there seems to be a bug In Rhino7. Here’s a 41MB .dwg for testing:
(file is above 20mb limit - does this onedrive link work?)

It’s a city map from the municipality, something we have to deal with regularly. Opens in ACAD in 20sec, and can be panned/zoomed smooth as butter. In Rhino7, it takes minutes to open, and bogs down Rhino pretty good! A colleague had the same problem with the file on another machine.
This can’t be right. Can you have a look at it please?

Interestingly, it can be opened faster in R6. Viewport performance is workable, but 10x slower than in ACAD.

My specs at home (short version): i7 3770 (yeah, old), 16BG ram, nvidia RTX 2060 super.
In the office: some newer 6-core i7, nvidia RTX 2070. Pretty fast machine, but still this scene is more or less unhandle-able in R7. Drivers are pretty up-to-date.


1 Like

Rhino since V4 has always been slow with huge 2d dwgs ( Floorplans of airports etc…) In cases where we were importing huge dwg to prepare our own production plans: Hide or delete all hatches. Hide or delete all blocks you don’t need for your work…

Worst dwgs I have ever seen were Catia dwg outputs of cruise ships (all floorplans of 13 decks in one dwg…)
With Grasshopper there are some ways to get something similar as dynamic blocks…


I think from a programming point of view, dynamic blocks are feasible. I didn’t know the feature, I guess it’s “relatively” new in AutoCad. As far as I can tell from watching tutorials about it, it basically allows you to add transformations to a block definition at several locations, with the ability to create custom handles for this.
I think you can recreate similar behavior with a mix of history applied geometry and a fluent use of the transformations commands in Rhino. So there is a workaround, but of course not as neat.
I guess creating a 3rd party plugin would also be possible. Would probably be a useful feature. Not only for 2d, but also 3d. Think of screws etc. Currently I create them by script, which is an overkill somehow.

The performance on the other hand will remain a huge problem. If you want to address that, it probably requires a lot of changes to the Kernel of Rhino, which is unlikely to happen. But who knows that…