New "Import 3dm" Component

Today’s Rhino WIP contains a new version of the “Import 3dm” component. The old “Import 3dm” component still exists and should behave exactly the same as it always has, it just has an “old” icon.

The new Import 3dm component now creates a headless RhinoDoc and outputs referenced geometry that references back to the headless doc. This allows for using the components like “Object Details” to pull other information off of the referenced geometry.

The component is creating a headless RhinoDoc under the hood and then reading a file into this doc. What this also allows is the use of most of Rhino’s file import plug-ins for reading. The new component supports the following file formats:

  • 3dm, 3ds, 3mf, amf, dwg, dxf, e57, gts, igs, iv, fbx, lwo, m, obj, off, pdf, pts, ply, raw, scn, skp, slc, sldprt, sldasm, stp, stl, svg, vda, vrml, gdf, x, zpr

This required some minor changes to our file import plug-ins so they wouldn’t ask for further input parameters when they are reading into a headless document. This should also be useful for developers working with compute or scripting the reading of files into a doc as you can now just write code that would look like

var doc = RhinoDoc.CreateHeadless(null);
doc.Import(pathToFile);
8 Likes

This new module seems interesting to me, however I think its name is inappropriate. “3dm import” doesn’t make me intuitively think of using it to import dxf for example.

I also note that in component output, even if the geometries seem to be referenced, I can’t sort the imported geometries with, for example, an Elefront sorting component:

I can see that I could do a pre-sort before import, but it makes me use many instances of this new component, which seems heavy to me. (here I’m trying to import .dxf files)

Great! It’s time to retire this feature before release… :rofl:

Wish: There could be a universal API for import/export options. Maybe those can be controlled by a configuration file, etc.

I discussed this with @DavidRutten and @BrianJ last week and it seemed best to reuse the existing component named “Import 3dm” instead of trying to create an entirely new component. It is also hard to name as there is already a “Read File” component that does something completely different. New names suggestions are welcome though.

I can imagine in the future there could be a larger scale version of this as an entirely new component that has import options and outputs a RhinoDoc.

This is hard to fix as Elefront was written before any concept of extra headless docs existed. I would be happy to work with @ramon and Alan on an update if they want. I can also try putting together a script that sorts or see if this can be done with the output of the Object Details component.

Me too; I just don’t know what that would look like as every importer seems to want to have a different set of options. I have gone the route of adding format specific options and readers to the FileIO namespace of RhinoCommon, but a generalized solution would be great.

I would propose redirecting command input / option getters (like redirecting STDIN to a file) during an I/O action, and caller may use a extensible key-value list as options. Although it’s seemingly more difficult than implementing managed FileIO for each plugin.

btw, when I’m writing the Export/Import component for the GH, which utilizes Rhino’s Export & Import command, it annoys me that some plugins remember the last state for toggle options while some don’t. It makes very difficult for external procedures to figure out what the current state is and whether a desired state is achieved.

“Model Import”?

“File Import” is a broader term. “CAD Import” would kind of exclude mesh models (?), in any case, perhaps “Model” is the most common concept in this particular import operation? (could be border cases since I’m not familiar with all the extensions)

// Rolf

Can it be just “Import”?

I don’t know if the layer name referencing is an Elefront’s problem, it should be checked:

Error genrated in french: “1. Solution exception:La référence d’objet n’est pas définie à une instance d’un objet.” deepl: Exceptional solution: Object reference is not defined to an instance of an object

The layer name referencing won’t work in any of these 3rd party tools. They all think the geometry exists in the ActiveDoc as that is how things worked until recently.

:+1:

All good names, but I would rather reserve these for another new component in the future that did a lot more than what the current “Import 3dm” component does.

Btw, how is resource managed here? Is one Import 3DM component linked to one headless doc and every time the doc is cleared, or a new headless doc is created every time?

I have been thinking of the lifecycle of some RhinoObject, such as ObjectAttributes, as they are IDisposable but frequently created / duplicated in an I/O (incl. import, export, baking, etc) scenario, while many plugins don’t dispose them timely.

Yes a new headless doc is created every time. The old one is disposed of when the new one is created. I hold on to a list of headless docs inside of the component and when a new solve occurs, I Dispose and clear the old list.

Don’t know if it’s the correct way to retrieve the RhinoDoc object, for now:

public static RhinoDoc GetDocument(this ObjectAttributes attributes) {
     return (typeof(CommonObject)
      .GetField("m__parent", BindingFlags.Instance | BindingFlags.NonPublic)
      .GetValue(attributes) as RhinoObject)?.Document;
}

I’m confused about what you are trying to achieve.

Say there’s a component that extracts information from an ObjectAttributes. However, ObjectAttributes itself doesn’t expose methods to determine which RhinoDoc the attribute is in.
In order to figure it out, I suppose reflection is the only way as I demonstrated.

Ah ok, yes that would be what you would need to do but I wouldn’t recommend it. Parts of the sdk that can only be accessed through reflection may change and potentially break in the future.

1 Like

Yes I fully understand that :wink: