Robert Penner easing equasions for f-curves #22084

Closed
opened 2010-04-20 03:17:12 +02:00 by Dan Eicher · 52 comments
Member

%%%This adds a few more interpolation types aside from constant, linear, and bezier to the interpolation mode menu, a new sub-menu in the graph editor 'Key' menu, one new operator (GRAPH_OT_easing_type) and a couple extra properties to the python 'Keyframe' object.

The (optional) extra parameters for Back and Elastic don't have a UI method to set them but they can be set through python.

Threw in a cheezy animated gif demoing the bounce, circle and elastic functions.%%%

%%%This adds a few more interpolation types aside from constant, linear, and bezier to the interpolation mode menu, a new sub-menu in the graph editor 'Key' menu, one new operator (GRAPH_OT_easing_type) and a couple extra properties to the python 'Keyframe' object. The (optional) extra parameters for Back and Elastic don't have a UI method to set them but they can be set through python. Threw in a cheezy animated gif demoing the bounce, circle and elastic functions.%%%
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Member

%%%Quick code review:

  1. Code organisation: yuck!
    In C, we do NOT implement functions in headers. That is a bad C++ practice.

If you must, you could include this as a separate C file. However, a better alternative would be to just add within fcurve.c, like

/* ******************************* */
<... license info ...>

<... code ...>
/* ******************************* */

(see math libs in blenlib, and also dual quaternion stuff in blenkernel/intern/armature.c for examples of code that's been included like this)

  1. Division by zero errors - it seems that these are likely to occur. Duration between keyframes CAN get quite small in some cases (i.e. if user turned off time snapping and moved keyframes quite close to each other unintentionally). Be careful about this.

  2. Small nitpick - try to follow the existing code styles around these areas a bit (with regards to brackets/braces), thanks.


Functionality:
Currently, the relationship between easing and interpolation is not immediately clear. Could you please include a user-level description of the functionality provided by this patch too, including basic info on usage. Next time, it'd be nice to have such a summary at the start of the patch description so that it's easier for everybody to get on the same page regarding the functionality :)

Also the interpolation types could probably do with some descriptions, since some of these appear quite cryptic (e.g. "Quart" and "Quint"?!). Names like "Expo" and "Quad" probably should be written out in full (e.g. "Exponential" and "Quadratic") for the UI; see RNA guidelines for more info.

Probably after seeing this, we can better evaluate how to present those other parameters for "Back" and "Elastic". It'd be nice to try and present this via familiar 'handle' widgets like for Bezier curves. Probably it is even possible to derive the needed values from the lengths or relative positions of these handles from the keyframes as needed? Or perhaps there are also other nicer possibilities. I would personally prefer though that we try and keep this as visual as possible (i.e. avoid resorting to just showing a few number fields where users have to guess the numeric values, especially not as an operator popup too, or restricting this to being python-backend only since this is something that all artists should be able to have direct and easy control over).


If you can make these changes, then we can try and get some user testing going on this. This certainly looks like useful functionality for speeding up the animation workflow, in particular for "motion-graphics" types, so it'd be great to see this in action.

Cheers!%%%

