• Editor

  • Curve Presets in 4.0

    inglés

So 4.0 looks great but I can't seem to find a work around to the curve preset manager we used to have in prior versions. Is there a proposed method to making and saving preset types of curves or do we need to manually eyeball them each time? I ask this because I want all my animations to be sorta uniform in the way they move, and while I could achieve this by using the current presets, they are unfortunately pretty limited (for instance, one style of ease-in/out, with no variance in how extreme you can get with that (outside of manual editing). No preset for specific broken cuts). Another problem I'm finding is that there are times I don't want the immense amount of control the curve graph offers and would prefer to just click a preset instead (especially if I end up preferring working in the dopesheet over the graph).

If there is no current replacement for the preset manager can we get it back in a future update? Thanks!

Related Discussions
...

  • Nate

  • Publicación n.º 3
  • Publicación en inglés

In < 4.0 versions the graph is based on relative values. For the X axis: the left edge of the graph is the first key's frame and the right edge is the next key. For the Y axis, the bottom of the graph is the first key value and the top of the graph the next key value. That is not a value graph: the curve you see in < 4.0 versions does not show how the absolute value changes over time. Instead it shows how the value changes relatively between key frames and values. This relative graph is suboptimal because it loses the scale of the change in both dimensions. It also prevents seeing more than one curve at a time, which means it's very difficult to get smooth transitions through keys. We provided that visualization only because we had many other things to get right and adding the proper graph we have now would have been too much of a burden at that time.

Storing handle positions as presets for the < 4.0 graph made some sense. Because the X and Y axes are relative, you could apply the same handle positions to another key to get the same relative curve. However, as mentioned, the relative curve is ultimately not very useful. It's not what you need to see and think about when animating.

In 4.0, the X axis is frames and the Y axis is values. The curve you see accurately represents how the value changes during the animation. Let's explore how presets would work in the 4.0 graph:

Consider the first curve:

Image removed due to the lack of support for HTTPS. | Show Anyway


Here's what it could look like to apply the handle positions to another curve, keeping the relative distance from the handle to each key:

Image removed due to the lack of support for HTTPS. | Show Anyway


It doesn't result in the same curve. You'd need to have the same difference in both X and Y between the keys to obtain the same curve, which is rare. With anything else, you get some other curve that is difficult to anticipate and unlikely to be what you want.

Instead, say you could store handle positions, remembering the X and Y positions as relative percentages, similar to how the < 4.0 graph worked. The first curve is the same as above:

Image removed due to the lack of support for HTTPS. | Show Anyway


Here's what it would look like to paste the handle positions as relative percentages to another curve:

Image removed due to the lack of support for HTTPS. | Show Anyway


The resulting curve looks similar, but since there are differences between the keys in X and Y, the curve has changed. When your keys are spaced differently in X or Y, which is very common, applying a preset like this probably doesn't give you the exact curve you want. It may be similar, but if you have to move handles at all after applying a preset, you probably would have been better off just moving the handles in the first place. It is very fast to adjust the curve on a case-by-case basis and the result is higher quality. The curve is what matters, not the exact handle positions.

In the < 4.0 graph it may have felt nice to have the handles for different keys to look the same, but the relative graph is not what matters. The value graph is what matters and the actual curve you were getting there was not the same, as shown above.

There is also a caveat with storing handle positions based on the difference between keys. This cannot be stored:

Image removed due to the lack of support for HTTPS. | Show Anyway


The difference on the Y axis is 0, so there is no relative change. This kind of curve cannot be described in Spine 3.8 at all. Sure, it's an edge case, but it happens occasionally.

We considered presets in the 4.0 graph, but ultimately decided their usefulness was limited. Moving handles is about as easy as applying a preset, but gives better results. We are open to bringing them back if we decide they are worth having (the functionality and the UI space).

