I have a model with 2 buildings. Building B started as a mirror image of building A, but has numerous changes to suit the topography. There are hundreds of layers involved. The layer sets have identical names, with A and B prefixes. I have a set of layer states for building A, and want to copy them as the basis for building B layer states.
I created a duplicate of the .3dm file, deleted the B layers, and changed the names of the A layers to have the B prefix instead of the A prefix.
In the duplicate, I renamed the layer states to have a B prefix instead of the A prefix.
I activated each of the renamed B layer states, and for each active state, saved its definition to be sure that it was registering the B layer names.
I imported the layer states into the base .3dm model.
All 7 of the B layer states were imported.
The A layer states continued to work as expected.
The B layer states were confused. In the main, they activated the A layers instead of the B layers. There are a few odd B layers activated, but it was not the expected clean B versions of the layer states.
It has the appearance of the B layer states ‘remembering’ that they were originally created with A prefix layers selected, and although they were resaved with the B layers selected, after importing they ‘see’ the A layers and revert to them, even though the B layers are also there.
I have attached 2 models which show the problem. Steps to demonstrate:
Open KDRBase.3dm.
In Layer State Manager, import the layer state from KDRBaseB.3dm.
You will see that the B Lower Floor layer state activates the layer ALF Ground Slab instead of BLF Ground Slab.
Could it be that the layers are internally known via an underlying code number or name, and that code is overriding the user level layer name? In KDRBaseB.3dm, the ALF Ground Slab layer no longer exists, so no such override would be possible. Interestingly, the B Lower Floor layer is activated by the B Lower Floor layer state, which might be related to the fact that it is a parent layer with no objects.
Remember that as mentioned in post 1, the B Ground Slab layer in KDRBaseB.3dm was renamed from A Ground Slab in the duplicated model.
@Japhy This is one of those times when it is not good to be correct. Can you suggest a clever workaround? It will be a pest to have to build the layer states from scratch, but it is looking like I will have to do so.
@Brian That is better, but there is a problem which might have a different origin. When I follow the steps that I outlined above for KDRBase.3dm and KDRBaseB.3dm, the imported B layer state keeps the A objects active, even though the A objects are not in KDRBaseB.3dm. The reference to the possibility of a different origin relates to other experiences where I have seen layers incorrectly remaining active after switching layer states. It does not always occur, but it is a regular pest. It is generally overcome by toggling through layer states until the required layer state remembers is true set of active layers.
@dale The imported layer state should know nothing of the A objects, because KDRBaseB.3dm only has B objects. After importing the layer state, on activation the A objects and B objets are active. Inly the B objects should be inactive.
I am using Version 8 (8.25.25294.11002, 2025-10-21).
@dale The B Lower Floor layer state should turn off the A objects. It came from a model which has no A objects, so the layer state should not make them active.
Hi Garry,
Here is what we know about the Layer State feature:
The Layer State does not dynamically update with the model if additional layers are added.
It also does not create layers that were present in the layer state if they do not exist in the model.
It is a “snap shot” of the layers and their settings or states at a particular point in time.
If the layers change after of the state is created, only the original layers will be affected when the layer state is restored.
This is not what we expect. When the layer state was saved, there were no Layers that were prefixed by “A” so there is not knowledge of how to restore them in the Layer State.
Start by opening the “B Lower Floor”,
“B Lower Floor” layer state has no knowledge of any additional layers that are present in the model down steam, unless you save a Layer State that is updated it with the new layers.
Now open KDRBase.3dm.
Import the “B Lower Floor” Layer State. (Remember: it is a snap shot of layers in the other model, that has no layers that are prefixed with a “A”.)
Restore “B Lower Floor”. Turn off the “A” layers.
In the Layer States dialog, right click on “B Lower Floor” and pick Update.
Test:
“A Lower Floor” will turn off B
“B Lower Floor” will turn off A.
See this workflow here.
Summary:
A Layer State can not know about layers that “will” be created in the future.
If there are layers in the Layer State that are not in the model, it will not create them.
Use the Update feature to updated Layer State over time when additional layers are added.
Hope this helps.
Sincerely,
Mary Ann Fugier
McNeel Technical Support
@mary Thank you. It does help with the understanding, even if it does not get me to where I had hoped.
I had noticed this, and it is a pest when there are many layer states that require updating.
That is as expected.
My expectation was that upon restoring a layer state, all layers would be set as inactive, then the layers present in the model and defined as active or inactive within the layer state would be set accordingly. I might be a lone voice on this, but I think it would be a better approach, saving much time in unwanted updates to layer states. It would also overcome the other issues that you have mentioned. My thought is that it is easier and more appropriate to add new layers to the relevant layer states than to have to update layer states that have no interest in the new layers. I will leave it to those with more experience to call.