%%%Quick code review: 1) Code organisation: yuck! In C, we do NOT implement functions in headers. That is a bad C++ practice. If you must, you could include this as a separate C file. However, a better alternative would be to just add within fcurve.c, like /* ******************************* */ <... license info ...> <... code ...> /* ******************************* */ (see math libs in blenlib, and also dual quaternion stuff in blenkernel/intern/armature.c for examples of code that's been included like this) 2) Division by zero errors - it seems that these are likely to occur. Duration between keyframes CAN get quite small in some cases (i.e. if user turned off time snapping and moved keyframes quite close to each other unintentionally). Be careful about this. 3) Small nitpick - try to follow the existing code styles around these areas a bit (with regards to brackets/braces), thanks. ---- Functionality: Currently, the relationship between easing and interpolation is not immediately clear. Could you please include a user-level description of the functionality provided by this patch too, including basic info on usage. Next time, it'd be nice to have such a summary at the start of the patch description so that it's easier for everybody to get on the same page regarding the functionality :) Also the interpolation types could probably do with some descriptions, since some of these appear quite cryptic (e.g. "Quart" and "Quint"?!). Names like "Expo" and "Quad" probably should be written out in full (e.g. "Exponential" and "Quadratic") for the UI; see RNA guidelines for more info. Probably after seeing this, we can better evaluate how to present those other parameters for "Back" and "Elastic". It'd be nice to try and present this via familiar 'handle' widgets like for Bezier curves. Probably it is even possible to derive the needed values from the lengths or relative positions of these handles from the keyframes as needed? Or perhaps there are also other nicer possibilities. I would personally prefer though that we try and keep this as visual as possible (i.e. avoid resorting to just showing a few number fields where users have to guess the numeric values, especially not as an operator popup too, or restricting this to being python-backend only since this is something that all artists should be able to have direct and easy control over). --- If you can make these changes, then we can try and get some user testing going on this. This certainly looks like useful functionality for speeding up the animation workflow, in particular for "motion-graphics" types, so it'd be great to see this in action. Cheers!%%%
Author
Member

%%%Ok, fixed it up a bit.

  1. took the functions out of the header but left them in their own file because they may be useful somewhere else later like maybe with the 'easing operator' someone is bound to eventually write or wrapped up in python goodness.

  2. the most obvious case already had a check (duration == 0) and I'm pretty sure that the only other one I could find (time and/or begin == 0) can't lead to divide by zero

Changed the names to reflect the underlying function -- not that it makes it much clearer though...WTF is a quintic? Aside from providing the mathematical formula don't know what else can be done about that.

Maybe it would be better to just have the Exponential function take an extra parameter that tells it how many times to square it?

For access to the extra function parameters for "Back" and "Elastic" I'm thinking that the 'N' property pane needs to have an 'Active Key' panel that is similar to the already existing 'Active F-Curve' section. Easy enough to do in python (once the animation API is a bit more stable) and tacked on to space_graph.py.

Setting the in/out and interpolation function using the menu is a bit clunky where an N-key panel would have all the settings with a click and a glance.

There's a website http://ianhaigh.com/easeandwizz/ (with fancy videos even) that shows end usage of these that explains it a lot better than I ever could.%%%

%%%Ok, fixed it up a bit. 1. took the functions out of the header but left them in their own file because they may be useful somewhere else later like maybe with the 'easing operator' someone is bound to eventually write or wrapped up in python goodness. 2. the most obvious case already had a check (duration == 0) and I'm pretty sure that the only other one I could find (time and/or begin == 0) can't lead to divide by zero Changed the names to reflect the underlying function -- not that it makes it much clearer though...WTF is a quintic? Aside from providing the mathematical formula don't know what else can be done about that. Maybe it would be better to just have the Exponential function take an extra parameter that tells it how many times to square it? For access to the extra function parameters for "Back" and "Elastic" I'm thinking that the 'N' property pane needs to have an 'Active Key' panel that is similar to the already existing 'Active F-Curve' section. Easy enough to do in python (once the animation API is a bit more stable) and tacked on to space_graph.py. Setting the in/out and interpolation function using the menu is a bit clunky where an N-key panel would have all the settings with a click and a glance. There's a website http://ianhaigh.com/easeandwizz/ (with fancy videos even) that shows end usage of these that explains it a *lot* better than I ever could.%%%
Author
Member

%%%Missed an #include in the last patch.

Also added in a property sub-panel for "Active Key" (which is really just the first selected one it finds) to demonstrate what I was saying about property access.

...and a screenshot of the new sub-panel.%%%

%%%Missed an #include in the last patch. Also added in a property sub-panel for "Active Key" (which is really just the first selected one it finds) to demonstrate what I was saying about property access. ...and a screenshot of the new sub-panel.%%%
Author
Member

%%%Getting the curves to display properly (screenshot) was amazingly easy so another quick update.

Think this is functionally complete now.%%%

%%%Getting the curves to display properly (screenshot) was amazingly easy so another quick update. Think this is functionally complete now.%%%
Member

%%%Comments on the Drawing Updates:
I was going to ask about this earlier, but I'm glad that you've picked up that it's needed. However, the way that you've implemented it now will only work in simple test cases where the first keyframe already uses one of the new interpolation modes. If you can't find any easier way, we might just resort to always sampling the curves, though this carries performance consequences for general cases.

Comments on the Active Key Panel:

  • While you're doing this, you could add numeric inputs for the other two handles (if they're used) too, since it appears that animators still like to manually tweak these directly.
  • Also, to test if a keyframe is selected, you could use the BEZSELECTED(bezt) macro instead of (bezt->f1 || bezt->f2 || bezt->f3)
  • While it might be nice to have a true 'active keyframe', I think just taking the first selected might be sufficient for now. Doing any more there can be left for a later date.%%%
