Thank you. As support for dynamic block parameters and block attributes improves, it will greatly enhance AutoCAD’s “BIM” capabilities.
When building a systematic workflow, encountering exceptions is common. Grasshopper struggles with exceptions—it often requires adding more and more patches to handle special cases. This is where combining it with CAD block attributes or parameters helps, because the block can take on part of the exception-handling.
For example, when modeling a curtain wall, you can use Grasshopper to generate the grid, then use dynamic blocks to populate the panels. The dynamic blocks themselves can switch between an “open” state and a “fixed/locked” state. This gives you both efficient grid layout and the ability to make manual adjustments when needed. If you’ve used Rhino.Inside.Revit, you’ll easily understand what I mean.
And even if we ignore all of that, for people whose primary workflow is in AutoCAD, having one more automation capability is obviously meaningful. It may feel redundant or not valuable to you because you already do everything in Rhino, but that doesn’t mean it has no value for others.
1 Like
Hi @Pan_Cheng ,
So you can’t show any picture, video, article… of dynamic blocks automation implementation? Not related with Grasshopper-Autocad Inside. It can be anything.
We just got from you: your textual assumption of what potentially maybe probably could be done.
I am amazed by this sentence. This is definitively not true.
Rhino + Grasshopper combo, by its capabilities and speed of implementation exceeds anything on the software market, when it comes to facade production industry.
The facade models in the video below are production-ready, with every hole and milling necessary.
There are plenty of such examples online, just google it:
Have you used Rhino before? Any geometry in Rhino has the capability to assign and visualize parameters via UI. It is called Attribute User Text.
Autocad lacks this functionality. You have to make a dynamic block, in order to get access to parameters in UI. This is a huge downside of Autocad - just to assign one simple parameter text to any geometry, you have to make a dynamic block out it. Otherwise you will not see that parameter in UI.
So your whole benefit of using Autocad is to create some very simplified grid model of a facade, with a couple of lines representing element facade units/profiles/glasses/coping axes… With few dynamic block visibility states and parameters added to them? That’s it?
You have no need to use Autocad for that. All of that can be easily achieved with Rhino+Grasshopper.
For parameters, just use the upper mentioned Attribute User Text. For visibility states, just define such functionality by reading a specific user text.
If you are afraid that you will make spelling errors in your user text attributes when you defined them manually: you can make a simple check for that inside the grasshopper with Match Text component.
Plus in addition, in Rhino+Grasshopper: you would be able to add real 3D production-detailed geometry to those axes - which you would not be able to do in Autocad, due to limitation of its old geometric kernel.
You did not even read my first comment in this topic, to which you decided to reply:
djordje:
functionalities you mentioned already exists in Rhino, without the need to use AutoCAD:
…
So my question is not what AutoCAD gets by getting connected to Rhino + Grasshopper. This is obviously a benefit for AutoCAD.
The question is: which benefit Rhino + Grasshopper users get, by having a connection with AutoCAD, that already does not exist in Rhino + Grasshopper?
Up until now, you failed to provide any meaningful reason.
Alright, I admit my reply didn’t actually address your question, so I used the wrong example. In fact, what you do with Rhino + GH is also what I’ve been doing all along, and I’ve already completed many complex freeform curtain-wall projects very successfully.
What I really meant was the second half—its value for people who work primarily in AutoCAD. So on that point, we can stop arguing.
As for your original question, I’m almost certain this tool won’t add much to your workflow. But I’m not sure whether you ever need to produce pure AutoCAD curtain-wall shop drawings—especially in situations where you have to collaborate with others. That involves company drafting standards and templates specific to the AutoCAD environment. With GH for CAD, I believe it can still be valuable in that context. I’m just not sure whether you would consider this a complement to Rhino + GH.
1 Like
Yes, of course, we all started with Autocad drawings.
For the company’s drafting standards:
The beauty of Rhino is that, it implements plenty of Autocad’s 2D drawing features.
@Kyuubimode already mentioned replicating Autocad’s print widths, linetypes.
You can also define the same Layer names in Rhino, as the one already required when working in Autocad: glass lines go to “Company_Glass” layer; insulation to “Company_Hard_Insulation”…
(Offtopic: Rhino’s nested layers are a huge plus, in comparison with Autocad’s flat layers hierarchy).
As for the dimension styles, you just need to open in Rhino one Autocad dwg created file - which already has required company’s dimension styles. Then save that Rhino file as template. In this way, every time, when you create a new file, those same Company’s Autocad dimension styles will automatically be available in Rhino.
The frame (rectangle) for the drawing and the drawing table (drawing number, designer name, project name…) in Autocad are a dynamic block. In Rhino, you would have to explode it, and replace each dynamic block’s tag with just normal text.
This needs to be done once, for few drawing frame formats (A3,A4) or scales, and then you can reuse that frame afterwards to create Rhino shop drawings.
The only downside until now of using Rhino+Grasshopper without Autocad, was vast collection of fasteners as dynamic blocks in Rhino.
But with some free time and good will, these can be created, as individual blocks in Rhino.
There is also a Rhino plugin which contains a library of such fastener, anchors, profile cross-sections, as mentioned Rhino individual blocks.
1 Like
It’s clear that your workflow is excellent—an ideal situation. But in many places, those conditions simply don’t exist. For example, here in mainland China, we more often have to deal with semi-finished drawings provided by others, and we may need to modify them and pass them back and forth repeatedly. In that environment, a single company’s standards are often powerless.
1 Like
@Tom_Norris The highlight preview of selected elements in Grasshopper doesn’t seem to work in AutoCAD.
@Pan_Cheng This is not currently supported but i will add it as a request!
Feature request: enable modifying the position, rotation, scale, and other transformation properties of existing geometry elements in AutoCAD (i.e., editing them—not creating new ones). Right now we can only get these properties, but we can’t set them.
Ideally, Grasshopper’s Transform components could be leveraged and used as the input side, so they can drive changes to an element’s transform/placement attributes.
Hi @Pan_Cheng, Yep, more great suggestions! 
We do have a new SetBlockRefernce which takes a block, a Origin, a Rotataion and Scale3d inside the next Release Candidate to enable exactly these types of workflows. We have a couple of other items we want to include before we can release, but I will let you know when it is available.
Regarding the transformations, you should already be able to transform the AutoCAD Geometry Types with Grasshopper’s Native Transform components, if you find any examples where this is not the case, let me know, as it would be a bug, and we can investigate. Unfortunately, the BlockReference is not a geometry type, hence the need for a Set component as you have requested.
1 Like
@Tom_Norris Regarding the Bake component: with the current behavior, any change in the input parameters immediately bakes a new instance. This needs improvement—at minimum, there should be a manual “Bake” toggle/switch.
2 Likes
Also, there are currently no components for native AutoCAD geometry objects (like in Rhino). Otherwise, baked elements end up being represented by curves instead of true AutoCAD-native objects.
The datatype should not change unless there is an operation which requires it to. For example, if you reference an AutoCAD line and then bake it, you should get an AutoCAD line.
If there are places where this does not happen, it is likely a bug that we need to fix.
I would caveat that to support all transformation types on curves like circles and arcs, the result will often be a different curve type (think of a Scale1D on a circle — the result cannot be a circle). It is RhinoCommon which is performing the transformation on the internal Rhino geometry, and we then just convert the result to its AutoCAD equivalent.
I think there are improvements to make here, though. What we can do, and I will add this, is some post-transformation rationalisation, and test if the transformed curve still has the properties of a circle, ellipse, or arc and then recreate them if it does.
Yes—what I actually mean is the output.