Working with AutoCAD-Native Types

Some AutoCAD objects have no clean Rhino equivalent. Here's why, and the consistent component pattern for working with them.

---

Why some types stay native

The bake example in Baking worked because the geometry — curves, surfaces, solids — exists in both Rhino and AutoCAD. You model it in Grasshopper and bake it across.

But AutoCAD has objects that have no direct Rhino equivalent. "No equivalent" doesn't always mean the concept is missing from Rhino — sometimes both applications have it, but implement it so differently that you can't convert cleanly between them.

Blocks are the classic example. Rhino has blocks and AutoCAD has block definitions, and at a glance they look like the same idea — a reusable, named group of objects. Under the hood they're fundamentally different. In the AutoCAD database a block definition is a composite object made up of multiple entities, each with its own ID, and it can carry far more than geometry — for instance an extension dictionary of arbitrary attached data, and, in the case of dynamic blocks, an associative network of parametric rules and constraints that drive its behaviour. A Rhino block has no equivalent to any of that, so there's no lossless way to map a block definition to a Rhino block and back again — a round-trip would lose data. Rather than pretend these types are interchangeable, Rhino.Inside.AutoCAD keeps them as native AutoCAD objects.

The main AutoCAD-native types

These types can't simply be previewed and baked like geometry; instead, Rhino.Inside.AutoCAD provides dedicated components (on the AutoCAD tab) to create, read, and reference them. The main AutoCAD-native types you'll meet are:

Type	What it is	Where to find the components
Block Definitions	The named, reusable template — a collection of entities stored once in the drawing's block table.	AutoCAD ▸ Blocks
Block References	An instance of a block definition placed in the drawing (with its own position, scale, and rotation).	AutoCAD ▸ Blocks
Layers	The named layers that organise a drawing and carry properties such as colour and visibility.	AutoCAD ▸ Layers
Line Types	The dash/dot patterns applied to entities.	AutoCAD ▸ LineTypes
Layouts	Paper-space sheets used for plotting and documentation.	AutoCAD ▸ Layouts

The repeating component pattern

Once you open one of these groups, you'll notice the components follow a consistent pattern. For most types you'll find roughly the same family:

• Get all — fetches every item of that type in the document (e.g. Get all layers).
• Get by name — retrieves a single named item (e.g. Get layer by name).
• The type component — represents the type itself and lets you decompose it into its properties (e.g. a Layer component exposing its name, colour, and so on).
• Create new — creates a new item of that type in the document.
• Set — modifies an existing item (e.g. Set layer to change its colour or properties).

Once you recognise this shape, learning each new AutoCAD type is mostly a matter of finding the same handful of components in its group.

The repeating component pattern — Get all, Get by name, the type itself, Create new, and Set — shown here for one of the AutoCAD groups.

Further reading: A block reference isn't always a perfect copy of its definition

It's tempting to think of every reference as an identical stamp of the block definition, but AutoCAD allows each instance to differ:

• Block attributes are text fields baked into the definition that can hold a different value per reference — for example, the same "door" block showing a unique tag or size on each instance.
• Dynamic blocks expose parameters (flip, stretch, rotate, visibility states, and so on) so a single definition can appear in many configurations, with each reference set independently.

This is another reason these objects don't map cleanly onto Rhino blocks, and why Rhino.Inside.AutoCAD treats them as native AutoCAD types with dedicated components.

Keep in mind

A few things to keep in mind when working with these:

• They're mostly referenced rather than previewed. Because most of these types aren't geometry, there's usually no viewport preview to toggle — you work with them through their components and by reading/writing the AutoCAD document. Block references are a little different: since we can extract their calculated geometry, we've made them previewable too, just as a convenience.
• They complement baking, not replace it. A common pattern is to bake geometry and assign it to a specific layer or line type using the bake Settings input, while the layer/line type itself is created or located with these AutoCAD-native components.