%%%Comments on the Drawing Updates: I was going to ask about this earlier, but I'm glad that you've picked up that it's needed. However, the way that you've implemented it now will only work in simple test cases where the first keyframe already uses one of the new interpolation modes. If you can't find any easier way, we might just resort to always sampling the curves, though this carries performance consequences for general cases. Comments on the Active Key Panel: - While you're doing this, you could add numeric inputs for the other two handles (if they're used) too, since it appears that animators still like to manually tweak these directly. - Also, to test if a keyframe is selected, you could use the BEZSELECTED(bezt) macro instead of (bezt->f1 || bezt->f2 || bezt->f3) - While it might be nice to have a true 'active keyframe', I think just taking the first selected might be sufficient for now. Doing any more there can be left for a later date.%%%
Author
Member

%%%Ok, got this thing finished I hope.

Added a flag to draw the (pretty) easing curves or to default to the (bland) bezier curves.

Added context sensitivity in the 'Active Key' panel and also inputs for the handles and control point.%%%

%%%Ok, got this thing finished I hope. Added a flag to draw the (pretty) easing curves or to default to the (bland) bezier curves. Added context sensitivity in the 'Active Key' panel and also inputs for the handles and control point.%%%
Member

%%%Sorry, that flag is a really ugly hack (usability wise). This is an example of something that users should not have to worry about explicitly.

What is all that +/- 11.272 stuff about? Where does it come from, and why is it needed?

The code for checking the previous keyframe (for Active Key -> Handle 1) is dangerous. What you've got there should fail when called on the first keyframe (i.e. bezt-- = who knows what!).%%%

%%%Sorry, that flag is a really ugly hack (usability wise). This is an example of something that users should not have to worry about explicitly. What is all that +/- 11.272 stuff about? Where does it come from, and why is it needed? The code for checking the previous keyframe (for Active Key -> Handle 1) is dangerous. What you've got there should fail when called on the first keyframe (i.e. bezt-- = who knows what!).%%%
Author
Member

%%%Removed the offending code and fixed the pointer math issue.%%%

%%%Removed the offending code and fixed the pointer math issue.%%%
Member

%%%Hi,

Just thought I'd give a status update on this FYI.

Due to the delicate state of the Durian pipeline at this stage, I'm somewhat reluctant to push such radical changes into trunk at this stage. Probably will have to wait till after Durian.

Also, just committed a active-key panel based on the one in the patch here. Thanks.%%%

%%%Hi, Just thought I'd give a status update on this FYI. Due to the delicate state of the Durian pipeline at this stage, I'm somewhat reluctant to push such radical changes into trunk at this stage. Probably will have to wait till after Durian. Also, just committed a active-key panel based on the one in the patch here. Thanks.%%%
Author
Member

%%%Updated the patch to reflect the new active-key panel in trunk.%%%

%%%Updated the patch to reflect the new active-key panel in trunk.%%%
Author
Member

%%%Updated for current svn (42717)%%%

%%%Updated for current svn (42717)%%%
Member

%%%Ok, a quick updated code review to see if we can get this into trunk :)


  1. It appears that the operator to set easing mode works on a per-keyframe basis? If that's the case, it needs to go in the Key menu not the Channels menu

  2. There are a few code formatting quirks that should be resolved before this goes into trunk (though I could fix this up later/post commit as well).

