Undo/Redo history - Exclude layer state changes?

Is it possible to exclude layer state changes from the undo/redo history?

If I want to undo the most recent change (or changes) to a model using ctrl-z, I have to cycle back through any more recent layer state changes. When I’ve undone the relevant change(s), I then have to manually reinstate those layer changes I wanted to keep!

More worrying, if I undo a number of steps and then inadvertently make a layer change (even something as simple as visibility), all those potential redos are instantly lost!

I realise that UndoSelected is an option but I find there are occasions where I simply want to restore the model back to a specific point in the timeline but I’m happy with the layer structure in its current form.

It’s my belief that the model undo/redo history should be distinct from the layer history. I really hope there is a solution for this.

I would also like to be able to exclude Layer modifications from Undo History.

I doubt that it would be implemented as default behavior in Rhino, but perhaps exclusion could be a system level option in Rhino 6?

// Rolf

I’ve had this wish as well, but I’m not sure how general that is - this is the first I can recall hearing about it from the world outside- in any case, I am pretty sure it but it won’t happen in V6…

https://mcneel.myjetbrains.com/youtrack/issue/RH-39536

-Pascal

I think that most users most of the time are able to work with the system as it is because “that’s the way it works” while muttering only mild epithets about the laziness and stupidity and lack of understanding about how real users work which must characterize the entire development staff at McNeel. The rest of the time, too much to ignore, it’s seriously annoying and causes an unacceptable amount of wasted time and workflow disruption. Probably thought process derailment too.

The real problem is, however, that when you really consider what’s going on there’s lot’s of relatively independent processes that a user might like to undo without affecting the others. Can they all be tied back exclusively to either geometry or layers?

The quick answer is for the user to do it right the first time, but we all know how often that happens.

Well, most of the time, I am actually very happy to have layer actions in the undo stack, only rarely do I find it inconvenient. Given that you can only choose one or the other as a default, I personally would always have it enabled. There are certainly other people who feel the opposite though…

–Mitch

I’m kind of with @AlW - I put up with it… to my mind, layer state changes more like view or CPlane changes - these, correctly, IMHO, have their own undo stacks.

-Pascal

1 Like

I think so too…

Philip

What happens if you separate the layer undo stack from the rest and then:

  1. Create a new layer
  2. Make the layer current
  3. Add an object to the current new layer
  4. Undo the last two layer operations.

What happens to the object you added?

–Mitch

Yeah - good question - I don’t know off hand - the object is moved to the current layer, with a warning? Nervertheless it is a grumbly thing to me to wade through layer state changes (that I may want to keep) to get to a ‘geometry’ undo.

-Pascal

I think that would be a good solution.

Philip

Sorry to bring up an old thread, but how is this working on Rhino 7 now? Can we consider layer changes (hide/show, add/delete) part of the undo stack or can we control this behavior somehow?

currently no change from v6 behavior.