Make2D and linked Rhino files

Hi,
I have a problem with the Make2D in combination with linked files. In order to split up a very large files, I created aspect models that are linked into a master file. That works fine until I try to use the Make2D - it ignores locked or invisible layers of the linked file and processes the command as if everything was turned on. This occurs on all linking methods that I tried.

Does someone know how to deal with this? I attached 3 very simple files where I would like a Make2D in the masterfile without the red “working” layer of the aspect model 2.

Thanks!
-Ludwig

aspect1.3dm (37.9 KB)
aspect2.3dm (29.4 KB)
master.3dm (38.0 KB)

Yes that’s quite bizarre, but the hidden layer on the xref file gives also an hidden sub layer in the make2d layer so that the original visibility is kept…I would delete it without hesitation.

I would do that, but the hidden layers contain geometry that are “blocking the view” on the things I want to display - so the Make2D is not correct… might not be so clear in the example files, but let’s say I model 3 different options for a facade in one of the aspect models - how can I generate a Make2D that only shows 1 option at a time out of the master file?

This is maybe due to the kind of link. You have inserted your reference files as blocks (with Insert).
Instead, delete the “aspect” blocks within the master.
Then, re import them as attachements (Attach).
Then save the Workession (File/Workession -> Save As) e.g. master.rws.
If you edit anything on the master.3dm file, DON’t forget to save it also.

Now you can try Make2D, all should work as expected.
Each time you work on the project, just open the rws file. (and save the master if needed)
This is a different workflow …ahem.

1 Like

Yes, thank you very much! Different workflow indeed, but works well for my needs. Cheers!

Thanks for the report. This appears to be a bug in Make2D. Logged here…

Glad to read this. :slight_smile:
it remains that using the “attach” option along with the worksession feature remains the best way to handle big projects.

I agree. I just fixed the bug, and you should see it in the next service release.

1 Like

RH-49163 is fixed in the latest Service Release Candidate