a) Switch statement formatting
b) Brace placement on function-level for fcurve_easing.c
c) Line 408 of patch - keep the existing code style there! i.e. Explicitly surround each case there.

See http://aligorith.blogspot.com/2011/12/avoiding-degenerative-coding-practices.html

  1. ANIM_editkeyframes_easing() - double check the comments beside each case ;)

  2. Line 451 of patch (BEZT_IPO_BEZ eval case) - why the break statement inside the if here. IMO it's redundant and just confuses matters.

  3. Ideally it'd be nice to see if we could hack up some optimised interpolation for drawing routines instead of relying on the curve sampling method for drawing everything. This approach does have some downsides, such as some aliasing issues arising from sampling frequency vs drawing everything that we didn't have in the past for the common bezier-interpolation case that the majority of animators use. However, in the interests of not complicating things and just having a sane reference implementation for now, we'll just go with what's there :)


In response to earlier comments

  • Ah, I see the check for duration==0 now. Cool, that should be fine now I guess :)%%%
%%%Ok, a quick updated code review to see if we can get this into trunk :) ------------ 1) It appears that the operator to set easing mode works on a per-keyframe basis? If that's the case, it needs to go in the Key menu not the Channels menu 2) There are a few code formatting quirks that should be resolved before this goes into trunk (though I could fix this up later/post commit as well). ``` a) Switch statement formatting b) Brace placement on function-level for fcurve_easing.c c) Line 408 of patch - keep the existing code style there! i.e. Explicitly surround each case there. ``` See http://aligorith.blogspot.com/2011/12/avoiding-degenerative-coding-practices.html 3) ANIM_editkeyframes_easing() - double check the comments beside each case ;) 4) Line 451 of patch (BEZT_IPO_BEZ eval case) - why the break statement inside the if here. IMO it's redundant and just confuses matters. 5) Ideally it'd be nice to see if we could hack up some optimised interpolation for drawing routines instead of relying on the curve sampling method for drawing everything. This approach does have some downsides, such as some aliasing issues arising from sampling frequency vs drawing everything that we didn't have in the past for the common bezier-interpolation case that the majority of animators use. However, in the interests of not complicating things and just having a sane reference implementation for now, we'll just go with what's there :) --------- In response to earlier comments - Ah, I see the check for duration==0 now. Cool, that should be fine now I guess :)%%%
Member

Added subscriber: @plasmasolutions

Added subscriber: @plasmasolutions
Member

Thanks @JoshuaLeung for noticing me - It seems that is exactly what I searched for!

Thanks @JoshuaLeung for noticing me - It seems that is exactly what I searched for!
Member

As we assumed @JoshuaLeung this patch didn't work in master anymore, so I manually added all changes to a clean master and diff'ed it. This is the newest patch.

I'm still testing it but here are already a few things I think about it:

  1. It's great for motion graphics work and adds many features I am doing manually atm
  2. If this makes it to trunk we should consider adding control points for the generated curves - many things are quite there, but I need some manual tweaking (with handles) still.
  3. Can't say something codwise as my PC just started working again and I wanted to share the patch, but I will!

Apart from that I will keep testing it now to look for more optimizations and better UI - but it is of great help already.
And last but not least: Thanks @dna-7 for the initial implementation - I love this feature already!

Greetings, Thomas

As we assumed @JoshuaLeung this patch didn't work in master anymore, so I manually added all changes to a clean master and diff'ed it. This is the newest patch. I'm still testing it but here are already a few things I think about it: 1) It's great for motion graphics work and adds many features I am doing manually atm 2) If this makes it to trunk we should consider adding control points for the generated curves - many things are quite there, but I need some manual tweaking (with handles) still. 3) Can't say something codwise as my PC just started working again and I wanted to share the patch, but I will! Apart from that I will keep testing it now to look for more optimizations and better UI - but it is of great help already. And last but not least: Thanks @dna-7 for the initial implementation - I love this feature already! Greetings, Thomas