I hear your point about sometimes wanting to work in the dopesheet. This will be most common as people first move to 4.0, as they are already used to working in the dopesheet and suddenly they need to adapt to the new (awesome) graph. Change is scary! However, the dopesheet is still the best choice for some tasks, such as when working with many different timelines and adjusting timing.

In < 4.0 setting the curves was done only in the graph. In 4.0 we added curve buttons to the dopesheet, mostly for stepped and linear, which never require any additional fiddling. I don't think it makes sense for the dopesheet to have more curve toolbar buttons, as those are better accessed in the graph. The toolbars in both views are already quite packed.

When you are working primarily in the dopesheet and you need to adjust curves, the problem is that you go to the graph and it's showing what? Probably a number of curves based on the rows shown in the dopesheet. What do you want it to show? Probably you want to select a key in the dopesheet and see only the curves for that in the graph. We don't currently have that functionality, but I think it would help for using a dopesheet-centric workflow and needing to adjust curves.

One way to do that might be to have two modes for the Sync button:

  • Graph -> Dopesheet for the graph-centric workflow, which is what we have now. The dopesheet shows only the rows for what is shown in the graph.

  • Dopesheet -> Graph for the dopesheet-centric workflow. The graph would show only the curves for the selected keys in the dopesheet.

That's our tentative plan so far, for 4.1. I know it's not the presets you asked for, but it may end up working well.

This is way more of a response than I likely deserved haha. Thanks so much for taking the time to write all this Nate.

I guess the problem stems from not having much of an animation background coming into spine in the first place, and then spending years getting accustomed to the program through just trial and error and self teaching. Problems I'm seeing with the new 4.0 methods likely have very obvious solutions but I have no reference on where to even begin tackling them.

One example I can think of is say you have a bone move and rotate on the same frames. It became obvious to me early on that it looks bad fast when the curves for these evenly timed (but not evenly valued) movements aren't the same. Based on what you explained about the old preset editor this wasn't actually producing exactly the same curves anyways (since I assume the value shift for the rotation was different from the value shift from movement, and thus the produced curves were in fact different), however the end result was satisfactory and more importantly worked incredibly fast considering it was multiple keys on what is now multiple curves that need to be edited individually. Thanks to your post I do realize they were never exactly the same due to the way the presets worked, so I can obviously overcome this and minor differences in the curves won't be noticeable, but this still seems like it will take far longer than what used to be highlighting and a button press.

Another problem is that I already have hundreds of assets built using my preset curves. For anything new I would need to find a way to match that. This is where having presets would be a major boon still, even though as you're pointing out they would still need editing after the fact. At least with my old presets still available I'd be starting from a closer spot and be able to clean it up knowing I was close to where I was before on every other asset I have in my game. This is only really a problem with a preexisting project, and wouldn't be an issue for an isolated animation or for a new project (and I suppose the solution is just to stick w/ 3.8 until moving on to something new). Another solution may be to work in 3.8 initially, then move the projects forward to 4.0 once I have them at least set up. The fact I can do this is why I really would prefer just having something resembling the curve preset manager re-implemented (because I can still do exactly what I'm proposing by simply using 3.8 and then moving the project forward to 4.0 after using said presets). I suppose the issue more has to do with the fact its a bad practice, and having it in as an actual feature kind of implies it's not one and would lead people down a bad path. Maybe just making it a toggled option deep in the preference menu could suffice (so that it's not on by default)?

In any case I'll try playing around more with 4.0 on a new model and see if I can figure out how to make this work for me, and worst case scenario I'll just revert back to using 3.8 for the rest of this project. Thanks again for taking the time to explain all this to me!

I'm happy to explain! You aren't the only one who misses presets and I think it's important that we give insight into why we don't have them anymore. It may help us understand how you want to use Spine. If it ends up with us being convinced that presets are actually worth having in Spine, then we'd bring them back.

