Only search projects.blender.org
 Log In
New Account
Home My Page Projects Blender 2.x BF release
Summary Activity Tracker SCM Files

Blender 2.6 Bug Tracker: Browse

[#26222] Alt-O (smooth) in Graph editor destroys fcurve handle type and data

Date:
2011-02-25 22:22		 Priority:
3
State:
Closed
Submitted by:
Josh Wedlake (joshwedlake) 		Assigned to:
Joshua Leung (aligorith)
Category:
Animation system		 Status:
Fixed / Closed
Relates to:
Duplicates:
Patches:
 
Summary:
Alt-O (smooth) in Graph editor destroys fcurve handle type and data
Detailed description
Pressing Alt-O to smooth f-curves in the graph editor causes the handles to become flattened in the value (y) axis and ignores any information they may previously have held. Smooth curves become slightly stepped due to this.

Also auto handles get converted to aligned handles which is probably not what the user wants.

There is also (as far as I can tell) no way to adjust the degree of smoothing. Perhaps a modal 'lazy' mouse slider (like the one used for push, relax and breakdown in the 3D view) would be easiest, or at least a post-operator panel as is used in the rest of blender.

Thanks

Followup

Message
  • Date: 2011-02-26 11:52
  • Sender: Joshua Leung
  • Could you give some examples of curves that when this is applied there are problems?
  • Date: 2011-02-26 14:56
  • Sender: Ton Roosendaal
  • I also want to urge reading the bug reporting guidelines. There's nothing better than a simple .blend file that illustrates errors.
  • Date: 2011-02-26 18:38
  • Sender: Josh Wedlake
  • sorry Ali,Ton, It happens on any fcurves so I didn't attach an example but this image shows the problem more clearly:

    http://www.pasteall.org/pic/9424

    note in the top image the 'flattening' of all the handles after smoothing.

    The pre-smoothing blend is here http://www.pasteall.org/blend/5406 though as I say it I haven't found fcurves this doesn't happen on yet, so I assumed a blend was useless and would only confuse the point. If you select all the fcurves in the graph editor the handles become flattened after pressing Alt-O.


  • Date: 2011-02-27 09:28
  • Sender: Daniel Salazar
  • I can confirm, noticed the same thing today

    For me it only happens when you use O *immediately* after changing the handle type or the curve interpolation mode. So this is probably something like an undo call missing or something on those lines
  • Date: 2011-02-27 15:53
  • Sender: Josh Wedlake
  • Hi Daniel,

    I go into the default scene and turn auto keyframe insertion on and rotate and translate the cube, jump a few frames forward, rotate and translate for a second time, then jump a few frames forward and rotate and grab for a third and final time. That gives me fcurves which suffer from the problem - I don't have to change handle types. Note I'm doing it three times to make sure I get some handles which aren't clamped as first and last handles usually are.

    The handles are auto-clamped by default for me and I don't have to change their type to get the error. When you say you are using 'O' do you mean O (Clean) or Alt-O (smooth)? I've only noticed the problem with the smooth tool Alt-O. I'm running r35190 compiled here, but it also happens in the latest Beta from blender.org.

    thanks
  • Date: 2011-03-03 01:19
  • Sender: Daniel Salazar
  • oh ok, then I noticed the same problem with 'O' clean. Could you check on what I said? try and do other stuff in the graph editor that triggers undo pushes before trying the smooth operator and see if that still triggers the bug

    cheers
  • Date: 2011-03-03 12:38
  • Sender: Joshua Leung
  • Regarding the original problems with the Smooth Curve operator:
    After studying your sample, it's clear that this was not really the kind of curves that I had in mind when designing this. To be able to support these, a recode of the way the operator does things will be necessary.

    Under this scheme, the idea behind flattening the handles was that you'd often get unsmooth curves just because you went and tilted some of the handles for local extrema, causing some unkeyframed overshoots, which also leads to changes in timing, which in turn often means unsmooth motion. This was mainly intended for really jittery mocap-type segments, for which such measures would be quite effective.

    I'll try to take a more detailed look into this at some point.
    (For triage checkers: if need be, mark this as "TODO" to get bugcount down) :)
  • Date: 2011-03-12 02:09
  • Sender: Joshua Leung
  • Made some improvements to the method used so that these cases fare better.
 

Attached Files:

No Files Currently Attached

Changes:

Field Old Value Date By
status_idOpen2011-03-12 02:09aligorith
close_dateNone2011-03-12 02:09aligorith
StatusInvestigate2011-03-12 02:09aligorith
assigned_tonone2011-02-26 14:56ton
CategoryTools2011-02-26 14:56ton
StatusNew2011-02-26 14:56ton