Added subscriber: @mark.b.tomlinson

Added subscriber: @mark.b.tomlinson

Added subscriber: @xrg

Added subscriber: @xrg

Added subscriber: @LeoMoon

Added subscriber: @LeoMoon

I would love to see this get integrated into Blender.

I would love to see this get integrated into Blender.

Added subscriber: @Januz

Added subscriber: @Januz

Added subscriber: @davidmcsween

Added subscriber: @davidmcsween

Thanks for the heads up plasmasolutions I really miss this kind of automation when adding detail in a limited time. It really saves me lots of clicking. However I would appreciate some KF handles and a variable for bounce (number of rebounds for example).

Thanks for the heads up plasmasolutions I really miss this kind of automation when adding detail in a limited time. It really saves me lots of clicking. However I would appreciate some KF handles and a variable for bounce (number of rebounds for example).

Added subscriber: @sevensheaven

Added subscriber: @sevensheaven

Very useful for motion graphics and animated infographics. I really hope this will soon be added to a main Blender release, or at least become available as an add-on, if possible.

As David mentioned, an input option for the number of bounces would be great.

Very useful for motion graphics and animated infographics. I really hope this will soon be added to a main Blender release, or at least become available as an add-on, if possible. As David mentioned, an input option for the number of bounces would be great.

Added subscriber: @SMB1243

Added subscriber: @SMB1243

I find this feature handy and a great time saver. I look forward to seeing it added into the release.

I find this feature handy and a great time saver. I look forward to seeing it added into the release.

Added subscriber: @PauloJoseOliveiraAmaro

Added subscriber: @PauloJoseOliveiraAmaro

WOW! How it did take 4 years to come to life? Thank you so much @plasmasolutions for recovering and updating this great patch! I've been doing this bounce effect by hand for a long time! You can't imagine how it will help me in my work.

WOW! How it did take 4 years to come to life? Thank you so much @plasmasolutions for recovering and updating this great patch! I've been doing this bounce effect by hand for a long time! You can't imagine how it will help me in my work.
Member

@PauloJoseOliveiraAmaro :) You're welcome,... but the real work is now starting. After the release @JoshuaLeung, @dna-7 and me have to find the best possible way to implement that in Blender - I really hope that we will find a way to make that happen.
@JoshuaLeung what is the next step we should take here?

Greetings, Thomas

@PauloJoseOliveiraAmaro :) You're welcome,... but the real work is now starting. After the release @JoshuaLeung, @dna-7 and me have to find the best possible way to implement that in Blender - I really hope that we will find a way to make that happen. @JoshuaLeung what is the next step we should take here? Greetings, Thomas
Member

@plasmasolutions: I guess we shall start with a code review of the patch :) In recent months, I've also been considering whether to set up a temporary "animation staging branch" to test and prepare a few pending patches.

  1. The "Easing Mode" menu entry in space_graph.py would be better in the keyframes menu. That's because, just like with the interpolation settings, it's a per-keyframe setting instead of a whole-curve thing (which extrapolation is).
  2. Looking at this again now, it seems that the easing code (fcurve_easing.c/h) should probably go into blenlib instead of blenkernel. That's because it doesn't actually touch any specific Blender data structures; the code is simply called from other code as if they were library functions (like most of the math library functions). In fact, we may as well call that module BLI_math_easing or something similar?
  3. The formatting in the editors code (i.e. "mode= RNA_..." should become "mode = RNA_...") needs some tidying up for the new style guides
  4. Some tooltips on the ease in/out properties would be good. Currently IMO it doesn't seem entirely obvious at times which one of these you'd want/need to use...