I would hope our Animating with Spine series could help your animation skills. Have you seen the videos? They are here:
Animating with Spine
I highly suggest doing the exercises for each video. It's only 3 videos so far but we have big plans for future videos. Now that a lot of the basics are covered, the next videos are going to get really interesting!

Regarding translate and rotate on the same frames, I don't think there is rule that says this will look bad if they don't have similar curves. Instead it's about timing, spacing, and all the other animation principles (see the videos! 🙂). Normally I'd ask our animation expert Sinisa to explain, as he can better than I (it's him talking in the videos), but he's on summer vacation until next week.

I think I understand where you are coming from. I wouldn't expect that you'd need presets to match your existing work. Curves are quite situational. Your animations are going to be sooo much better in 4.0 because you have a much better view of the curves and can have smooth transitions through keys. I'd be interested in hearing how it goes if you stick with 4.0 and try to make do without presets for some time.

To me, with current presets graph view is just fine.

So I watched the first video and even just the aspect of rescaling key values in the graph view has me sold lol. That said I have some questions you can hopefully field since I'm struggling to figure out how to solve these issues.

1) currently when the bool is false, seperation of x and y curves still occurs. Is this intended? Is the point of the seperation bool simply to visually seperate them so they can be isolated? If this is the intended functionality I'd love some kind of toggle to allow for controlling x/y axis uniformly outside of having to highlight the keys to grab both stacked keys.

2) the first/last key (ie the loop point) are always treated as though their bezier handles are seperated. I could not find a way to make them act as though they were connected (the behavior of other bezier handles) which seems important to get appropriate curves at the loop point. Is there currently a way to do this?

Thanks again Nate!

1) Translate always has a curve for X and a curve for Y (unlike < 4.0), but the X and Y are keyed together. Try moving the X key and you'll see the Y key also moves (the connection is indicated by a dotted orange line when you hover a key). Notice a translate timeline shows up in the dopesheet as a single row.

Separating translate means you can move the X key to a different frame from the Y key's frame. You can also key only X or only Y, they are completely separate. Notice the X and Y timelines show up as two separate timelines in the dopesheet.

2) No, currently the first and last keys don't have their handles connected. They are truly different keys, so we need to add some special magicke to do this. We ran out of time and wanted to get 4.0 released, but we'll do it in the future. For now you'll have to just eyeball it to make a smooth transition. That's pretty easy, just make the handle lines straight.

You're welcome!

un mes más tarde

So I've tried and I've tried but I just can't get the curve editor to work for me. I leave every attempt feeling like a complete failure having spent 8x the amount of time I would have in 3.8 to achieve the same effect. I'm going to attempt to explain what's going on for me in case this is somehow useful to future updates.

As I see it, the basic problem I'm facing is this: I have spent 3+ years (maybe more?) working in the old (inferior) editor. In that time I've learned how to work within it, so all my muscle memory, timings, etc, are built off the logic of the old system. Jumping into 4.0's graph editor is overwhelming as a result. But it's more than just learning the graph, it also involves relearning how and when to key. I have found things that are easier to perform in the 4.0 graph editor, but being unable to go back to old methods in other areas makes it difficult to experiment with and slowly move over fully to just the graph editor. Instead of being able to slowly add in new techniques from 4.0, I'm basically forced to do EVERYTHING in a new way, right out the gate. At least for myself, this is not conducive to learning.

When I import a project from 3.8 to 4.0, it still has the curves set as they were from the 3.8 editor (ie: using my custom presets).

Custom Preset:

Imported to 4.0:

It's pretty obvious doing this where the problem w/ the old method lies, as you can see sharp edges near the keys. This is where 4.0 can be used to clean that up. Here is the same curves after straightening out the bezier nodes:

This is great! New tools that work with the old thing I currently had going on, I can wrap my head around this and can also start to see the imperfections of the old system and move forward. However, even excusing that, let's look at what the DEFAULT (and really only) preset options get us in 4.0:

