• Editor
  • Spine 4 graph is inefficient OR I'm missing something

  • संपादित
Related Discussions
...

Hi everyone, I just want to add my voice to share that having a Graph window as large as the timeline with limited presets (meaning I have to toggle back and forth when I need to adjust curves) is a MAJOR cramp to my workflow. Approximately a 15% increase in time taken (10 additional minutes for every hour worked) from this one change. I've been using Spine 4 for about 2 months only on weekends for one job and Spine 3.8.99 for another on weekdays.

The difference has 3.8 come out as a very VERY clear winner since just having a small graph in 3.8 and mostly using ease presets allows for very easy overall adjustments.

I'm not sure if there's something to alleviate this that I'm missing, I notice the interpolation buttons but with no ease presets, those are ineffective. I deeply hope that this is can be considered as I will have to forego Spine 4 for animating until there's something to assist this.


Also thanks for all your hard work Esoteric Team. I hate to be someone who piles more in the way of work, though this is a bit too big of a hit to productivity to not say anything.

Thanks for your time

Can you show exactly what you are wanting to do and how you are doing it? This will help us determine if there is already an better way to do what you want, or if not then it will make it clear where the deficiency is with the 4.0 graph.

Did you see the two ease presets? There's ease in and ease out:
 Loading Image
 Loading Image
Those are not user defined, giving a basic easing curve, but I wanted to be sure you know about them. If you meant that you are missing user defined ease presets, can you show your 3.8 presets?

You said you need to toggle back and forth between the dopesheet and the graph when you need to adjust curves, does that mean you have them as separate tabs? It may help to use the graph above or below the dopesheet, possibly with Sync in the dopesheet. If space is at a premium, the graph and dopesheet views have options to hide the toolbars and/or rows.

stikkanimate लिखा

Also thanks for all your hard work Esoteric Team. I hate to be someone who piles more in the way of work, though this is a bit too big of a hit to productivity to not say anything.

Don't feel bad at all! We appreciate that you take time to explain where you are having pain, it's very helpful for us to improve Spine.

For us to make changes with any confidence, we need concrete scenarios that show the problem. For example, "when I need to do this, it's very time consuming because I do it like this". This involves a mix of features and workflow, so while it may be obvious for you with how you use the tools and the workflows you are using to animate, we may not be seeing the same issues. Clearly defining the use case ensures we understand the problem and once we have a solution allows us to be sure that the problem is solved nicely.

Thanks for the response Nate.

Here's my preferred 3.8 layout with a maximized tree, sufficient stage, timeline space, visible weights, mesh adjust and graph presets. Of which, graph presets, weights, tree and dopesheet are the most important. This layout is suitable but still somewhat cramped and often needs slight adjusting depending on character and action but that's no problem really.

https://drive.google.com/file/d/1ToO5rEeXoFbg22A6CXAKSay5mAQBApuY/view?usp=sharing
Here's a 6 second vid (170kb) of the presets I use daily. If it doesn't work and you're still interested, let me know and I'll just screenshot and upload them all.

In S4 however, the largest deficit is the screen space that the new graph requires in order to be on the screen at the same time. It has to be toggled in the same bar as Graph or if put in the same place as the rest, completely closes in on the stage space linked below.

I'm animating very complex characters for my 3.8 job and the stage space is well enough, but this one where the graph reaches well over the screen's halfway mark when it's extended to be usable; Is uncomfortable if not unfeasible to work with in the stage area for anything complex.

About the presets vs manually adjusting curves, I use them at about a 100:1 ratio. This allows me to save stage space by squashing the curve visual to a sliver and have consistent animation curves. The only thing I can think to suggest is to have Presets a new standalone window for curves since I could then shelve the rarely used Graph with the Dopesheet.

Edit: An additional idea too is make the divider between parameters and curves able to slide to the left, hiding the names while still keeping the visibility dots. This way there's more of the graph and less of the buttons and names