@plasmasolutions: I guess we shall start with a code review of the patch :) In recent months, I've also been considering whether to set up a temporary "animation staging branch" to test and prepare a few pending patches. 1) The "Easing Mode" menu entry in space_graph.py would be better in the keyframes menu. That's because, just like with the interpolation settings, it's a per-keyframe setting instead of a whole-curve thing (which extrapolation is). 2) Looking at this again now, it seems that the easing code (fcurve_easing.c/h) should probably go into blenlib instead of blenkernel. That's because it doesn't actually touch any specific Blender data structures; the code is simply called from other code as if they were library functions (like most of the math library functions). In fact, we may as well call that module BLI_math_easing or something similar? 3) The formatting in the editors code (i.e. "mode= RNA_..." should become "mode = RNA_...") needs some tidying up for the new style guides 4) Some tooltips on the ease in/out properties would be good. Currently IMO it doesn't seem entirely obvious at times which one of these you'd want/need to use...
Member

@davidmcsween: As always, having visual "in-place" controls always beats having just numeric fields to edit. However, coming up with a suitable design for these and then integrating these with the rest of the transform system here (EEK!) is not exactly a trivial feat. I'd consider this as a bit of a nice add-on/followup patch for this, once we get it in.

@davidmcsween: As always, having visual "in-place" controls always beats having just numeric fields to edit. However, coming up with a suitable design for these and then integrating these with the rest of the transform system here (EEK!) is not exactly a trivial feat. I'd consider this as a bit of a nice add-on/followup patch for this, once we get it in.
Member

@JoshuaLeung I agree on all your points and I will talk with @dna-7 about wether he likes to alter the code. If he does not, I will. Especially since we can now show tooltips in enums it should help new users a lot if we got meaningful tooltips there.

As I prepare some speed measuring website for Brecht for the Cycles CPU optimization task and writing a comprehensive handbook about Blender atm, I will work some hours a week on it, so don't expect immeditate updates in a day or so... but as the release is at least 3 weeks away and this feature won't make it into 2.70 we'll have enough time to tackle those minor issues.

I agree on your follow up idea too. Let's get this in first and then make it even nicer :)

@JoshuaLeung I agree on all your points and I will talk with @dna-7 about wether he likes to alter the code. If he does not, I will. Especially since we can now show tooltips in enums it should help new users a lot if we got meaningful tooltips there. As I prepare some speed measuring website for Brecht for the Cycles CPU optimization task and writing a comprehensive handbook about Blender atm, I will work some hours a week on it, so don't expect immeditate updates in a day or so... but as the release is at least 3 weeks away and this feature won't make it into 2.70 we'll have enough time to tackle those minor issues. I agree on your follow up idea too. Let's get this in first and then make it even nicer :)

@plasmasolutions, I'm very excited, but I'll be patient. I'm sure all of you will do a great job for this feature! :-)
About the tooltips, I think some icons also could help to make easier the recognition. Simple icons created just to spread the idea:
{F76679 size=full}

@plasmasolutions, I'm very excited, but I'll be patient. I'm sure all of you will do a great job for this feature! :-) About the tooltips, I think some icons also could help to make easier the recognition. Simple icons created just to spread the idea: {[F76679](https://archive.blender.org/developer/F76679/easing-icons.png) size=full}
Member

@PauloJoseOliveiraAmaro Great icons! I like them very much and will use them once I will work on this...

@PauloJoseOliveiraAmaro Great icons! I like them very much and will use them once I will work on this...

Removed subscriber: @sevensheaven

Removed subscriber: @sevensheaven

Added subscriber: @sevensheaven

Added subscriber: @sevensheaven

Hi guys,

I've unsubscribed from the discussion, but my interest in the plug-in is still as great as before. Keep up the good work, and I'm eagerly awaiting the Blender implementation!

Thanks,

Metin

Hi guys, I've unsubscribed from the discussion, but my interest in the plug-in is still as great as before. Keep up the good work, and I'm eagerly awaiting the Blender implementation! Thanks, Metin

Removed subscriber: @sevensheaven

Removed subscriber: @sevensheaven

