Hi guys,
Not sure if this has been reported so far but I noticed the following behavior when using the latest WIP:
I had a set of layers, one of them had name “Default”.
After I saved the model and opened it after some time (still with latest WIP) I found out that another 10 layers starting with default have been added. See enclosure. Moreover, objects have been transferred to different layers!!! This seems to be a serious bug to me.
Can you please investigate asap?! Reassigning objects back takes quite some time.
Hello @pascal,
I am not using this in the current file. But I was experimenting with Worksessions - rather simple operations like adding and removing of the Worksessions. I am 100% sure that before I quit the file, I saved it when no Worksessions have been attached.
This happened here a while back but I couldn’t repeat it, it’s a pretty dangerous bug as you save the file you’ve been working on and close down, then next time you open, after a reboot, all the geometry is taken from their layers and placed on a new numbered default layer, with default color and linetype and the original layers are empty.
Just looked a bit deeper and here is what happens. (using files attached)
Open file A
Worksession attach File B (from drop down menu)
Save
Detach file B (from ws manager dialog)
Save
Close Rhino
Re-Open Rhino
Re-open file A
This is repeatable here and the re-opened file has the layers messed up as described.
Hi Brian,
I think it was me who first reported this a while back. This has been a show stopper for me as I use worksessions quite a bit, but I don’t think that’s the only cause and not only the default layer gets duplicated, things go all over the place and geometry goes to wrong layers and wow what a can of worms that was. Your example is trivial compared to the amount of layers one has in a real worksession or Rhino file to begin with and when those go wrong there is no going back to try to get them right. I also think it might occur when one imports files into a layout and not just worksessions but I gave up after V6 started ruining my files.
Dan’s suggestion to give it a try is troublesome as I can’t ruin further files testing this, I guess I have to duplicate all my files in order to try it out and see if it really is squashed.
Glad you guys are trying to fix this.
RM
Hi Dan, still a problem in 29Aug17 WIP. I’ve experimented a bit more with this and I think you should be able to repeat the behaviour with the following. As @3dsynergy said, it’s a pretty big problem.
After attaching and detaching a worksession using the steps in my previous post, this is what appears to be happening. Follow the steps in the previous post with these files C and D to repeat the behaviour.
On the re-opened file C there are additonal rogue layers added to the top of the layer table, yet the original layer order remains, so the geometry all shuffles up the list filling the new layers.
The number of layers added corresponds with the number of layers in the attached worksession, so if the open file has many layers and the worksession has just a few, then the added rogue layers will populate with geometry from the corresponding no of original layers. All the remaining geometry in the file layers will jump up the list and the file becomes a huge mess.
It appears that the geometry on the default layer remains intact if the worksession has the same named layer current.
I also noticed the file survives if there are multiple Rhinos open and the worksession one is not the last to shut down.
In the meantime @3dsynergy beware of V6 worksessions until fixed, bad for your health to open a file in the morning that has been decimated… especially with a deadline. Thinking about this a bit more, you can correct the file by selecting by layer and placing the geometry back where it should be - might take a couple of hours but you get the file back in a working state.
The bug is fixed. Any WIP with a version date of Sep-7-2017 or later will contain the fix.
Basically, the layers of the detached worksession(s) were getting saved as new “Default” layers in the file. Because layer names must be unique, these names got 01, 02, … appended when the damaged file was read.