Thanks for the pics and video!

Have you tried hiding the toolbar and/or rows in the graph? We could have options to hide parts of the toolbar, instead of all or nothing.

The dopesheet could have visibility dots like the graph. These would control which timelines are visible in the graph, the same as the dots in the graph. This would let you control which curves are visible in the graph, without needing the graph rows visible.

We have a graph-centric workflow by using the Sync button in the dopesheet, where the dopesheet shows the rows for the curves shown in the graph. This allows you to use the graph primarily while still using the dopesheet to help select keys in the graph, and makes it viable to hide the dopesheet toolbar.

I understand you prefer a dopesheet-centric workflow. We've discussed that, where the Sync button would let you choose graph>dopesheet (as we have now) or dopesheet>graph. This way the graph would show the rows for the selected keys in the dopesheet. Depending on what you are doing, this could be convenient by having the graph show the curves you care about without needing to use the visibility dots.

In this recent post, there is the idea of a graph auto frame mode that only frames the curves for the selected key and the curves before and after those. Coupled with the above, this might be a nice way to show only the relevant curves from the dopesheet selection, similar to the 3.8 graph.

Your presets are interesting, thanks. I'm very surprised you get by using those with few manual adjustments. Having curve presets as a separate view sounds OK. As you said, that allows you to not have the graph visible while using a dopesheet-centric workflow, but still be able to apply some basic curves (presets). I expect when you get an animation near completion that you'd use the graph to polish the curves.

Presets would be applied based on the differences between the keyed values and frames, similar to adjusting multiple handles at once. This means a preset can't be applied between two keys that key the exact same value, because their difference in value is zero. Also, when applying a preset, I expect it will change the handles on the other side of the keys. I think it would be surprising for it to separate the handles automatically. This is a pretty big difference from how 3.8 applies presets and I'm not sure how you'll like it.

BTW, are you applying curves as you create keys? Setting curves early on increases the cost of change. I'm sure you are used to your workflows, but FWIW it may be faster to block out the most important poses without thinking about curves, set in-between poses, adjust timing, then do a pass in the graph to set curves. Also, have you tried the favor workflow? It can be very efficient and gives great results.

5 दिन बाद में

Have you tried hiding the toolbar and/or rows in the graph?

Yeah, I have tried it but the efficiency issue remains. Can't see what rows refer to which bone params when I have a large number of bones selected without clicking and jiggling keys and don't have any preferred presets so it's just an enormous struggle to work with all around at every step.

Also, being able to slide the bar to see what name and parameter a curve represents would deal with some skeletons we get back from freelancers that don't rename bones. We have bone1, bone2, bone3, 4, 5...286,287,288 and we can't get them to do otherwise even though we know all the tricks to auto-parent and naming at the home studio. Having the bar as adjustable would be very beneficial.

I expect when you get an animation near completion that you'd use the graph to polish the curves.

Only in some cases. The finalizing stage really isn't overly particular for curves given that our characters are meant to be seen on a smartphone. Presets more than do the trick 99% of the time. I've linked a video ref of our game's battle animation.

BTW, are you applying curves as you create keys? Setting curves early on increases the cost of change. I'm sure you are used to your workflows, but FWIW it may be faster to block out the most important poses without thinking about set in-between poses, adjust timing, then do a pass in the graph to set curves.

Yeah, I block out when I can and apply curves after but my responsibilities are mostly doing revisions on pre-existing work now so that's not applicable with many tasks in the pipeline. Really, any pipeline that involves going from a rigger, to a freelancer, to a revisionist means that working from scratch is often out of everyone's hands. Presets are just leagues more efficient.

The game I'm working on in Spine 3.8 is out now if you're interested in animation reference, here's a link to the game.
https://youtu.be/8NgMgTcfMng?t=565

