On a general note:
I’ll celebrate the day when Autocad vanishes from the face of the earth (which I doubt I will live to see). There’s nothing likeable about it. It’s a living corpse, that still exists for one reason only: it became industry standard decades ago, and now it gets moneymilked by Autodesk, and there’s no probable version of reality in which it will get ergonomic and modern.
How would you ‘modernize’ a program laid out originally for 2D work anyway? BIM/3D programs like Revit or Archicad are just this, and even if they are around for decades already, no common ground has been found for modern, flexible file standard / scene description.
IFC? USD? Those are still not there, and support for 2D (non-physical objects) is lacking.
Interestingly, the DWG format is best at exactly this: 2D content. (whether producing 2D content from 3D scenes still makes sense is another debate).
So, the DWG format sticks. For legacy reasons (access to countless old files), and for lack of a better alternative.
Rhino needs to support it. Because it’s standard, and because Autocad should be sent to hell…
Unfortunately, most of your points are true.
With ‘we’ you mean McNeel, right?
-
XREF management:
We have worksessions, and inserted/linked blocks. It’s indeed confusing to understand the (subtle) differences, and there is potential for simplification/unification here.
But it must come from McNeel. I doubt that a plugin/script solution would even be able to ‘reach down’ that deep into Rhino’s system.
-
Layout and sheet management.
Oh yes! I’m using R8, and have to export dozens of layouts to PDF for a project. The print dialog has improved allright, but still there are enough shortcomings (bugs even - will report), when it comes to exporting multiple layout pages.
-
The print dialog does not even remember the last file path, as of now! (I should post this more prominently). Nasty!
-
We need ‘publishing sets’ (a term from Archicad, which is pretty good with these things) - kind of layout groups that can be exported in one go, but with different file formats/page sizes/file paths, if needed.
-
The ‘Layout’ panel -
and this new layout list in the Print dialog -
are actually unnecessary doublets. I’d say those hypothetical ‘publishing sets’ should be definable in the Layouts panel (by introducing classic folder icons, and checkboxes next to it to define what gets exported), along with properties for file path/format etc. The Print dialog would then just exports what has been ticked in the Layouts panel.
-
Annotation
Never needed to annotate that much, but what I did need many times were blocks that can live display their own coordinates!
-
Block management
I just… just cannot fathom why McNeel shows so little interest in pushing hard in the ‘dynamic block’ direction. There are even 2 plugins out there that can encapsulate Grasshopper scripts in dynamic blocks (APE, VisualArq), but this must come out of the box!
It should be possible in Grasshopper to introduce viewport UI elements that can trigger different block states (just like in Autocad), when the GH script is embedded in a block.
Another advantage of Autocad is worth mentioning: it’s parametric. Create a circle, and you can adjust the radius later. With this system of GH-powered blocks, this could become possible here, too.
Some progress has been made here in R8. Only the active block state is imported now, not all variants.
- Compatibility
100% won’t be possible. I don’t believe there ever will or can be compatibility between Autocad and a potential Rhino/GH dynamic block system, so just go for a solution that works in Rhino, and forget about full compatibility.
However, if draw order came across in the DWG format, it would be great.
.