Using the store tool we can see the difference between a custom preset and the new default preset. The problem here is, without presets, any time I want a curve like this I'm forced to hand make it. Whereas with the presets I could at least get it into the right ballpark and noodle it around to perfection from there. The old method ultimately takes less time. With a single key its obviously pretty minor, but over time this adds up.

As it stands I can currently make this work by doing everything in 3.8, then forking the file to a 4.0 copy and editing further from there. Obviously if anything new needs to be done I need to go back to the old 3.8 fork in order to make changes and bring them forward and copy them over. So I CAN achieve what I'm looking for currently, it's just very cumbersome.

Ultimately though, I think even ignoring these aspects, it would be beneficial to add some kind of custom preset option in. Being able to get keys closer to where you want them with a single press, even if it NEEDS to be edited afterwards, would save time. Making this an opt in option only in the settings too could alleviate any headaches you may be afraid of from people being overwhelmed by a feature like this (what with it being imperfect by nature).

Another issue I have with the current graph editor (and this may be a symptom of working with large files) is that the graph editor when viewing multiple keys is completely ineffective. Worse still is transforms almost ALWAYS need to have their x and y split in order to see curves at all.

Full Chart example. This is obviously unusable as is, and I'm assuming was never meant to really be played with:

Single Control Transform. The base x+y values are far apart enough that they cannot be viewed in tandem without mostly flattening the curves. This forces transform splitting and means manually editing the curves x + y bezier nodes separately:

A possible solution to this may be to have an option to change the graph to % changed rather than the actual keys? Or, if it makes any sense, having an option to ignore the actual values of one of the two (x/y) in favor of having the two curves at least inhabit the same space. Barring any solution though, being able to use presets would help with this as well, since we could at least get the x+y curves looking similar when we ultimately have to edit them individually.

Anyways, thanks for taking the time to read this if you got this far. I really don't want to come off like I'm just complaining arbitrarily and begging for a superfluous feature. The addition of custom curve presets would make a huge difference for me, and would actually allow me to slowly adapt to the 4.0 architecture, rather than being thrown into the deep end from the outset. I feel like an absolute idiot when trying to work in 4.0, and I'm honestly embarrassed to even post this, as I fear it really IS just me. But on the off chance it ends up helping to improve Spine I figured I owed it both to myself and to you all for creating such a fantastic animation program.

I feel like an absolute idiot when trying to work in 4.0, and I'm honestly embarrassed to even post this, as I fear it really IS just me.

Thanks for the suggestion here. I hope the situation get improved when I officially move to work in 4.0 in the future. Don't want to feel like an idiot in 4.x.

  • Nate

  • Publicación n.º 11
  • Publicación en inglés

@SoulKarl, thanks for the thoughtful post. Likely you're experiencing a mix of things. 4.0 is the first release of a very complex feature and it's a big change from what you are used to. It took us a lot of time and effort to get it where it is. Releasing it and getting it stable are required for it to be a solid foundation for us to continue improving it.

SoulKarl escribió

I have found things that are easier to perform in the 4.0 graph editor, but being unable to go back to old methods in other areas makes it difficult to experiment with and slowly move over fully to just the graph editor.

The old graph had to go for a few reasons. One is that we'd like the new graph to do everything the old one can do, if not better then at least as well. Another is that the new graph required a complete overhaul of just about everything. All of the internals for the dopesheet, how selections are made, how keys and curves are stored and applied, everything under the covers is new. The old graph could not just be kept around, it had to be nuked. If we wanted it, we'd have to rebuild it with our new systems. We have a long list of things we want to do. If we held off releasing until everything was done, we'd never release. I don't know if the old graph should be on that list, but even if it was, it still couldn't have gotten done for 4.0.

As mentioned, I'd prefer to find ways to completely replace the old graph with the new one. Identifying what the old one can do better is good and helps us consider how the new one needs to be improved.