I've handled a majority of the in-battle character animations and bridged the technical issues with these characters that often have multiple character views in one skeleton. The number of bones and screen real estate that's needed for these.. while I can breeze through in 3.8, I would straight up refuse to animate in 4.0 and quit my job.

Meanwhile, for a different gig, I can animate in 3.8 but still have to export in 4 - so I started trying to get used to 4 and it's near unbearable for me. I animate in 3.8 on my computer then send to my laptop which has 4 to export.

Also, have you tried the favor workflow? It can be very efficient and gives great results.

I'm sure the favor tool would be handy in some situations but at this point it's like trying to fix a leak in the sink and ignoring that a flood has already taken out the house.

This is all my personal experience and I'm aiming to be objective so I hope my frustrations aren't too overbearing. I'm grateful for your consideration.

Edit: Another note, the Dopesheet appears to be busted for scaling https://i.gyazo.com/182800e515b32ba0b7d55a98051985c5.mp4
it either only takes the end key in the selection, or it leaves the key on the end and only takes up to, but not including, the end key.

stikkanimate लिखा

Yeah, I have tried it but the efficiency issue remains. Can't see what rows refer to which bone params when I have a large number of bones selected without clicking and jiggling keys

Aye, makes sense. Having dots in the dopesheet would help a little. Ultimately though the graph excels at only 1-3 or so curves. 4+ curves can often become information overload.

stikkanimate लिखा

Also, being able to slide the bar to see what name and parameter a curve represents would deal with some skeletons we get back from freelancers that don't rename bones. We have bone1, bone2, bone3, 4, 5...286,287,288 and we can't get them to do otherwise even though we know all the tricks to auto-parent and naming at the home studio. Having the bar as adjustable would be very beneficial.

Currently the row width auto sizes, so you can always see the names. Allowing the user to resize it wouldn't help to see the names, it would only help to hide the names by making the rows more narrow. That's not great though, since once the user resizes the rows, how do we return to automatic row width? I'd not want the width to be manual only, it shouldn't be the users job to jockey the rows width left and right.

The rows are OK when you have the space, like when you are using the graph primarily. I agree we need improvements when using the dopesheet primarily. We have some ideas half implemented already and can show them relatively soon!

stikkanimate लिखा

The game I'm working on in Spine 3.8 is out now if you're interested in animation reference, here's a link to the game.
https://youtu.be/8NgMgTcfMng?t=565

Thanks, it's interesting to see. I think we understand your use of presets now. Sorry for the interrogation, I just wanted to be sure how you were using them.

stikkanimate लिखा

I animate in 3.8 on my computer then send to my laptop which has 4 to export.

Note you can run 3.8 and 4.0 on the same computer. You can choose the version on the launcher screen, or set up shortcuts to run one or the other.

stikkanimate लिखा

Dopesheet appears to be busted for scaling

Yep, we recently came across this and fixed it for 4.0.53. To work around it until then, when making a box selection make sure your mouse down doesn't occur while over a key, else that key won't be included in the box selection.

I understand the graph row editing might be outside the scope of how the graph is designed so no worries. I agree about jockeying the row width needing to be automatic, at least as far as the curves are concerned.

All this wouldn't be an issue if the windows were undockable outside of the program window but with things as they are, every bit of screen space is as valuable as gold to me.

Thanks again Nate, I really appreciate your time and all your work. It's no exaggeration to say Spine has helped me get back on my feet back in 2020 with more opportunities than ever going into 2022. I'm excited to see what sort of dopesheet-specific changes might be on the way!

एक महीने बाद में

Please try the new Curves view in 4.1.10-beta, available soon!

Man, I just knew 2022 was going to be great. You hit an absolute homerun with this! I only checked the curve overshoots along with the Curves editor and both work as hoped. I didn't go too in depth though, have to switch back and keep working.

I'll be switching to full Spine 4 when this drops, an enormous thank you for this change!

Great to hear it helps! We still have a few other minor improvements to make. :beer: