moving objects to different layer changes frame number #28871

New Issue

Kris Slazinski · 2011-10-11T15:00:46+02:00

Kris Slazinski commented

2011-10-11 15:00:46 +02:00

%%%When I move object to different layer with keyboard shortcut, current frame number changes to 1. Do as follows to reproduce the bug:

Load factory settings
Change frame by 10 for example (shift+up arrow, BTW why it is changed from just up arrow?)
Move object to layer 2 with M->2 and... when pressing 2, frame changes to 1. Strange.

Tested on Mac OS X and ubuntu. The bug is present on both.
%%%

%%%When I move object to different layer with keyboard shortcut, current frame number changes to 1. Do as follows to reproduce the bug: 1. Load factory settings 2. Change frame by 10 for example (shift+up arrow, BTW why it is changed from just up arrow?) 3. Move object to layer 2 with M->2 and... when pressing 2, frame changes to 1. Strange. Tested on Mac OS X and ubuntu. The bug is present on both. %%%

Kris Slazinski commented

2011-10-11 15:00:46 +02:00

Changed status to: 'Open'

Bastien Montagne commented

2011-10-11 15:11:56 +02:00

%%%Bug confirmed on my Debian wheezy 64… Seems like a very nasty shortcuts mismatch, will try to have a look at it :/%%%

Brecht Van Lommel commented

2011-10-11 15:35:45 +02:00

%%%It has to do with the undo system, and the problem seems to exist in both 2.59 and 2.60rc. If you do another operator like rotating the object in between, it doesn't happen. Changing frames will not do an undo push, and move to layer uses undo/redo to work, it's related to that somehow.%%%

Sergey Sharybin commented

2011-10-11 16:53:15 +02:00

%%%Brecht, it happens with any operator when changing it's properties. Probably, operator re-do system should ensure if global push was made..%%%

Bastien Montagne commented

2011-10-11 22:28:45 +02:00

%%%Bwa, this is a monster! Well, at least, it made me work & understand deep inside operators & undo system…

So, as said above, it’s an undo issue. The problem is that undoable operators only store their result in undo stack, not their initial state. So, when you undo (one way or another, from classical ctrl-Z to operator redo), you do not come back to the state just before the operator was applied, but to the state just after the previous undoable operator was applied… I.e. erase all non-undoable operators applied in-between.

I see no ideal way to fix this. The simplest solution is to store an additional undo step, just before applying any undoable operator (the attached patch is a proposition for that, but would need a check by someone more skilled in ops internals than me, I’m not sure I covered all possible cases…). This solves the problem, but has a drawback: it doubles the needed undo memory!

One could imagine to add a sort of “dirty” undo flag somewhere (WM, perhaps? or curundo?), to try to avoid dummy “init state” when applying several undoable ops in range…

But to be honest, I wonder why frame change is not undoable? Especially as the “current frame clicking/scrolling” of anim editors is undoable!

Anyway, I think we can postpone that to after 2.60!%%%

%%%Bwa, this is a monster! Well, at least, it made me work & understand deep inside operators & undo system… So, as said above, it’s an undo issue. The problem is that undoable operators only store their result in undo stack, not their initial state. So, when you undo (one way or another, from classical ctrl-Z to operator redo), you do not come back to the state just before the operator was applied, but to the state just after the previous undoable operator was applied… I.e. erase all non-undoable operators applied in-between. I see no ideal way to fix this. The simplest solution is to store an additional undo step, just before applying any undoable operator (the attached patch is a proposition for that, but would need a check by someone more skilled in ops internals than me, I’m not sure I covered all possible cases…). This solves the problem, but has a drawback: it doubles the needed undo memory! One could imagine to add a sort of “dirty” undo flag somewhere (WM, perhaps? or curundo?), to try to avoid dummy “init state” when applying several undoable ops in range… But to be honest, I wonder why frame change is not undoable? Especially as the “current frame clicking/scrolling” of anim editors *is* undoable! Anyway, I think we can postpone that to after 2.60!%%%

Joshua Leung commented

2011-10-12 01:41:56 +02:00

%%%Regarding the current rationale behind the frame change operators and undo:
http://aligorith.blogspot.com/2011/08/animator-poll-frame-change-undo.html

This just happens to be a sub case of the missing undo push. %%%

%%%Regarding the current rationale behind the frame change operators and undo: http://aligorith.blogspot.com/2011/08/animator-poll-frame-change-undo.html This just happens to be a sub case of the missing undo push. %%%

Sergey Sharybin commented

2011-10-12 09:29:17 +02:00

%%%We've got plenty of issues with undo stack and global undo. Better to solve them all at one by introducing re-thinked design of this system. Added to TODO (http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#Undo_stack)
Thanks for the report, but closing it now.%%%

%%%We've got plenty of issues with undo stack and global undo. Better to solve them all at one by introducing re-thinked design of this system. Added to TODO (http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#Undo_stack) Thanks for the report, but closing it now.%%%

Sergey Sharybin commented

2011-10-12 09:29:17 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2011-10-12 09:29:17 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

moving objects to different layer changes frame number #28871