I didn't know that tooltips could have icons? Could you select the type of curve in place from the icon list?

I didn't know that tooltips could have icons? Could you select the type of curve in place from the icon list?
Member

@davidmcsween: Tooltips cannot have icons. Menus/dropdowns however can.

@davidmcsween: Tooltips cannot have icons. Menus/dropdowns however can.

@davidmcsween, my suggestion was to add icons to Set Key Interpolation menu (trigged by pressing "T"). Something like that:
blender-easing-proposal.png
The same options would be showed in Interpolation menu from N panel, if I'm understanding correctly.

@plasmasolutions, thank you! :-) When you need the SVG, just tell me.

@davidmcsween, my suggestion was to add icons to Set Key Interpolation menu (trigged by pressing "T"). Something like that: ![blender-easing-proposal.png](https://archive.blender.org/developer/F77025/blender-easing-proposal.png) The same options would be showed in Interpolation menu from N panel, if I'm understanding correctly. @plasmasolutions, thank you! :-) When you need the SVG, just tell me.

Added subscriber: @FilipMond

Added subscriber: @FilipMond

Added subscriber: @tanel58

Added subscriber: @tanel58
Member

With 2.70 now frozen and about to be released, and development opening up again, I'd like to look into getting this into master within the next week or so (barring any major distractions which may crop up) :)

With 2.70 now frozen and about to be released, and development opening up again, I'd like to look into getting this into master within the next week or so (barring any major distractions which may crop up) :)
Member

@JoshuaLeung, Great news Joshua! Are you willing to look into features like "bounce count", "manual adjustment handles" and things like this before merging it? Or do you like to get it in and then improve it?

Greetings, Thomas

@JoshuaLeung, Great news Joshua! Are you willing to look into features like "bounce count", "manual adjustment handles" and things like this before merging it? Or do you like to get it in and then improve it? Greetings, Thomas
Member

Manual adjustment handles and icons will have to wait till after the merge. From the looks of things, bounce count is somewhat baked into the code.

Manual adjustment handles and icons will have to wait till after the merge. From the looks of things, bounce count is somewhat baked into the code.
Member

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Member

Hi all,

I've just committed this patch to master (daccaa713b). Congrats to Dan and Thomas for all the work they've put in to getting this to this stage!

I ended up making a few formatting tweaks, tooltips, and a few other things (like some variable shadowing that was going on).

@PauloJoseOliveiraAmaro: It'd be nice to get a copy of that svg (or even better, a patch which adds icon support for these) :)

Hi all, I've just committed this patch to master (daccaa713b6e66af4b958fa373b31d557a4caa33). Congrats to Dan and Thomas for all the work they've put in to getting this to this stage! I ended up making a few formatting tweaks, tooltips, and a few other things (like some variable shadowing that was going on). @PauloJoseOliveiraAmaro: It'd be nice to get a copy of that svg (or even better, a patch which adds icon support for these) :)

Hi @JoshuaLeung : I don't know how to make a patch, and I could give you the svg file right now, but I think I could help in making the icons that are actually needed. The icons I did they was just to show the idea and they may be not enough.

Tell me exactly what icons are needed and I'll create them. And what is better, to create them in the actuall blender icons file or in a separated svg?

Hi @JoshuaLeung : I don't know how to make a patch, and I could give you the svg file right now, but I think I could help in making the icons that are actually needed. The icons I did they was just to show the idea and they may be not enough. Tell me exactly what icons are needed and I'll create them. And what is better, to create them in the actuall blender icons file or in a separated svg?

@JoshuaLeung, I would like to know exactly which icons are needed so I can create them, if you still need them.

@JoshuaLeung, I would like to know exactly which icons are needed so I can create them, if you still need them.
Member

@PauloJoseOliveiraAmaro : Ah, thanks for the reminder. I've added a separate design task for this discussion. See #39855

@PauloJoseOliveiraAmaro : Ah, thanks for the reminder. I've added a separate design task for this discussion. See #39855
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
13 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#22084
No description provided.