I just spent the entire afternoon debugging why my new DXF files (exported via Pancake in Rhino 8) weren’t parsing correctly using the legacy ShapeDiver Import Geometry component-both locally and online.
The issue:
In the latest Rhino 8 builds, DXF lines with color 0,0,0 (black) are being interpreted as 255,255,255 (white) by the legacy ShapeDiver Import Geometry component-the one where the M output gives RGB values directly.
This doesn’t happen with DXFs exported from Rhino 7 or older builds of Rhino 8.
Please see the screenshot below to compare the behavior across versions:
Since these components did not get any update in a long time (especially not the Legacy Import component), then this must be due to a change in Rhino itself.
Is there any reason why you do not upgrade to the latest version of the Import component? If I understand correctly, it would solve the issue, correct?
Thanks Mathieu,
Yeah, I resolved it by exporting the DXF files from Rhino 7, so I don’t expect any action from your side.
I’m still using the older import components mainly because they give me the raw R,G,B values directly. The newer ones output materials, and I’d have to explode them to get separate values - plus they convert RGB codes into color names like “White”, “Black”, etc. It’s not a dealbreaker, just a bit more work.
Also, since I often need to import many 3D models, I’d need multiple import components - which can easily turn the definition into a full-on spaghetti mess. So yeah, partly laziness on my side
That said, is there any easy way to turn off the color name translation in the new import component?
Why do you want to get rid of the “Black” color? As Alex said, this is just a matter of the way colors in Grasshopper are cast to strings, but the component outputs a real color which can then be used further in your definition for whatever purpose you are interested in. In other words, it should not have any impact on your workflow.
As a matter of fact, the old Import component was using an external algorithm, whereas the new one imports objects and materials using only Rhino functionalities.
I am embedding a metadata trough RGB channels, as back in the times it was the only way to describe what is inside the imported 3D model. We build up the whole system base on this. At the moment there would be more convenient paths I am sure.
Got it. Given that this behaviour is the standard one in Grasshopper, I think the workaround from your screenshot above is the best solution at the moment. It would indeed make sense in the future to revisit your workflow making use of the most recent feature or Rhino 8/ShapeDiver.
You should be able to use the latest released version of the plugin for all versions of Rhino. Note that the Rhino 6 plugin still includes the old Import Geometry components, as the new ones are only compatible with Rhino 7+.
The issue:
Temporary workaround:
