FCSW_Ben

  • 17 juin
  • Inscrit 30 nov. 2016
  • Dans 4.3-Beta Exported JSON Won't Import in Unity

    • Harald

    • Message #13
    • Ce post est en anglais

    @ExNull-Tyelor @FCSW_Ben FYI, the spine-unity runtime on the 4.3-beta branch has been updated to load 4.3 skeletons from the most recent Spine Editor now. The previous spine-unity 4.3-beta state reading skeletons of version 4.2 was just mirroring the state of the 4.2 branch, without any 4.3-beta changes included yet.

    The first 4.3-beta spine-unity packages are available for download here as usual:
    https://esotericsoftware.com/spine-unity-download
    Please note that as always, any beta (especially when early in development) is not recommended for production use.

    We are currently investigating an issue with negative skeleton scale and Transform Constraint changing behaviour compared to 4.2, so you might want to wait a bit before upgrading your existing projects.

    • Dans 4.3-Beta Exported JSON Won't Import in Unity

      • Nate

      • Message #12
      • Ce post est en anglais

      I don't know what that is exactly, but it's cool! 😎

      I'm glad you aren't blocked anymore at least. I guess you don't have transform constraints, else it would have been a bit tricky to convert with a text editor.

      4.3.13-beta is up now! It converts path slot->target, transform constraint source->target, and the new transform constraint properties to the old offsets, as much as is possible.

    • Dans Understanding WHY curves change automatically when I don't want them to

      • Nate

      • Message #16
      • Ce post est en anglais

      The 4.3 beta is up now! Changelog I'm interested to hear how it works for your use cases.

    • Dans Understanding WHY curves change automatically when I don't want them to

      • Nate

      • Message #13
      • Modifié
      • Ce post est en anglais

      To be clear, we want to support many workflows. Sinisa isn't saying you must use the workflow he prefers, only that as a fellow traditionally trained animator, it's what he feels works best for many reasons. I think what he's getting at is to avoid the situation you are encountering so often by taking a different approach.

      Get as far as possible without using curves, then do curves at the end to polish. The favor tool is great for adding breakdowns. You can get very far without needing curves, greatly reducing the amount of fiddling with handles. Also when you have overshoot from a curve, drop a key at the peak to better control your extremes.

      That said, we are exploring how Spine can better adjust handles when keys are moved up/down to reduce the amount of fix up needed. You can see Maya does the same as Spine when a key is moved up/down: you get a squashed curve that isn't anything like what you had. We can do better!

      Separately from better handle positions, note that using an automatic Bezier gives you a good result when moving keys up/down. We'll consider making it easier to drop automatic keys, as currently you have to click automatic a lot. Automatic of course doesn't help you if you want a key with separated handles.

    • Dans Understanding WHY curves change automatically when I don't want them to

      • Nate

      • Message #11
      • Modifié
      • Ce post est en anglais

      You say you don't want Spine doing things to keep the curve looking nice, but the reality is Spine has to do lots of things to make any scheme work. It's a matter of deciding what the behavior should be. I appreciate you showing how you work and where you run into pain and I think we can make improvements here.

      FCSW_Ben That's all good, and I totally understand your intention. I'd like to walk you through the problem from my perspective, though, because we are talking about two different things.

      I think the screenshots in my last post show that what you seem to want (3rd screenshot) is better than what we currently do (2nd screenshot).

      Your graph is difficult to read because it's not very tall, it's very wide, and it's zoomed out. Frame would likely provide a better view.

      I recreated roughly what you showed:
      http://n4te.com/x/1460-curve-test.zip
      To reproduce: on frame 15 move the hip bone down.
      Expected: the same curves, fast-then-slow.
      Actual: wonky overshoot and curves that are nothing like fast-then-slow.

      Making the keys not separated (which gives very different curves) does not change the issue. The curves (especially the second curve) are still not similar to fast-then-slow after moving the hip bone down.

      I think what I described in my last post would solve this: when a key is moved up or down, the handles of the moved key should be adjusted so they don't move in the curves view. Also, the "after" handle of the key before the moved key and the "before" handle on the key after the moved key need to be adjusted. We'll dig into this more and let you know how it goes.

      Worst of all, if I'm not careful about the separate settings being as consistent as possible throughout the project, the process of correcting and re-correcting the curves will inevitably lead to a blow-out like this:

      I don't understand this part. Can you clarify what you mean?

      • Dans Improper Transitions Between Animation Tracks
      • Dans Improper Transitions Between Animation Tracks

        The rotation is changed to keep the bone's same world rotation for convenience. I think that's commonly what people want. If we didn't change the rotation, it's somewhat tedious to do the math to do it manually.

        The rotation change causes a key to be set if auto key is on.

        FCSW_Ben If our animation mix is set to zero in the runtime, but we're still seeing what I describe as "global inherit" behavior, does it imply a bug in the runtime? If the Inherit keys only affect the animation being played, I would expect swapping between animations to reset the inherit values to the setup pose.

        The question as it's asked is hard to answer. "Global inherit" isn't defined and isn't standard terminology. Mix duration (zero or non-zero) doesn't affect keyed properties being stuck after an animation is mixed out.

        If you apply an animation and mix it out to another animation (which may be an empty animation) then the keyed properties should be returned to the setup pose values after the mix. If they don't, yes, it's a bug.

        Note if you use clearTrack or clearTracks or trackEnd then the skeleton will get left with whatever property values it had at that time. Mix to another animation (even if mix duration is 0) to get the setup values.

        I setup a runtime test with your skeleton. If I play block and then block_to_idle, I see the inherit mode from block persists. This is a bug and we've fixed in in spine-libgdx just now. It will be ported to the other runtimes soon!