If that were to prove impossible, there are still new challenges even if we wanted to bring the old graph back. The old graph can only give a myopic view of the 2 handles between keys. If you move a handle, the handle on the other side of the key needs to move to keep the curve passing through the key smooth. If we don't do that, you'd get a cusp (a sharp bend in the curve). If we do that, you can't see how you are changing the neighboring curve. It can't be drawn on the old graph due to the way it shows curves. You could see it on the new graph while you make adjustments on the old graph, but I'm not sure that makes for a good user interface.

let's look at what the DEFAULT (and really only) preset options get us in 4.0:

Using the store tool we can see the difference between a custom preset and the new default preset.

There are presets for auto, ease in, out, bounce, but yeah there aren't arbitrary presets you can store and apply to any key. That kind of preset is gone for similar reasons to the graph. There wasn't time and the feature is no longer as good of a fit as it was previously.

Your example is maybe not great since the stored curve is already very similar. The default/auto preset is ease in/out and the ease in and ease out presets get you close if you need that. Can you show a preset you store in 3.8 that those presets don't get you close?

As it stands I can currently make this work by doing everything in 3.8, then forking the file to a 4.0 copy and editing further from there.

Nooo this is not a great workflow. 🙁

Full Chart example. This is obviously unusable as is, and I'm assuming was never meant to really be played with:

Yep, the graph is generally intended for viewing a relatively small number of curves at once.

Single Control Transform. The base x+y values are far apart enough that they cannot be viewed in tandem without mostly flattening the curves.

This is a good point. However, there are some options. You are not required to use auto frame all the time. Often it works well, especially for shorter animations, but it's just not possible for auto frame to always provide the best view of your curves.

For a translate timeline in the graph, you can click a key, ctrl+A to select all keys for that curve, then click Frame (or setup a hotkey). That will frame just the selected keys. With the curves in your example, you won't be able to see the other curve, but you won't have to separate X and Y.

You can have more control over the axes zoom by holding alt and dragging the right mouse button. This can quickly get you to the view of a curve that you need.

We have considered other features to help with this. One is to normalize the Y axis, so all the curves are shown in the same space. This can be helpful, but it hides the magnitude of the values and so isn't useful for all curves (such as those that change only slightly) and isn't useful for comparing curves relatively. On top of that we could provide "stacked graphs", where each normalized curve gets it own graph, possibly with curves using the same units sharing a graph.

Anyways, thanks for taking the time to read this if you got this far. I really don't want to come off like I'm just complaining arbitrarily and begging for a superfluous feature.

Not at all. It's your job to have problems and our job to find the best way to solve them. 🙂

The addition of custom curve presets would make a huge difference for me, and would actually allow me to slowly adapt to the 4.0 architecture, rather than being thrown into the deep end from the outset.

I have to wonder if presets would make as big a difference as you expect. You'd apply a preset, then need to fix it up. You can do that with the 4.0 default presets, even if maybe they don't get you super close to start with. I have a feeling the issues are elsewhere, maybe with control of the graph view, getting the right selection to do what you need, with transferring curves from one key to another, or maybe with setting multiple curves at once.

One of the old graph's strengths was that you could set the curve for multiple keys at once. It is not always great to have multiple curves using the same interpolation and the old graph made curves that have a cusp at nearly every key, but it was certainly fast to get some sort of curve somewhat close to what you want. When that is good enough, it's very fast. When it's not good enough, in < 4.0 it is difficult to make the curves better from there.

Have you seen our Animating with Spine videos? Have you done the exercises with 4.0? It would be interesting to hear how you do and see the results. I know it can take quite a bit of time to do the exercises, but I think you'd find it worthwhile. We'll have the 4th video up in a week or so!

Lastly, it may be helpful to come at it from another angle. Instead of getting bogged down in the lowest level, setting individual keys and moving handles, you might try a pose-to-pose workflow using the favor tool. It can be an extremely fast way to animate and the results don't suffer for it, the quality can be as high or higher than other approaches.

