I would like the same control over my Acad drawings as i have over Revit, via Dynamo.
A typical user error is creating a block with basepoint in 0,0,0, when the actual block should have a local basepoint close to it’s own geometry.
Any ideas on how to list block with faraway basepoints, even better; how to move the basepoints closer to the blocks?
Or rather, move the block objects closer to the block origin (not the other way around).
Choosing exactly where the block objects are located relative to the block origin should probably be done on a case-by-case basis. But here’s an example approach to moving everything closer to the block origin. This is basically just shifting everything so that the origin will lie at the center of the geometric extents (i.e. center of the total bounding box for all block objects).
Another option which may preserve the content:
- Get the geometry objects from the block
- Pull the combined geometry’s bounding box
- Pull the min point from the bounding box
- Convert the point to a vector
- Reverse the vector
- Move all the geometry objects by the vector
- Get all block references for the given block
- Move all the block references by the origin (non-revered) vector (#4)
Is there a node to do this? The only one that I’m aware of to transform geometry in AutoCAD (not in Dynamo) is Object.Transform, which only accepts a coordinate system as the transform matrix.
Thanks for your suggestion. I’d like to replicate your graph from the screenshot, but i’m having trouble finding the node Block.Extents
I’m running Dynamo Civil3D 2.1.1 in a Civil3D 2020 environment. Could it be that you’ve got that node from a package or from a discontinued Dynamo Release?
It is an OOTB node. Look under AutoCAD → Objects → Block.
yeah, that’s where i’m looking, and i’m wondering if i’m doing something wrong, because i would expect more nodes…
Ah, right. Move the coordinate system from the original location, then apply that.
FWIW a Object.Translate node is another missing tool in the OOTB nodes.
Yeah that doesn’t look right. I think the current Dynamo version for Civil 3D is 2.5.2. You might want to check for updates through the Autodesk Desktop App.
Defining a coordinate system is 4x more data points than a vector and creates geometry display which at scale slows things further; so no this isn’t the same. Yes this is a valid work around using a higher complexity object than needed (as noted above), but that doesn’t mean the provided toolset isn’t missing this functionality.
the complexity you are referring to is an illusion, under the hood, the Translate with a vector is performed with a Matrix (CoordinateSystem) transformation.
By that logic every node should require an input for the .net imports.
Just because the API has the call in a specific way doesn’t mean the Dynamo library has to match it line for line, after all the intent of Dynamo is to simplify the bar for entry, not just provide more of the same.
It is a valid rule of thumb, just not in this case
By that line of reasoning, the node should be called “Move” and not “Translate”, right? It actually happened to me that someone asked me: “To which language should I translate?” when looking at this node for the first time.
Ah yes that old ‘well, it’s just the word that is used’ issue… I suppose there is a ‘path, like the route traveled though the woods?’ conversation had at some point as well.
Vocabulary being what it is, all reductions in specialized knowledge are a good thing. And while translate appears to be consistent in all applications, the absence of a ‘move by vector’ isn’t consistent.