There is a new version of the Import3DM node (used in Rhino7 and Rhino8, I think). I’d like to use it, but it forces the active viewport to match the active viewport of the imported file, which is very jarring. And I have a grasshopper script where the user can choose from a list of files. My work-around was to use the older Import3DM from Rhino6, which does not do this. But now, after recent updates, the old node throws error messages about forward compatibility, which might be confusing to people using my scripts.
Any chance we can get the new Import3DM node to NOT force a viewport change? It’s so nice and professional-looking to have it not snap you into a different viewport everytime you choose a new file. Or maybe at least make the the viewport snapping feature optional (it might be useful in some cases, I guess, but it’s defnitely undesireable in mine)
In the attached GIF I show myself replicating the issue. The important thing is for the file that will be imported to be saved with an active viewport that is different from the active viewport of the current file that we are using grasshopper in.
In this example, the file called “import_test.3dm” was saved with the top viewport as the active viewport. But in the current file, I am trying to work in the perspective view. As you can see, it keeps switching me to the top view whenever I connect or reconnect the path.
.
.
Thank you for taking a look at this. I really appreciate it. (I realize that doesn’t necessarily mean it will be fixed the way I want). Let me know if you need anything else.
I have Rhino6 (SR35), Rhino7 (SR36), and the trial version of Rhino 8 (SR5).
The legacy Import3DM node is from Rhino6 (not Rhino7)
The Import3DM node from both Rhino7 and Rhino8 have this view-switching problem (at least in my experience)
It looks like exported geometry might not cause this issue. I’m assuming viewport info is not present in exported files. (Overwriting my files with exported geo might actually be the solution for me.)
Since the last update, Rhino7 (and only Rhino7) throws a warning (see attached image) about forward compatibility and deserialization whenever I open my kit’s GH scripts in it. The GH scripts were made in Rhino6, iirc. I thought this was due to the legacy import node, but now I think it might be something else causing this warning because just now I used Rhino7 to open a simple GH script made in Rhino6 and that contained the legacy import node and no warning was raised.
Those pop-up warnings I was getting in Rhino7 did turn out to be unrelated to the legacy import component, and I seem to have that resolved now by changing how I build the file paths that feed into the import component. So, I can continue using the legacy import component, and that means the whole issue is solved for me. At least for now.
Also, following up on my last comment, I again tested creating an object, then exporting the object to a .3dm file using File > Export Selected (instead of saving the file), and it really seems importing such a file via the Import3dm component does not have the view-switching issue (I’m guessing viewport info is not contained in such a file). So I think that can be a potential work-around for people.
A final thought, if it turns out that someone at McNeel actually wants the viewport to update when using the Import3DM component (if it’s a feature and not a bug), then I would like to suggest - if it’s possible - adding an input node to the component: something like “Update Viewport” and have it default to False. But I guess we could also just all learn to use exported geometeries to avoid the problem.