We'll continue working on the graph in 4.1 and beyond. It's helpful to get early feedback, so be sure to check out the beta, even if you don't move your projects to it at that time. Note we haven't started much work on 4.1 yet. We want to, but we are still working on 4.0 stability. It's quite good, the most stable Spine has every been actually, but issues do keep cropping up daily and kill our time.

@Nate, thanks for the quick and thorough response! First let me clear something up because there seems to have been some miscommunication on my part. I have absolutely zero interest in dragging over the old graph editor from pre-4.0. I ONLY want the custom curve preset feature that was present with it. I agree that there's not really any benefit to re-implementing the old graph view when the new one is vastly superior. However, losing base functionality such as saved custom load outs still seems like a step back (assuming it isn't planned, I understand not being able to roll out 4.0 with every possible feature).

Nate escribió

There are presets for auto, ease in, out, bounce, but yeah there aren't arbitrary presets you can store and apply to any key. That kind of preset is gone for similar reasons to the graph. There wasn't time and the feature is no longer as good of a fit as it was previously.

Sorry, I didn't mean to imply there weren't default settings for the other basic types of curves, just that there is only one default for each. Also calling custom presets "arbitrary" feels a bit dismissive. How is it arbitrary if it saves me hours per animation (weeks per character, months per project???).

Nate escribió

Your example is maybe not great since the stored curve is already very similar. The default/auto preset is ease in/out and the ease in and ease out presets get you close if you need that. Can you show a preset you store in 3.8 that those presets don't get you close?

It's not an issue of needing to show a different preset though... this is an issue of needing to show a more extreme value shift. Here is the identical preset on a larger value shift:

I could continue to increase the value shift to further illustrate how far off the curve becomes. If it's off a little it can be off by a LOT the larger the change becomes, at least visually.

To be clear in terms of storing curves, I believe the "curve" I actually want to be able to store is the placement of the starting key's bezier handle, and the ending key's bezier handle. I'm not sure if that makes any more sense, but if it makes things more confusing feel free to ignore it.

Nate escribió

Nooo this is not a great workflow. 🙁

Ya, agreed - that was kinda my point 😛 Yet it is the only way I can currently dip my toes into 4.0 (hence my problem). Without doing this it is either all or nothing, and even when doing this again I need to fork just to play safe essentially. It feels bad and discourages me from even trying 4.0 further (whereas, with presets, I could at least stay in 4.0 and use it throughout, rather than as a finalization tool).

Nate escribió

This is a good point. However, there are some options. You are not required to use auto frame all the time. Often it works well, especially for shorter animations, but it's just not possible for auto frame to always provide the best view of your curves.

For a translate timeline in the graph, you can click a key, ctrl+A to select all keys for that curve, then click Frame (or setup a hotkey). That will frame just the selected keys. With the curves in your example, you won't be able to see the other curve, but you won't have to separate X and Y.

You can have more control over the axes zoom by holding alt and dragging the right mouse button. This can quickly get you to the view of a curve that you need.

I'm aware of these methods thanks to the first tutorial video, but it still only allows for editing of one curve at a time (and specifically for x+y values, I'm still just editing x or y.) In the x+y situation, what is the benefit of doing this over simply separating x and y and just still using auto frame? I can disable the split after editing too if there is some kind of performance loss from having them split. That seems way less cumbersome than highlighting keys just for framing every time i need to isolate them.

Nate escribió

I have to wonder if presets would make as big a difference as you expect. You'd apply a preset, then need to fix it up. You can do that with the 4.0 default presets, even if maybe they don't get you super close to start with.

I assure you presets would make a massive difference, and you've basically written my response here for me. Yup, you need to fix it up either way, however with 4.0 defaults you don't start close. Even if this only saves one second per curve, this adds up insanely fast over the lifetime of a single animation, let alone a full rig or a full project (or hell, the lifetime use of the program by the user). How is that alone not a valid argument for custom presets?

