I’m trying to import geometry from DXF files into the GH file using the shapediver geometry import component, but the component is simplifying too much the original curves (image attached - in green the original lines, imported with a C# component, in red the imported lines with the native shapediver component). I’m having problems too with the limitation of the native shapediver component: the layers of the original file are not imported. As my company works with urban and architecture files, the use of layers from the original file is crucial to differentiate the parts of the project (not just colors).
I’ve tried to use the following C# script as a workaround, but the script was denied by the platform (reasons?). Do you have a solution or workaround for this problem?
Importing of layers is not supported natively by the ShapeDiver Geometry Input but you can use the FabTools plugin and its Get User Data component to get the layer information. Lear more about importing DXFs in this tutorial, the source files are in the video description:
The oversimplified curves look strange. Could you share a sample DXF so we can have a closer look?
I think the problem is with arcs and polyarcs. It’s strange because the problem doesn’t occur with the C# component. It’s like the arc is transformed in an over simplified polyline.
For importing layers, I’ve tried the FabTools component but:
Yes, the arcs and polyarcs seem to be problematic and I recommend to export the DXF as polylines to avoid oversimplified curves on import. This also works for the Get User Data component.
Hi Pavol, the problem is that we will receive files from our clients and we can’t control the line formatting (it will be an online automated service). In the urban landscape scenario it is a problematic solution too because the areas need to be exact, and the polylines will deform, even if a little, the original shapes.
What is the problem with the C# component? Can I use another technique to resolve this problem?
The script references a local path and cannot work on our servers, more on forbidden functionality in this article:
We are working on a major ShapeDiver plugin update which will be released soon and it will also improve DXF imports. As a temporary measure, ask your clients to export DXFs as polylines for now.
Sorry to insist. I’ve tested a conversion in AutoCAD to polylines using the pedit command. The lines are not converted because they already are polylines, they stay the same.
If I manage to use a URI instead of a file path and store the DXF file in my server, I’ll be able to use the C# component?
If I ask our clients to convert files to only polylines they will do exactly what I did: select everything and use pedit for conversion. And It works, if something is not already a Pline.
So, if I manage to use a URI, I’ll be able to use a custom component? I don’t want to lose time searching for a solution if it will not be usable in shapediver.
The DXF comes to Rhino as arcs even if they are polylines in AutoCAD. I’m not quite sure how the conversion works but exploded curves import without any issues.
Yes, curves without other segments are imported well.
But the files will be used for various urban analysis, like score by the lot distance from a park. So I need the closed polylines to identify the center of each lot, and then attribute a mesh colour to it. I need the lot areas and dimensions too.
If I explode, I’ll be unable to identify each urban lot alone. Join lines is not an option, it will result in various errors.
The custom C# component with modifications (if i manage to use URI) is not a possibility?
I understand that the polylines have to be closed.
Importing with custom C# via URL won’t work, I’m afraid. But as I mentioned, soon we will have an import component using Rhino 7 headless documents, thus using Rhino’s native importer and you will be able to get the drawings to ShapeDiver without any issues.