Reference layers reset everytime reference is updated

Rhino Rhino for Windows
, , ,
1

Hello,
Can we make the layer status of the referenced layers persistent?
This is extremely useful when working in large teams or with options. There is no up side for the current situation where.
This referes not only to the main layer status but also to the viewport layer status. After carefully laying out several viewports, turning on and of the viewport visibility of several layers, all the work goes down the drain on the next update.
Is this on the roadmap for rhino 8?

N

1 Like
2

Any updates on this?
Was this solved in Rhino 8?
N

3

The behavior hasnā€™t changed, the workflow to maintain layer status is to use Linked Blocks set to active.

image

1 Like
4

Wow, thanks.
After all this years that is probably the only option I havenā€™t played withā€¦
Is this an accidental occurrence? I went back to the documentation on this and that key property is not mentioned. The only ā€˜featureā€™ associated with this option is that if the insert file disappears the geometry will be goneā€¦ I always wondered what was the point of that optionā€¦
N

5

@Japhy,
On second thoughts, I probably did play with this option and opted to not use and block it from my memory ā€¦ and now I am suffering the drawbacks.
We work with multiple nested linked blocks.
Hereā€™s a situation, File A has a File B linked as a block. File C has File A linked as a Block.

  1. first drawback
    File B changes. I go to file A and update File B and save. On File C it show that both File are newer, but you can only update File A, it is not possible to update file B and although File B is already updated on file A, File C still shows the previous version of File B. This is certainly not expected behavior.

  2. Second drawback
    Since we changed to active, on a running project (yesterday), we have the situation that we have been able to (mostly) avoid while using Linked/referenced or (more recently) ā€˜Embeded and Linkedā€™. Although, we painstakingly tell Rhino to use the imported nested block when linked block are updated, there has been a multiplication of embedded blocks - a single door block (present in several nested linked blocks) is now up to ā€˜door 05ā€™. And also we cannot check where these doors are embedded and how many are present in the model. From past experience these will grow exponentially and make the file unworkable pretty soon.

So the original problem still stands.
Let me know if there is a solution.
N

1 Like
6

What is the purpose of each of the files?

C seems to the one being printed or final output? with User 1 in A and User 2 in B?

If thatā€™s the case wouldnā€™t you want use worksessions for User 1 and 2 references and only link the blocks into C?

7

Well! WorkSessions I do remember, but it was so long time ago that I cannot find any posts of mine on that, either I changed username, or Rhino changed community platform - probably both.
Essentially, WorkSessions were so prone to problems that we have banned their use in my previous company, and I have sticked to that policy ever since.

One thing I do seem to remember was Rhino, not prompt to save changes either when closing the WorkSession or when jumping from one file to the next, or something like that.
I remember quite a bit of frustration around that.

I have shorten the chain of nested blocks to illustrate the problem.
We use several ā€œgenerationsā€ of nested blocks, with several siblings by generation. File B in the example can be multiple files, and these may have also other files inside.
Depending on the complexity, we may have a building divided in Cores (maybe more than one), FaƧade (maybe more than one), Roof, Ceiling, Interior Zone 1, Interior Zone 1, Structure. These parts maybe combined in macro groups (File B) and then these together in one master file (File A). We do indeed use File C for make2d and printing. Depending on the amount of documents this is important you will have several File Cā€™s - elevations, sections, plans. That is why you need to have File A as a master.

There could even be several buildings, so several File Aā€™s

As I said, I canā€™t remember how worksession very well, but I do not think it would work on this scenario.
Where would you use worksession? File C wouls be a worksession?
N

8

Worksessions are good for referencing in others work or large files for design context. The layers you turn off will not save and you canā€™t modify its location.

In general getting too deep in nesting gets problematic regardless of the software. In Revit nested families with associated parameters can take a horribly long to load into a project after changes, Autocad and Rhino get cumbersome the more hierarchy you add. This applies to doing mechanical assembly or a architectural project.

An alternative to nesting is to create associations via data rather than buried 5 or 6 deep in blocks.

9

Sorry to be blunt, but the point of this thread is: Reference layers reset everytime reference is updated.
You suggested using linked, and I pointed two reasons (one probably a bug specific to ā€˜Linkedā€™, the other likely a more general bug - see Bug - BlockEdit Linked block renames nested blocks - Rhino 7 - Rhino)
You do not address any of these points and suggested using Worksession, which I spent time try to remember and writing about it but, luckily, I did not spend any time retesting them because - later you mention (and I had forgot) - that layers will not be saved, which it is the point I was asking to get solved.

You then mention that going too deep into nesting getting problematic (also in other software [not true]). But again this is not about multiple generation nested blocks. It doesnā€™t and/or it shouldnā€™t get problematic, but this is not the point of this thread. This is about the layer status of linked files. Surely, this is something easily fixed.

The point is:
I cannot imagine a common situation where this is desired out come:

  1. You reference a group of models, turn layers on and off, set a scene.
  2. Someone updates one of the references.
  3. You update the scene and the reference is reloaded in whatever status the last person that worked on it left it.
  4. the scene needs to be resetā€¦ every time this happens.

Can you imagine if that would happen in AutoCad? It doesnā€™t and for good reason.

Risking stating the obvious but trying to really drive through the issue:

  1. different scenes will require different layer status, therefore the linked file canā€™t always be saved in the ā€˜correctā€™ status.
  2. different linked files may have common layers, when it appears/disappear for one it appears/disappears for all.
  3. when I change the material or the color of the layer in the scene, rhino already remembers does not change it back to the original when it updates. Rightly so!!!

Again, this should be easily fixed, it is fixed for the color and other characteristics of the layers!

Please put this on the road mapā€¦
N

1 Like
10

@Japhy , @mcneelsoftware ,
Regardless of an alternative to nesting, can you please tell us if this is on the roadmap and if there is a timeline for it being solved. I just had to update a few components in a large scene and it is really frustrating to have to reset the whole thing.

Please solve this.
N