You are somehow ignoring the value of time saved via customized options while simultaneously relying on photoshop's custom scripting in order to import images w/ atlases/jsons. Like, spine would be unusable without that... I can't even imagine having to import the hundreds of pieces I have per rig and then having to place them all in the right spot. I mean technically it's possible, but it sure is a gigantic waste of time.

Nate escribió

I have a feeling the issues are elsewhere, maybe with control of the graph view, getting the right selection to do what you need, with transferring curves from one key to another, or maybe with setting multiple curves at once.

I have no problem with any of these things becoming easier, but I don't think it would fix the problem presented by removing the ability to store custom presets. This ultimately all just comes down to saving time. If you feel the old method of storing them sucked then I would assume that means there is a better solution to storing curve presets. The answer can't be "you can no longer store presets" because that isn't an improvement on presets, that's just a removal of them. Something is better than nothing, even if that something is deemed imperfect.

Nate escribió

One of the old graph's strengths was that you could set the curve for multiple keys at once. It is not always great to have multiple curves using the same interpolation and the old graph made curves that have a cusp at nearly every key, but it was certainly fast to get some sort of curve somewhat close to what you want. When that is good enough, it's very fast. When it's not good enough, in < 4.0 it is difficult to make the curves better from there.

Yup!!! This is it exactly. 3.8 method is much faster, but you can't clean it up as well as you can in 4.0... So why can't we just get the best of both worlds and allow for fast setup and nice custom fixing after that??

Nate escribió

Have you seen our Animating with Spine videos? Have you done the exercises with 4.0? It would be interesting to hear how you do and see the results. I know it can take quite a bit of time to do the exercises, but I think you'd find it worthwhile. We'll have the 4th video up in a week or so!

Yes, I've watched all three and while they did a good job of explaining the graph, they didn't do much in the way of acclimating us to animating anything more robust within it. Hopefully the fourth video delves into more complex forms than single bone/mesh animations.

Since you said before it helps to know where people find 4.0 graph editor thrives, this is it. It is absolutely amazing at dealing with a single bone/mesh or a single curve. I can make what I want much faster this way. The curves can also be used to achieve a curved (non-linear) motion of a transform using a single key (where as before the curves on a transform just served to ease-in or ease-out the landing/startup of a straight motion). As soon we start compounding the amount of controls and the amount of complexity it starts becoming exponentially harder than an animation would have been in 3.8.

Nate escribió

Lastly, it may be helpful to come at it from another angle. Instead of getting bogged down in the lowest level, setting individual keys and moving handles, you might try a pose-to-pose workflow using the favor tool. It can be an extremely fast way to animate and the results don't suffer for it, the quality can be as high or higher than other approaches.

I'll give this a shot!

Thanks again for taking the time to answer all of my concerns on this! I really do appreciate it.

  • Nate

  • Publicación n.º 13
  • Publicación en inglés
Nate escribió

there aren't arbitrary presets you can store and apply to any key

SoulKarl escribió

calling custom presets "arbitrary" feels a bit dismissive.

Arbitrary as in "based on or determined by individual preference or convenience". In other words, "there aren't presets that you can define yourself, store, and apply to any key".

SoulKarl escribió

It's not an issue of needing to show a different preset though... this is an issue of needing to show a more extreme value shift.

Thanks, it makes sense it's more off as the curve is larger.

SoulKarl escribió

To be clear in terms of storing curves, I believe the "curve" I actually want to be able to store is the placement of the starting key's bezier handle, and the ending key's bezier handle.

I've been assuming it would work as it did in v4: The position of the handle on the X axis is stored as a percentage of the distance between the first and second key's frame. The position of the handle on the Y axis is stored as a percentage of the difference between the first and second key's value. That allows the curve to adapt when applied to keys that are closer or farther away on either the X (frame) or Y (value) axes. My first post in this thread shows how that looks. It also mentions the inability to store the curve when the keys have the same values. We'd likely have to just ignore that case.

