I wanted to check that the surface is recognised as surface only in dynamo. But to my surprise, the Object.Type node is recognising surface as an Object. Kindly please help me with the same so that I can easily correct this. Are there any other ways to create plane surface so that my dynamo node recognises the surface. I am also attaching the screenshots for better understanding. I will be highly obliged to receive any kind of help.
Hi @shagun_tandon,
Dynamo currently doesn’t support AutoCAD surfaces, so this is the correct behavior. Can you explain more about what your goal is? There may be some alternative approaches.
Hi @zechri.jensen,
My objective with this custom node is to robustly identify and work with Civil 3D surface objects within Dynamo. In my workflow, I often select a variety of objects (such as texts, polylines, and surfaces) from an AutoCAD or Civil 3D drawing and then need to filter out only the surfaces for further processing—like extracting geometry, performing area or volume calculations, or running design-related analyses.
The problem I’ve encountered is that the built-in Object.Type node returns the full .NET type (e.g., "Autodesk.AutoCAD.DynamoNodes.Object") instead of a specific and simplified surface type (such as "Surface" or the corresponding DXF name like "DBSurface"). This makes it difficult to distinguish a surface from other objects. In previous versions (like 2022), the filtering worked as expected, but in 2023 (and even some builds of 2025), the behavior has changed, meaning surfaces aren’t automatically recognized as surfaces.
To overcome this, I developed a custom node that uses .NET’s reflection (using .GetType().Name) to extract the simple type name, and I’ve also implemented a mapping strategy between the DXF names and the simplified type names. This allows my node to correctly filter out Civil 3D surfaces from a mixed selection, enabling downstream operations targeted specifically to surface objects.
Ultimately, my goal is to create a more reliable and user-friendly tool for identifying and processing surface data in Dynamo, despite the current limitation where Dynamo doesn’t natively support AutoCAD surfaces. I’d appreciate any guidance or suggestions you might have on alternative approaches or future improvements in the API that could better support this functionality. I have also attached an image with this post so kindly see it.
Thank you for your help!
I’m curious to know more about this, because AutoCAD surfaces have never been supported in Dynamo. Are you sure you aren’t referring to Civil 3D surfaces?
Anyway, it’s pretty easy to just unwrap the object in a Python node and work with the underlying DatabaseServices instance. For example:
obj = IN[0]
OUT = obj.InternalDBObject
Thanks for your suggestions—they’re really helpful. I’d like to clarify further: my objective isn’t limited to just surfaces. I actually want to create a comprehensive mapping between AutoCAD objects and their corresponding Civil 3D objects. This way, regardless of whether a user is an AutoCAD expert or a Civil 3D specialist, they can easily understand which object we’re referring to by knowing both names.
For example, in my workflow:
An AutoCAD DXF object like DBText might map to a Civil 3D Text node.
Polyline might map to either Polyline or Polycurve (depending on context).
MText might also be considered as Text in Civil 3D.
For Civil 3D–specific objects, such as surfaces or alignments, I need to be able to unwrap them to inspect their underlying types (like AeccSurface for a surface).
The idea is to “unwrap” any given Dynamo object (using, for example, a Python node with code like:
obj = IN[0]
OUT = obj.InternalDBObject
Once unwrapped, I’d like to use a mapping table (or a similar approach) to translate between the AutoCAD DXF names and the internal class names used in Civil 3D. For instance, I might maintain a mapping.
This mapping lets me reliably identify any selected object and show both the AutoCAD and Civil 3D naming conventions. This is crucial for my tool since users might be more familiar with one naming system over the other, and I want to make it clear which object is being referenced.
I hope this clarifies my goal. Any further guidance on how to robustly implement this mapping across all object types would be greatly appreciated.
Just to add a few additional points to clarify my approach further:
Additionally, I was able to work this out for both Grid Surface and TIN Surface. However, I was not able to achieve the same for normal surfaces yet.
I hope this extra detail helps clarify the extent of my current mapping work and points out where I’m still encountering challenges.
Best regards,
Shagun
Based on what you said here, I think you might be overthinking the differences between AutoCAD and Civil 3D.
Civil 3D is built on top of AutoCAD, meaning the MText and Text (DBText) you see in Civil 3D are the same MText and Text (DBText) you see in AutoCAD. The difference comes in with Civil 3D Labels, which have no direct mapping to AutoCAD objects, as they are really more of a collection of AutoCAD objects held together with some additional objects (you can see this by exploding the Label and getting the base objects as a result).
This would also be the same for most other entities, such as Polylines, Lines, Curves.
Polycurve is specific to Dynamo.
Surfaces in AutoCAD and Surfaces in Civil 3D are two very different object types and don’t have a true comparison.