Worksessions are killing my materials


Worksessions are killing my materials. I don’t know what to do when I use them because when I detach a worksession all the materials are left in the active file and if I delete them Rhino deletes textures that I need in other materials causing those materials to loose texture paths in the active file as happened in my decals.
When I detach a nonactive file, then save the active file, then close rhino and don’t save the worksession the next time I open the file all those materials are still present in my file, this should not be. Now I’m afraid to use purge materials because it killed my decal textures last time I used it.

So big bug, ws inactive file materials are left in active file even when the worksession is not saved.

Another bug is that when I attach a file via worksession Rhino just inadvertently changes the materials or doesn’t display the materials at all. In fact I had a building texture on a building in the active file that somehow got mapped to the cylinder of a piston crank. So to recap Rhino changes the materials of an inactive file remapping them with materials from the active file.

Third bug “blocks” in an inactive file either don’t texture or render black. I reported this years ago and it’s still in Rhino7. Now I remember why I gave up on using blocks. Please this needs a major fix and please make it so that materials in worksessions and blocks are left as is.


Is this the same problem you previously reported? Please leave Worksession mats alone

Hi RM - so far, trying to reproduce this as simply as possible, I cannot… I guess we need a bit more detail about the setup, or an example (simple as possible) set of files to worksession.

OK, well, I see some of this at least, when material names are duplicated. That part is the same as RH-66666 Worksession: respect attached file materials
I am not able to repeat the attached file materials hanging around in the file, so far. My guess of the moment is that fixing rh-66666 may also sort out some of the other bad stuff.


Hi @pascal ,
“666 is no longer alone”
I think it might have to do with blocks in a worksession and maybe how the materials are named? One attached file I use has blocks within blocks within blocks it’s quite large and has many materials. I noticed that the leftover materials in this case are from the blocks within that file. When I attach this file I never attach it as active since I only need it for viz.
In the image you can see some of the leftover materials. Sorry I can’t send any of this file. I’ll try in time to mock up something that will help find it but I think it’s pretty obvious.

Also I’m running into blocks in that worksession that lose their materials, but if I open the file alone the materials are fine and can be viewed and rendered. I think I sent a file a few years ago to S.Baer that illustrated this but never heard back about it.

I hope this can be fixed it’s pretty much a mess now.
Thanks for taking a look and for your help.

Hello! I can confirm that attaching/detaching files can leave orphaned materials in the scene.
If a material name already existed in the scene, the mat from the attached file will be imported with postfix [imported]. Attach the file again - another duplicate with [imported] [imported] in the name.
Generally, it’s hard to keep multiple files in sync, material-wise. How about some sort of shared matlib, which is auto-updated with every change (like textures)?

Purging helps to rid the scene of duplicate mats, but as 3dsynergy said, also removes unused mats that in some cases might be needed again.

A worst case scenario here is attaching a file with a google earth 3d scene (there’s a 'hacker’tool for getting them), which tends to have hundreds of mats with textures.

How about showing attached materials just like attached objects - greyed out, copypaste-able, but not change-able, and disappearing after detaching their file again?

OK, thanks - I’ll try to put together a setup with blocks that shows this - my simpler test does not, so far.

@Eugen - if I attach a file that contain a linked block with matterials assigned in the linked file, all these materials do show up and do not go away if I detach the file. However they do not survive in the ‘parent’ if it is saved and reopened - is that what you see?
If I attach/detach/attach the same file, so far, I do not see the [imported] so there must be another step I am missing.


Hello! Thanks! Don’t have access to Rhino in my vacation (will test back home), but I think the material duplication issue happens with or without blocks, does it not?

Hi Pascal,

Perhaps this,
1 detach the worksession file that contains the blocks etc. leaving the active file,
2 save the active file
3 exit rhino but say no to the save worksession prompt
I don’t know if these are the missing steps but for me I constantly get these orphaned materials.

Just did a little test:

  1. Materials from attached files should remain as they are, and not be replaced by a material with accidentailly the same name in the parent file. So, agreed that RH-66666 should be fixed.

Suggestion: attached mats are somehow highlighted/marked in the material panel, just like attached objects have a darker tone of yellow when selected. They can be copied/pasted there, but not changed or deleted, and disappear (!) again when the file is detached.
Or, you make the attached mats invisible (a feature you introduced recently on VisualArq’s behalf). I would prefer the first way, though.

  1. Once a file is attached, all it’s Materials are copied into the parent file (should a mat with the same name already exist, replaced - see 1), and stay there, even when the file is detached again.
    This has nothing to do with blocks.

  2. About this [imported] mat name postfix: can’t repro. Happened numerous times last year, though.

Something else:
A bug has been introduced lately: when a file is detached, it’s name remains in the layer panel as an orphan. It’s a regression. Can’t tell since when - some December release I think.
(This was always the same testfile, attached/detached a few times)

Besides, I had lots of diffuse crashes lately after attaching files, not even complex ones. I could not yet nail the problem.



Latest sr Version 7 SR14 (7.14.22010.17001, 2022-01-10)
I’m hoping this gets some serious attention. I don’t understand why someone changed this when it was working beautifully in V5.

If I have a file and it becomes large I split it apart into smaller chunks, but I might have the same materials in each file or they might have the same material name where the name is the same but the mapping or material has been altered or some of the same objects and layer names.

Now worksessions have become a major pain with this bug and are limiting my ability to use Rhino. I’m trying to get complex scenes that need compiling looking at and doing test renders. Now I have to explicitly look at each file and alter it just because it might have the same material or object in it or layer name or structure. I can’t waste this time nor frustration when this worked before but doesn’t now, sorry you guys need to come through on this and fix this please.