The units for the Y axis can vary, so it's not possible to store the handle Y position as an absolute value and be able to apply it to any key.

Nate escribió

I have to wonder if presets would make as big a difference as you expect. You'd apply a preset, then need to fix it up. You can do that with the 4.0 default presets, even if maybe they don't get you super close to start with.

SoulKarl escribió

I assure you presets would make a massive difference, and you've basically written my response here for me. Yup, you need to fix it up either way, however with 4.0 defaults you don't start close. Even if this only saves one second per curve, this adds up insanely fast over the lifetime of a single animation, let alone a full rig or a full project (or hell, the lifetime use of the program by the user). How is that alone not a valid argument for custom presets?

As I said, I'm not fully sold that presets would make as big a difference as you expect. There isn't a 1 second difference between fixing up a preset that is close and one that is less close. Such fix up is likely roughly the same effort. In the case where a preset gives you what you want without fix up, then I agree it has saved time. To me that case feels like a stronger argument for adding presets in 4.0.

There are other aspects of the 3.8 graph that I feel have a bigger impact on saving time than presets. That's why I went off on a tangent about those, I understand you're looking specifically for user defined presets in 4.0.

SoulKarl escribió

You are somehow ignoring the value of time saved

No, I am not. 🙂

SoulKarl escribió

If you feel the old method of storing them sucked then I would assume that means there is a better solution to storing curve presets. The answer can't be "you can no longer store presets" because that isn't an improvement on presets, that's just a removal of them. Something is better than nothing, even if that something is deemed imperfect.

In general there are reasons a feature can be no longer needed because new features render it obsolete. The jury is still out on presets coming back as they existed in 3.8 but there are definitely improvements we'll make to make adjusting curves (and using the graph overall) less time consuming. Your feedback is received loud and clear.

SoulKarl escribió

Since you said before it helps to know where people find 4.0 graph editor thrives, this is it.

Actually I was saying the opposite, that it's helpful to hear about what was easy in the old graph but is not easy to do in the new graph.

Hey Nate, thanks for the quick reply. Sorry if that last post came off confrontational at all, it was not my intent.

Nate escribió

As I said, I'm not fully sold that presets would make as big a difference as you expect. There isn't a 1 second difference between fixing up a preset that is close and one that is less close. Such fix up is likely roughly the same effort.

hmm I'm not sure I've explained myself well in regards to what I feel I would be getting out of presets, so let me try putting it this way. I know the curves I liked before, but I don't know instinctively where the bezier handles would be AROUND to make a similar curve in 4.0. Being able to start from a spot where they are in the vicinity of the right area would be beneficial, and would allow me to learn where to put them. If I am just blindly guessing I won't arrive at the same result that I have in the past, and that uniformity throughout is important to me for a consistent end product. So it's less that the speed increase is coming from moving it less distance (which, I agree, seems like a weird ask) but more that I just have no clue where i should be moving the handles in order to get somewhere near the old curves I'm used to. The time save is in seeing a close approximation of where I should be heading, not the small distance in movement it saves. This is also assuming it doesn't just work right out the box by doing the preset and then flattening the handles (2 button presses).

Nate escribió

Your feedback is received loud and clear.

Thank you, this is the main reason I felt I should post again (since this thread is older) as I am likely just going to stick with 3.8 for the most part for the time being, but didn't want to leave with the thought I had just moved onto 4.0 and there were no problems. I will continue to mess around w/ 4.0 here and there to get more acclimated to it, but just wanted to at least voice the concerns I had for it. I fully understand why you had to ditch this functionality in the first place and why it's not the most important use of your time to add it back in. Either way, worst case scenario I'm still very happy with 3.8 as a product, so I don't mind sticking back there for the time being. I look forward to seeing what comes with future updates 😃

Thanks again!

5 meses más tarde

@SoulKarl, check out the Curves view in 4.1.12-beta. 🙂