I’m a bit confused with the normal parameter in the BlockReference.Create Node.
Along a polycurve I collected CoordinateSystems. At the origins I place block references and I use the ZAxis as the normal, to rotate the block in the Z direction.
The blocks are placed but with a slight angle as expected. If I compare the ZAxis of the CoordinateSystems of the placed BlockReferences with the original used ZAxis of the polycurve CoordinateSystems, then there is a difference, as shown below:
I think the differences in the Z-axis is because the polyline has a slope in the Z-direction. Therefore, the z-axis in the coordinate systems along the polyline will not match the original z-axis which was set as the normal to the block references.
I am not sure I do understand this. I feed the Z-Axis of the Coordinate Systems along the polycurve which has a slope, as a Normal parameter to the block references. Then I expect the same Z-Axis in the properties of the block reference after placement. I can’t explain the difference.
I agree with @Haaba, the difference likely lies before these nodes. Use an export as image (camera looking button in the upper right corner of the workspace) after zooming to this, and expanding the previews of all nodes which feed into the nodes on screen. Post the resulting image here.
@Anton_Huizinga can you confirm if you are using the latest version? there was an issue in the previous release that did not allow for blocks with a normal different from the global Z axis.
When you chose “CoordinateSystem.ZAxis”-node, you will only get the z-component of coordinate systems. This will be a vector that points straight up, as the global z-axis, since you don’t have components of x- and y-vectors. The block references will therefore have the z-axis as the normal vector, which is straight up.
The coordinate systems along the polyline will be oriented dependent of the slope of the polyline. When the polycurve has a vertical geometry, the z-axis along the polycurve will be oriented regarding the slope of the polycurve, which will differ from the vertical normal vector of the blocks.
Have to have a better look on this, if I prepare a test document with a single line, other weird things happen. If I calculate the angle between the X-Axis and the global X-Axis, I get the same value as the angle in XY plane of the line, but if I use that as rotation angle, the blocks are not correctly aligned if I add a normal. So, the ZAxis of a Coordinate System can’t be used as a normal of a block? Will try a few things and come back later!
Well, some new tests. I have a single line in Civil 3D and these are the properties:
The angle in XY is 20.66 and a slope angle of 45. I want to align blocks along this line. The block is a box and this is the desired result in 4 viewports:
So, if I give the block a rotation of 20.66 in the Node BlockReference.Create, the blocks are rotated correctly. I calculate the angle of the line between the X-Axis of the Coordinate Systems along this line and a global X-Axis (and needs a correction of 90 degrees because of the design of the block):
Strange things going on with normal vectors in Block References indeed @Anton_Huizinga. I tried to get my head around this one but these are my 2 cents:
The Extrusion direction relative to UCS of a Block Reference is a strange thing. It only shows up as a property (AutoCAD LIST command) when the current UCS is set to WORLD but not when setting a user UCS:
It seems the normal vector of a Block Reference in Dynamo is having difficulties when also adjusting for rotations, in XY planes.
Then I came up with a possible workaround and that is using Dynamo geometry to reach the same goal. Below the adjusted script also attached. This actually works using the same coordinatesystem settings:
Thanks @John.DeLeeuw, it is a solid (haha) workaround to create solids instead of blocks. It is effective when the solids are not complex but I rather use blocks (complex curbs) that I can align along a Feature Line or so.
The angle presentation in the List command changes from 20.66 to 90 as soon as the normal is set, without a deviating normal it is 20.66. Indeed weird behavior of AutoCAD.
Thanks for your script, will keep it for solid creation jobs. But I hope someone from Autodesk (@jacob.small or @Paolo_Emilio_Serra1) can explain the behavior of the BlockReference.Create Node or puts this issue on the bug list
In the meantime, you might also want to check out this Autodesk webinar by @Paolo_Emilio_Serra1 ,with regards to Dynamo and Site Development, in which he also shows complex curbs and I think he also used a Solid workaround for them
Hi @Anton_Huizinga, as @Paolo_Emilio_Serra1 has pointed out, our first release of Dynamo for Civil 3D actually can get the exact normal as you want, but the result will be terrible.
Or if we talk with code, our previous code is setting BlockReference.Position/Normal/Rotation properties directly, so you can get the exact result, but seems AutoCAD handles these stuff strangely that cause the above block transforms. Then we took some suggested code from Paolo and it seems working much better.
If yes, you can actually use the new node, BlockReference.ByCoordinateSystem() without any rotation to get it. The normals are also kept. With CoordinateSystem, we can avoid the tedious work to deal with normal/position/rotation, as it contains the clear Origin/X/Y/Z which can be used directly as block transform.
If you want to change the ‘brick’ from vertical to horizontal, the rotation angle will then be 90 degrees.
).
