I have a problem with a very simple Dynamo Script extracting pipe solids.
I don’t understand the problem, because the node “Object.By.Geometry” doesn’t work.
I attach the screenshot, the drawing and the Dynamo Script.
Infact, I have the same problem running the Dynamo Script for the pipe network crossing, made by @CivilEnvoy, discussed in this post, Pipe Network Crossings - #13 by CivilEnvoy
that calculates the distance between pipes by extracting solids.
Thank you, the solution was simpler than expected.
I inserted the extra large scale because other nodes requested it, I didn’t think that without setting the medium scale it would not be possible to export the pipe solids
You’re welcome. Yes, it is very confusing. If you search around the forum you’ll see that it is the cause of many common problems.
@solamour@jacob.small
In my opinion, if there is one thing for the Civil 3D team to move to the top of the list when they work on Dynamo next, this would be it. It’s been an issue since the beginning and continues to trip up most new users. Whatever you can do would be much appreciated.
We’ve taken one step in the right direction recently with Dynamo 2.15 that will retain your chosen working range value - as opposed to always using the default Medium.
Hear you that this is a giant problem with Civil 3D in particular, and as Jacob says we can look to get better error messaging as a quick fix before a more holistic one comes from the Civil 3D team.
Pardon if I’m misunderstanding, but this seems to be the opposite of the issue? In the context of Civil 3D, I actually can’t think of a reason why the geometry scaling setting should ever be changed. I have yet to come across a situation where changing it to something other than Medium has any benefit. It seems to only cause confusion, and even worse, significant issues with handling geometry. I wouldn’t be opposed to removing the option completely from the Preferences window and not throwing the working range warning at all. Just leave it set to Medium under the hood.
@zachri.jensen It’s a step in the right direction for honoring a user’s choice of Geometry Working Range, but agreed I worded that poorly
For Civil 3D users, if the choice is to not expose the working range functionality and suppress any affiliated warnings that would be part of the actual integration into Civil 3D. Your suggestion, under the hood, should be a viable one
I have - just this week in fact when I was trying to bring non-standard path data (think non-wheeled transportation) into Dynamo from an outside source.
Basically whenever the data comes from outside C3D you have to tell Dynamo what scale you’re working in. Think of stuff like modeling terrain in Dynamo directly (takes <1.5 seconds to generate) instead of from content already in civil 3d (more than a few seconds to move similar data over). If your scale is off by too much the discrepancy means you won’t get anything geometry created by Dynamo, as the stuff that’s ‘too big’ or ‘too small’ gets tossed and suddenly all points are co-incident.
I do agree that this has very little to do with the typical Civil 3d use cases around automation, but more with Generative Design focused workflows (which I think is where the ultimate goal of the Dynamo integration with Civil 3D should focus, but I may be biased). But ‘removing it’ would actually lead to significant hindrance towards that long term goal. A means of bulk suppressing those warnings by default on the Civil 3D nodes in particular may be of use; something which may be doable as is within the current framework of the Dynamo JSON format, but would likely be best implemented by the Civil 3D team.
