not moveing straight between two keys, no access to the keys

mariam1023

hi, i have an object which should move between two keys with a straight line. There are no keys between them and nothing which come bring to the situation, but the movement is lagging. Is it a bug? Any issues with that?

mariam1023

Luke

Hello, thank you for writing in. Would you mind posting some screenshots of Spine, where the screenshots show the 2 keys and the object you're trying to move?

stikkanimate

One of a couple things come to mind.

Either it's because the new graph system causing the curve to overshoot/undershoot the keys. Look in the graph editor and you should see the curve go beyond your keys.

It's a partial transform/path constraint that is active/blending with your animation

Erika

Hard to tell without seeing the project/a gif/video or at least screenshots of what is happening. I second what Luke wrote!

warmanw

One more similar issue from me...

sometimes when you copy and paste a frame a little forward in time, in-between those frames spine generates a curve even though values of those frames are the same and expected result would be no interpolation. remedy is to select first frame and set curve to linear.

Erika

warmanw schrieb
One more similar issue from me...

sometimes when you copy and paste a frame a little forward in time, in-between those frames spine generates a curve even though values of those frames are the same and expected result would be no interpolation. remedy is to select first frame and set curve to linear.

Do you have a project that can reproduce this so we can have a look at it?

warmanw

Erika schrieb
Do you have a project that can reproduce this so we can have a look at it?

I think it is a normal behavior, just confusing.. no?

since with the key it also copies curve. so even if the values from A to B are the same we get a curve in-between. if that is not normal I will try to reproduce and send it.

Erika

I'm not sure, as I don't get that behavior in my workflow, hence why I was asking for an example 😃

warmanw

Here you go https://drive.google.com/open?id=1GJ0nemn5OLty50rrhjmYdJPmW8RAyumq&authuser=warmanw%40gmail.com&usp=drive_fs
I think I sent this issue to ES contact

gunspike

I agree with this opinion. If you copy and paste a key with the curve property, it becomes a curved graph, not a straight line, even if the values are the same.

Erika

It looks however like the representation in the dopesheet is correct (no line) and in the graph the result is still what looks like a straight line, so I'd assume this behavior is correct. Or can you provide an example where the result is incorrect or highly undesirable?

warmanw

Erika schrieb
It looks however like the representation in the dopesheet is correct (no line) and in the graph the result is still what looks like a straight line, so I'd assume this behavior is correct. Or can you provide an example where the result is incorrect or highly undesirable?

I am pretty sure that is normal behaviour even for extreme cases it is just not desired 😃
https://drive.google.com/open?id=1GK7TGMbVx2byuCm1F-z7t4XVH6XDZDtN&authuser=warmanw%40gmail.com&usp=drive_fs

stikkanimate

Apologies for necro-post but I have to agree with just how annoying this is and how warmanw has (99%) nailed the issue. Copying a key and pasting on dopesheet should (in my opinion only) work the same as 3.8 where you don't have an S curve into the duplicate but a straight line.

My near daily frustrations from working with Spine 4 are turning into abject anxiety as every revision takes 2 times longer to fix than it should. An anxiety I haven't experienced even when first learning Spine and when using Spine 2 for modding. Simply having curves function the same as they would in 3.8 dopesheet with a custom 'presets' would eliminate all anxiety and keep the program entirely familiar and friendly.

Additionally, the button that's supposed to separate the handles, clearly active in this linked video, are still altering the handles behind it when using existing locked-in presets.
https://i.gyazo.com/9c4abee2e7dbc6df83658e29e93f124b.mp4

Is there any link to where we can see when this sort of UX issue has a timeline for being addressed? For me, it absolutely must be addressed or I need to begin searching for other jobs that aren't using Spine 4 for my own health.

gunspike

Yes. There is a bug where even if the curve is disconnected, it can be reconnected. It should be resolved promptly. If user presets are included in version 4, the working speed will increase as efficiently as in version 3.

Nate

warmanw schrieb
when you copy and paste a frame a little forward in time, in-between those frames spine generates a curve even though values of those frames are the same and expected result would be no interpolation. remedy is to select first frame and set curve to linear.

That is expected behavior. Spine copies the handles along with the key. There is no special case to change the copied handles to linear when the previous key has the same value. We could do that, but I'd first like to improve my confidence that it won't be even more annoying. In what situations would you not want this new linear behavior?

If keys A and B have the same value, you copy A, and you paste it between A and B, then you probably don't want linear

you already had keys with the same value using handles to get other values between them. If we do change copied keys to linear, we'd only do so when the next key (B) has a different value than the previous key (A).

If you copy/paste a key with the intent of moving it up/down, the linear change will have removed the handles, requiring you to click the previous key and change it to Bezier. There is no answer that solves every situation, but if one scenario occurs more often we can make that the default to be more efficient on average. I'm guessing you guys are using copy/paste (or ctrl+shift+drag) to create "hold" keys, which is probably quite common.

Are there other situations to consider?

Note the linear change makes a cusp (the value transition is not smooth, it has a corner). Also the linear change would be applied not just for copy/paste but ctrl+shift+drag to copy a key.

stikkanimate schrieb
the button that's supposed to separate the handles, clearly active in this linked video, are still altering the handles behind it when using existing locked-in presets.

The button shouldn't be active (blue) because not all of your selected keys are separated. We've fixed that in 4.1-beta. You can tell which are separated by the icon at the end of the handle.

stikkanimate schrieb
Is there any link to where we can see when this sort of UX issue has a timeline for being addressed?

Your complaints have been heard. We're working on solutions and a number of them will be in the next beta version, 4.1.10-beta.

gunspike schrieb
There is a bug where even if the curve is disconnected, it can be reconnected. It should be resolved promptly.

Nothing can be resolved unless we know how to reproduce the bug.

warmanw

Nate schrieb
Are there other situations to consider?

I will keep an eye on that workflow and let you know, but in general I like new curves. I agree it might be difficult sometimes but I definitely dont want to go back.

I Noticed that I start working with curves at the end. mostly would work with linear . this way I break stuff much less.

I would create one nice curve for main motion using hips bone after that just quick posing with linear.. and only at the end I would start using curves.

However my main concern would be editing curves in a batch. about that I will complain another day 😃 need more practice

Nate

I meant other situations to consider specifically for the linear change. Still happy to discuss other improvements we can make of course! We have some other improvements in the works I'm anxious to finish. It's taking a bit longer than anticipated, as things tend to do.

Spine tries to be smart when changing a key to Bezier, or pasting/dragging a key past other keys. We put a loooot of effort into that. Without the smarts what you get in those situations is almost never what you want. This linear change is similar. The team discussed it and we'll give it a try!

Applying curves too early will make changes more difficult, so your workflow sounds good. If linear isn't enough but you aren't ready to start adding curves, you can use an extra linear key or two for a rough approximation of a curve. Usually you need only 1 or 2 extra keys for that. For example, if you have keys A -> B you can add key A2 so you have A -> A2 -> B where the A2 pose is closer to the A pose than the B pose (the favor tool is a great way to add key A2!). This will result in the pose changing more slowly at first. Later when you start setting curves, you might replace some keys with curves. Again you'd only bother with the extra linear key if you need it when roughing out your animation.

Please try the new behavior in 4.1.10-beta (available soon!) when pasting or copying keys using ctrl+shift+drag.

warmanw

Nate schrieb
Please try the new behavior in 4.1.10-beta (available soon!) when pasting or copying keys using ctrl+shift+drag.

Will DO!

Nate

Also don't miss the new Curves view!

Nächste Seite »