+1David_Fine wrote:Yes, +1 to changing the Undo/Redo stack to not include movements on the timeline or moving from one layer to the other.
Redo not always working
Re: Redo not always working
MAC OS 12.6.2 - TVpaint 11.7.1 PRO 64bit, Wacom Intuos Pro
- David_Fine
- Posts: 557
- Joined: 29 Aug 2014, 16:39
Re: Redo not always working
What is this "spare" of which you speak? The Undo/Redo issue is about the way the stack of actions is recorded and that includes changes to artwork and changes to the timeline, like deleting an instance.momo wrote:Sorry to ask but I dont really understand why ask for change when you can simply use the already existing spare function which would does the exactly what would be needed in this situation. Spare is arguably even better since you can store a drawing for much longer...all this for the sake of making it the same as all the other software...I am not convinced.
David Fine
iMac late 2014 3.5 GHz, 32GB RAM
Snowden Fine Animation Inc.
Vancouver, Canada
iMac late 2014 3.5 GHz, 32GB RAM
Snowden Fine Animation Inc.
Vancouver, Canada
Re: Redo not always working
For the sake of discussion let's exclude the amazing History panel as an undo stack manipulation tool and work only with undo buttons or shortcut keys.
David proposes to remove frame changes or layer changes as entries in the undo stack. With frame and layer changes removed, how will TVPaint know WHERE IN THE TIMELINE and the LAYER STRUCTURE each stroke or other undo-able action is to be undone?
Assume there were 10 strokes on frame one followed by a (non-stack-recorded) MANUAL frame change to frame two where10 more strokes are applied. With frame two still current, the artist decides to undo the last 15 strokes.
Question: After all 10 strokes (20 - 11) on frame 2 are removed... how will TVPaint know it is to move to frame 1 to continue removing five more strokes? Will the artist have to remember to manually move back to frame one before continuing to undo strokes 10 - 6?
Right now, all the frame changes and layer changes are interleaved between all the other undo-able actions in the undo stack and TVPaint automatically manages to move to the right frames and layers during undo operations. It seems to me all that goes away if frame changes and layer changes are tossed out.
Sven
David proposes to remove frame changes or layer changes as entries in the undo stack. With frame and layer changes removed, how will TVPaint know WHERE IN THE TIMELINE and the LAYER STRUCTURE each stroke or other undo-able action is to be undone?
Assume there were 10 strokes on frame one followed by a (non-stack-recorded) MANUAL frame change to frame two where10 more strokes are applied. With frame two still current, the artist decides to undo the last 15 strokes.
Question: After all 10 strokes (20 - 11) on frame 2 are removed... how will TVPaint know it is to move to frame 1 to continue removing five more strokes? Will the artist have to remember to manually move back to frame one before continuing to undo strokes 10 - 6?
Right now, all the frame changes and layer changes are interleaved between all the other undo-able actions in the undo stack and TVPaint automatically manages to move to the right frames and layers during undo operations. It seems to me all that goes away if frame changes and layer changes are tossed out.
Sven
TVP Pro 11.0.10-64bit Win10 - 64GB ram -2TB HHD - 256GB SSD - Wacom Cintiq 16, driver 6.3.41-1
Android Tablet: rel. 11, Samsung Galaxy Note10.1 - 32GB with microSD 32GB
Android Tablet: rel. 11.5, Samsung Galaxy Tab S7plus - 128GB with microSD 64GB
Android Tablet: rel. 11, Samsung Galaxy Note10.1 - 32GB with microSD 32GB
Android Tablet: rel. 11.5, Samsung Galaxy Tab S7plus - 128GB with microSD 64GB
- Paul Fierlinger
- Posts: 8100
- Joined: 03 May 2008, 12:05
- Location: Pennsylvania USA
- Contact:
Re: Redo not always working
One word: KeyFramer.
Particularly in light of David already having spent all this time in search of the best do/redo command, he might want to consider giving the KF a try now to discover how simple it really is once one grasps the clear logic of KeyFramer's functionality.
David, keep in mind that you might decide somewhere, way down the road, that the action in that scene could use some more tweaking AFTER all has been colored, and the KF will still be opened right there the way you left it, all setup and ready for another tweak and it will be über simple. You could even set it up so that each character will have its own KF stacked up on top of each other so that you could scrub the timeline with each character activated and watch them interact in real time before you make the final render.
Particularly in light of David already having spent all this time in search of the best do/redo command, he might want to consider giving the KF a try now to discover how simple it really is once one grasps the clear logic of KeyFramer's functionality.
David, keep in mind that you might decide somewhere, way down the road, that the action in that scene could use some more tweaking AFTER all has been colored, and the KF will still be opened right there the way you left it, all setup and ready for another tweak and it will be über simple. You could even set it up so that each character will have its own KF stacked up on top of each other so that you could scrub the timeline with each character activated and watch them interact in real time before you make the final render.
Paul
http://www.slocumfilm.com
Desktop PC Win10-Pro -64 bit OS; 32.0 GB RAM
Processor: i7-2600 CPU@3.40GHz
AMD FirePro V7900; Intuos4 Wacom tablet
http://www.slocumfilm.com
Desktop PC Win10-Pro -64 bit OS; 32.0 GB RAM
Processor: i7-2600 CPU@3.40GHz
AMD FirePro V7900; Intuos4 Wacom tablet
- David_Fine
- Posts: 557
- Joined: 29 Aug 2014, 16:39
Re: Redo not always working
I totally get the value of the keyframer, but for simple undo and redo of editing or drawing, etc, I am thinking that it should exclude movement on the timeline. As regards Svengali's point, I am no programmer, but it seems to me that the stack can ignore timeline movements where no other action takes place. That is, if I go to another instance and draw on that, then the stack should record that as an action. If I move to that same instance and do nothing, it should ignore that. That is, you have to do something.
In Photoshop, if I click to another layer, it does not record that action. If I click to another layer and draw on it, it records the drawing and knows where I did it. TVPaint should work the same way as Photoshop in that regard. TVPaint is unique in recording movement or viewing as a step. It shouldn't.
In Photoshop, if I click to another layer, it does not record that action. If I click to another layer and draw on it, it records the drawing and knows where I did it. TVPaint should work the same way as Photoshop in that regard. TVPaint is unique in recording movement or viewing as a step. It shouldn't.
David Fine
iMac late 2014 3.5 GHz, 32GB RAM
Snowden Fine Animation Inc.
Vancouver, Canada
iMac late 2014 3.5 GHz, 32GB RAM
Snowden Fine Animation Inc.
Vancouver, Canada
Re: Redo not always working
The whole issue of the Undo Stack and its idiosyncrasies concerning frame changes and layer changes could be settled with a single post by any one of the programmers. I guess sometimes silence speaks volumes.
I'm no programmer either, just a TVPaint user of eight years... but I suspect things are not as simple as you suppose in a piece of software as complicated as TVPaint, where its highly likely that changing frames or changing layers has enough hidden consequences that these seeming "non-events" must necessarily be used as way points in the construction of a dynamic, undo-able history, so as to organize and maintain huge volumes of visual data with minimal impact on speed of execution.
The evolution of any mature cross-platform software (on many different architectures and generations of hardware technology and generations of bug-ridden, continuously updated operating systems) will have established a developmental and philosophical history that required many layers of workarounds and clever innovation that subsequent code must have been built upon.
I'd guess that the functionality of the Undo Stack was established early on and is directly tied to the fact that TVPaint output consists of pixel-based images that are updated in real time. Undo-able operations must always deal with that reality. No doubt, the practical consequences of that simple fact more than anything else have shaped how Undo / Redo works.
Given all that, I can see that simply viewing a sequence "seems" like it should not trigger a frame-change event in the Undo Stack. Yet, historically, it always has and I think I understand why.
But if that bit of functionality can be changed without any other consequences then I'm all for it, too, and I'll add a provisional +1.
Sven
I'm no programmer either, just a TVPaint user of eight years... but I suspect things are not as simple as you suppose in a piece of software as complicated as TVPaint, where its highly likely that changing frames or changing layers has enough hidden consequences that these seeming "non-events" must necessarily be used as way points in the construction of a dynamic, undo-able history, so as to organize and maintain huge volumes of visual data with minimal impact on speed of execution.
The evolution of any mature cross-platform software (on many different architectures and generations of hardware technology and generations of bug-ridden, continuously updated operating systems) will have established a developmental and philosophical history that required many layers of workarounds and clever innovation that subsequent code must have been built upon.
I'd guess that the functionality of the Undo Stack was established early on and is directly tied to the fact that TVPaint output consists of pixel-based images that are updated in real time. Undo-able operations must always deal with that reality. No doubt, the practical consequences of that simple fact more than anything else have shaped how Undo / Redo works.
Given all that, I can see that simply viewing a sequence "seems" like it should not trigger a frame-change event in the Undo Stack. Yet, historically, it always has and I think I understand why.
But if that bit of functionality can be changed without any other consequences then I'm all for it, too, and I'll add a provisional +1.
Sven
TVP Pro 11.0.10-64bit Win10 - 64GB ram -2TB HHD - 256GB SSD - Wacom Cintiq 16, driver 6.3.41-1
Android Tablet: rel. 11, Samsung Galaxy Note10.1 - 32GB with microSD 32GB
Android Tablet: rel. 11.5, Samsung Galaxy Tab S7plus - 128GB with microSD 64GB
Android Tablet: rel. 11, Samsung Galaxy Note10.1 - 32GB with microSD 32GB
Android Tablet: rel. 11.5, Samsung Galaxy Tab S7plus - 128GB with microSD 64GB
Re: Redo not always working
Svengali, you understood perfectly the nub of the problem and you explained it very well.
In TVPaint, you have a layer stack + frames.
Currently, in TVPaint, if you simply change the cursor position in the timeline without any further change (drawing, apply an FX, whatever), the Undo stack won't remember each new position.
If you change the cursor position + apply a change (drawing, FX, whatever), the Undo stack will record the new cursor position + the change you did.
Why ?
Because TVPaint manages layers and frames. If the position was not saved at the same time as your strokes, when you undo you wouldn't see what your are undoing (you could affect image 2 while being on image 100).
The fact the cursor + the change are saved together is logical and safe. It prevents you to undo "too much" without noticing it.
In Photoshop, you have one layer stack.In Photoshop, if I click to another layer, it does not record that action. If I click to another layer and draw on it, it records the drawing and knows where I did it. TVPaint should work the same way as Photoshop in that regard. TVPaint is unique in recording movement or viewing as a step. It shouldn't.
In TVPaint, you have a layer stack + frames.
Currently, in TVPaint, if you simply change the cursor position in the timeline without any further change (drawing, apply an FX, whatever), the Undo stack won't remember each new position.
If you change the cursor position + apply a change (drawing, FX, whatever), the Undo stack will record the new cursor position + the change you did.
Why ?
Because TVPaint manages layers and frames. If the position was not saved at the same time as your strokes, when you undo you wouldn't see what your are undoing (you could affect image 2 while being on image 100).
The fact the cursor + the change are saved together is logical and safe. It prevents you to undo "too much" without noticing it.
Re: Redo not always working
Lost in all the other comments in this thread was the significance of this brief but profound gem of wisdom from ZigOtto about using "FlipBook-Play".ZigOtto wrote:that's why I'm not personally affected by this undo/redo issue,
cause I always use my "FlipBook-Play" shortcut to check my drawing changes in my workflow,
I "play" the full preview only in the final to check (and tweak) the timing (instance's exposure) in real time.
When you assign the "FlipBook-Play" shortcut to some key (the spacebar for instance) and always use that, the UNDO/REDO stack works in the exact way David and other users are looking for...
You can UNDO strokes or other actions in the stack, to some place lower in the UNDO/REDO stack.
You can then review the results of these UNDOs on the action by pressing the spacebar to start and stop viewing.
You can start and stop viewing as many times as you want... JUST DON'T EVER USE THE START OR STOP BUTTONS ON THE WINDOW INTERFACE OR THE REMOTE PANEL! THAT IS WHAT TRIGGERS THE "CHANGE CURRENT IMAGE" ENTRY AND TRUNCATES EVERYTHING BEYOND ON THE UNDO/REDO STACK!
After you see what the animation looks like and you have stopped viewing by pressing the spacebar you can do one of several things.
1. If you have stopped viewing and you are on the same frame you were editing, you can
- (a) Press REDO to step back up the stack (the erased strokes or other actions will be restored, one step at a time.)
- (b) Start adding new strokes or other actions to that frame which will truncate the stack, losing everything beyond, and add new stuff to the stack.
2. If you have stopped viewing and you are on another frame, you can
- (a) Press REDO and return immediately to the top of the UNDO/REDO stack RESTORING all strokes and other actions that you UNDID. (Wrong, pressing REDO still truncates the stack with a "Change current image" losing everything beyond. Sorry. )
- (b) Use the cursor keys to move back to the frame where you first pressed the spacebar and then you can
----- Press REDO to step back up the stack (the erased strokes or other actions will be restored, one step at a time.)
----- Start adding new strokes or other actions to that frame which will truncate the stack, losing everything beyond, and add new stuff to the stack.
- (c) Stay on the new frame or move to another and start drawing which will truncate the stack, losing everything beyond, and add new stuff to the stack.
Again. As ZigOtto suggests, DON'T USE THE START OR STOP BUTTONS ON THE WINDOW INTERFACE OR IN THE REMOTE PANEL EXCEPT WHEN YOU ARE READY TO "PLAY" THE FULL PREVIEW ONLY TO CHECK (AND TWEAK) THE TIMING (INSTANCE'S EXPOSURE) IN REAL TIME!
Finally, I have to say, the nuanced difference between using the PLAY and STOP buttons as opposed to the "FlipBook:Play" shortcut and the divergent consequences of each choice for playback MUST be more clearly explained somewhere (in the manual???). It's something I was totally unaware of until I started watching the History stack and noticed inconsistent results. That sent me back to ZigOtto's comment and suddenly it all made sense. Thanks Zig.
Sven
TVP Pro 11.0.10-64bit Win10 - 64GB ram -2TB HHD - 256GB SSD - Wacom Cintiq 16, driver 6.3.41-1
Android Tablet: rel. 11, Samsung Galaxy Note10.1 - 32GB with microSD 32GB
Android Tablet: rel. 11.5, Samsung Galaxy Tab S7plus - 128GB with microSD 64GB
Android Tablet: rel. 11, Samsung Galaxy Note10.1 - 32GB with microSD 32GB
Android Tablet: rel. 11.5, Samsung Galaxy Tab S7plus - 128GB with microSD 64GB
Re: Redo not always working
Oh this allows to to save a frame to use it again if needed. You can find this handy function: edit->spare->copy to spareDavid_Fine wrote:What is this "spare" of which you speak? The Undo/Redo issue is about the way the stack of actions is recorded and that includes changes to artwork and changes to the timeline, like deleting an instance.momo wrote:Sorry to ask but I dont really understand why ask for change when you can simply use the already existing spare function which would does the exactly what would be needed in this situation. Spare is arguably even better since you can store a drawing for much longer...all this for the sake of making it the same as all the other software...I am not convinced.
I use this a lot to do what I thought you wanted to do with the redo/undo button. With that function I can test 2 keys and see which one works best.
Like Paul said
this is the limitation of the spare function.Paul Fierlinger wrote:Spare will take only single images, not an entire anim layer.
Another idea instead of changing the redo/undo function which seems very complicated, could be to develop that "spare" function more... we could have image a spare panel where you have a list of frames o that are saved for you to re use if need be. That way you can always re apply/use a drawing anywhere you want in the layer even after changing the timing or doing anything.
But then again why do this complicated change when I can simply copy past the drawing I might want to re use on another layer that I name "spare".
momo
- Paul Fierlinger
- Posts: 8100
- Joined: 03 May 2008, 12:05
- Location: Pennsylvania USA
- Contact:
Re: Redo not always working
That's what I sometimes do as well. Or to keep my current clip clean of the clutter of spare layers, I make a copy of the clip in the project tab (think of it as a spare clip) and work out my intricate actions in the spare clip from where I can either copy and paste my best layer back to the clean clip, or copy and paste the best layer via the KeyFramer if I also need to alter the sizes of a character.But then again why do this complicated change when I can simply copy past the drawing I might want to re use on another layer that I name "spare".
But in the end, I think most workflows can't be that simply transferred from artist to artist because we each have a tendency to be self taught and our individual workflows can go far back within the History Panels of our brains where one outside change can collapse our entire mindsets and send us into a tizzy -- at least this has been often my case..
Paul
http://www.slocumfilm.com
Desktop PC Win10-Pro -64 bit OS; 32.0 GB RAM
Processor: i7-2600 CPU@3.40GHz
AMD FirePro V7900; Intuos4 Wacom tablet
http://www.slocumfilm.com
Desktop PC Win10-Pro -64 bit OS; 32.0 GB RAM
Processor: i7-2600 CPU@3.40GHz
AMD FirePro V7900; Intuos4 Wacom tablet