NlaStrip Tweak Mode - No automatic action length sync on exit #34645

New Issue

koil · 2013-03-15T02:31:38+01:00

koil commented

2013-03-15 02:31:38 +01:00

%%%--- Operating System, Graphics card ---
OS: Windows 7 Home Premium SP1 32 bit
Graphics: SIS Mirage 3 Graphics: SIS672 Internel

- Blender version with error, and version that worked ---

error: Blender 2.66.0 r54697 windows 32 bit
worked:

- Short description of error ---

Size of the NlaStrip is same after leaving Tweak Mode.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Timeline: select keying set LocRotScale.
3D View: move cube, insert keyframes (i).
Nla Editor: set time 10.
3D View: move cube, insert keyframes (i).
Nla Editor: freeze action.
Nla Editor: select action, tweak mode (TAB).
Nla Editor: set time to 20.
3D view: move cube, insert keyframes (i).
Nla Editor: object mode (TAB).

The size of the NlaStrip is small.
%%%

%%%--- Operating System, Graphics card --- OS: Windows 7 Home Premium SP1 32 bit Graphics: SIS Mirage 3 Graphics: SIS672 Internel - Blender version with error, and version that worked --- error: Blender 2.66.0 r54697 windows 32 bit worked: - Short description of error --- Size of the NlaStrip is same after leaving Tweak Mode. - Steps for others to reproduce the error (preferably based on attached .blend file) --- Timeline: select keying set LocRotScale. 3D View: move cube, insert keyframes (i). Nla Editor: set time 10. 3D View: move cube, insert keyframes (i). Nla Editor: freeze action. Nla Editor: select action, tweak mode (TAB). Nla Editor: set time to 20. 3D view: move cube, insert keyframes (i). Nla Editor: object mode (TAB). The size of the NlaStrip is small. %%%

koil commented

2013-03-15 02:31:38 +01:00

Changed status to: 'Open'

koil commented

2013-03-15 12:38:33 +01:00

%%%Found: NlaEditor: Header: Edit: sync_action_length.

Though should be automated.
Todo or Proposal.%%%

%%%Found: NlaEditor: Header: Edit: sync_action_length. Though should be automated. Todo or Proposal.%%%

Joshua Leung commented

2013-03-15 13:31:20 +01:00

%%%The lack of syncing here was somewhat on purpose, although I'm now a bit more open to some tweaks here than I've been since introducing the new system. In the intended workflow here, you're NOT supposed to go creating empty, near empty, or ridiculously short strips, and then start extending them and extending them and extending them :)

This is because in the past, we had terrible issues trying to correctly discern what exactly users did to their actions when it came to syncing time for these strips, making it all to easy to accidentally set the scaling factor to account for changes in length, and gradually squeezing everything in to 0.00000000000000...01 frames with a near-infinity scaling factor. While this was perhaps caused more by a potentially buggy implementation, this also doesn't sound that like such a healthy workflow to begin with, as we should be able to just care about simply keyframing motions as per normal, and THEN trying to retime them as whole units (or to add extra keyframes as separate strips to smooth over rough parts).
Actions aren't always used by a single strip. Having said that, it probably fits more with the "tweaking" concept that the syncing would only occur for the one being tweaked. But...
Sometimes we may actually not want to include the full action range. I'm aware of more than a few cases where you might have a few stray keyframes at the start which were added just to make it easier to have a certain motion flowing smoothly at the start of the action range. In this case, do we want to actually want users to have to constantly re-set the reduced range?
Strips may have other strips surrounding them. If we automatically try to extend the range of strips, it's easy to have situations where there simply isn't any room for the extra keyframes to go (in the current track). However, in the current situation, it is at least possible to see that perhaps there is truncation going on, and adjustments to timing (coinciding with changes in other tracks perhaps too) can be made first, and then the strip can be safely extended.

So really, performing this syncing is a can of worms. IIRC, I've put in a few operators that can be used to perform this syncing manually when needed.%%%

%%%The lack of syncing here was somewhat on purpose, although I'm now a bit more open to some tweaks here than I've been since introducing the new system. In the intended workflow here, you're NOT supposed to go creating empty, near empty, or ridiculously short strips, and then start extending them and extending them and extending them :) 1) This is because in the past, we had terrible issues trying to correctly discern what exactly users did to their actions when it came to syncing time for these strips, making it all to easy to accidentally set the scaling factor to account for changes in length, and gradually squeezing everything in to 0.00000000000000...01 frames with a near-infinity scaling factor. While this was perhaps caused more by a potentially buggy implementation, this also doesn't sound that like such a healthy workflow to begin with, as we should be able to just care about simply keyframing motions as per normal, and THEN trying to retime them as whole units (or to add extra keyframes as separate strips to smooth over rough parts). 2) Actions aren't always used by a single strip. Having said that, it probably fits more with the "tweaking" concept that the syncing would only occur for the one being tweaked. But... 3) Sometimes we may actually not want to include the full action range. I'm aware of more than a few cases where you might have a few stray keyframes at the start which were added just to make it easier to have a certain motion flowing smoothly at the start of the action range. In this case, do we want to actually want users to have to constantly re-set the reduced range? 4) Strips may have other strips surrounding them. If we automatically try to extend the range of strips, it's easy to have situations where there simply isn't any room for the extra keyframes to go (in the current track). However, in the current situation, it is at least possible to see that perhaps there is truncation going on, and adjustments to timing (coinciding with changes in other tracks perhaps too) can be made first, and then the strip can be safely extended. So really, performing this syncing is a can of worms. IIRC, I've put in a few operators that can be used to perform this syncing manually when needed.%%%

Joshua Leung commented

2013-04-26 15:46:06 +02:00

%%%While just checking on this again, I found that there was an unused define for this lurking around in the background. As a result, I've exposed this so that this behaviour can be enabled on strips that need it (though I must point out that it's still a bit rough).

See r.56314 for fix. Closing as "fixed" now :)%%%

%%%While just checking on this again, I found that there was an unused define for this lurking around in the background. As a result, I've exposed this so that this behaviour can be enabled on strips that need it (though I must point out that it's still a bit rough). See r.56314 for fix. Closing as "fixed" now :)%%%

Joshua Leung commented

2013-04-26 15:46:06 +02:00

Changed status from 'Open' to: 'Resolved'

Joshua Leung closed this issue

2013-04-26 15:46:06 +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

NlaStrip Tweak Mode - No automatic action length sync on exit #34645