Thanks mary for the info, I figured it had something to do with the referencing of the file.
Is the ability to “work”, for lack of better term, with a ref file in a worksession something that is on the wish list
or “in progress” list for Rhino V6?
So, the only work around, to maintain the layout / detail layer visibility, if I understand correctly, is “if one needs to affect ref layers in detail viewports in layouts then don’t use worksessions and deal with, in many cases for myself, an even larger file than before, sometimes making it next to impossible to use or produce layouts and drawing packets” is that about the size of it or is there a hidden gem of a work around to help is sleepless soul out?
Please forgive my tone, it has been frustrating trying to work on a particular file which is a cross over file from a client and our work and it takes roughly 10 mins to open or so, 25 mins to save, and this is just the active file in the worksession.
Unfortunately, even linked block using Reference layer visibility are not being saved on the Detail. The developers will review this and decided when the fix can be available. We do not know if it will make it will be 6 or 6.x or later.
I would like to recommend Linked Blocks in the WIP. But there are current issues with Detail layer visibility with Linked block reference layers. It beleived it was working in the WIP in October, but now it is not longer working. So I have logged this issue: Detail Layer Visibility of Linked Reference Layers Are Not Being Saved in Parent 3DM
The best thing here is that you are telling the Forum that this an important feature that you use and that needs improvement. This will help the developers prioritize accordingly. It helps me a lot also, because then I am not the only one who is “beating the drum” on these block features.
A little history, work session were added pretty early on in Rhino developement (1.1 I think) when is was used to being large models together in the Rhino editor in an efficient way. The 2D drafting features and layouts were added after. So there is definitely many improvements that need to be addressed.
Sorry for these issue.
Thanks you again for the discussion…
Kind regards,
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA
Hi Dan,
Technical, Pen, Ghosted are display modes, not a print modes.
They may not print as you expect or as displayed on the screen.
Your best option, if you are not printing what you think you should see, is to capture at a high res and reattach the image to the model with the PictureFrame command.
Hi Mary,
Sorry, I’m a little confused here - so the display modes that work best from layout prints to customers such as Pen, Technical, Patent Drawing aren’t really good for printing due to instability of result?
Hmmm thats odd. Okay, so we produce allot of fabrication models, submittal drawings to clients and such, over the last year and a half we have used Rhino more and more to produce these packets so I am making layouts with detail viewports and then in paper space I will dimension and annotate. If I was to capture a high res image and re attach due to the display mode not printing correctly, then I can not dimension the information I need to show. That’s obviously not going to work and my boss will not be happy with that result if I tell him that’s the approach I must take, whats the alternative to the alternative and / or can a custom (more stable) .ini file be written as both a display mode / print mode that will not only show on the screen what the view port is portraying but also print correctly without dropping information?
The current viable way is to crank up the dpi settings in your PDF printer.
But, yes, in the end we need vector output - on-the-fly Make2D that doesn’t have to produce curves that will be used for further modelling tasks but only used to print …
Cheers for the insight. The files we work on are so big that Make2D just simply kills our machines and are also are non dynamic so any changes (which there are many due to the nature of our work) would have to be remade and positioned correctly to match and maintain information on the layout. I have bumped up the PDF DPI settings and will see how well that works.
Do you have any experience working with the .ini files either in editing or in rewriting?
If I’m following along correctly here, the .ini files you are referring to are just text files which contain all the settings in one or more display modes. They are only used to transfer settings from one Rhino to another - or as backup of your settings. Everything in there should be / is exposed in the GUI in the Rhino settings. And there isn’t necessarily anything there that will make a display mode print better.
Have the issue with layer visibility in detail been resolved? I also tried using Rhino for drafting and find it very frustrating, especially with time pressure to deliver. Definitely something that should be improved, as this is discouraging me and my management from using Rhino on this type of work again.
An update with the latest release of Rhino 6 (6.16.19190.7001): the issue is still there.
Anyone have a solution? From what I can tell, the next best thing is using a linked block, but these cannot be edited in context of the larger model (they are opened in a new instance of Rhino), so it won’t work for our application.
Hey, I know this is old, but I just wanted to say it’s still a confusing issue and add how nice this would be to have resolved.
I think that while rhino has added all these neat new interoperability features lately, there’s still not a holistic model of how to organize a large project with multiple user and files.
I mean, there is, but it hasn’t really been flushed out or it doesn’t seem like the workflow aspect of bringing these features together has been prioritized lately.
Hi @David8,
This is still an open issue WorkSessions: Save Visibility per Detail: RH-37146
You can register on the McNeel Youtrack system and add any additional comments.
Thanks for checking in.
Sincerely,
Mary Ann Fugier
This thread is six years old, how is it that this hasn’t been fixed yet? You’re adding totally new features that everyone agrees are neat, but neglecting to fix the bugs in features that people have been complaining about for years. It’s like a plumber showing you a shiny new faucet he’s installed, when all you want is for him to fix the leak under the sink. There have been two completely new software versions since this thread alone was created. “Thanks for checking in”? With all due respect, it’s taking the piss. It’s incredibly frustrating to see Mcneel push out new software versions, which everyone has to buy to remain relevant, and fail to address issues like this which have been around for years…
I posted already about this issue in the forum, didn´t know about this topic.
I would like to emphasise how important is to be able to work with worksession/blocks in a way that allows to save visibility per detail when working on a layout, as has been expressed here.
I am afraid that, without this, Rhino (which has amazing features) is not a valid tool to draw projects on 2D as you cannot really work with reference files (such as one file for ground floor, another for first floor, etc…).
I also agree that this is something we need (Layout Layer Visibility memory).
From my experience, Rhino drawings get difficult to control when file sizes get too large, or there are many line elements (this may be a graphics card or CPU problem, but Worksessions are a way to mange complexity).
Here is a thread that terminates in a main reason why Linked and Embedded Blocks add to the difficulty: Worksessions and Section / plan views - #9 by ahmet.unveren
It’s essentail to be able to set Layer State by layout and detail on WS. Control of visibility, color, lineweight, material are one of the most important issue not only for producing 2D drawing but also for porject delivery to clients. Neither WS nor Block can be an option for collaboration at the moment.
Please pay more attention to workflow for collaboration and documentation, McNeel
McNeel developers, programmers and coders believe that making new features is more interesting/exciting than fixing old bugs and finishing Rhino documentation.
Hi all - has been there / is there currently any development on this issue?
I also agree that it is essential to be able to control and save layer visibility of non-active files and referenced blocks in the detail viewport, as well as being able to adjust and save other layer properties of non-active files in the detail viewports. Lacking this capability is a big prohibitor for the ability to do documentation in Rhino.
Along with this same idea, it would also be very useful to be able to “bind” a non-active file into the active file (there by making it native to the active file / breaking the live link), where it retains any layer property adjusts (both in global model space and layout detail viewports) to the previously non-active file (as well as maintaining all layer structures and geometry content).
because then I am not the only one who is “beating the drum” on these block features.