Oh. Dang. I'm trying to merge two skeletons, and when I do the constraints go away. There's about 60 of them I need to remake. Thank you regardless. 
FCSW_Ben
- há 9 dias
- Entrou em 30 de Nov de 2016
The Spinebot would normally be correct, but that version doesn't exist for download at this time.
I see there's a completed feature I'd like to test, labeled as belonging to 4.2.59-beta. I can't seem to download this using the launcher. Is there a way I can get it? If it works, it could save me an entire day of work.
- Editado
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.
A lot of our work is based in traditional animation. So we're really thinking in key poses, and less key frames. We want to move from pose to pose with specific timing.
Above is an actual timing chart from this project, with two key poses mapped to breakdowns (which Spine would call a keyframe). Breakdown numbers on the left, equivalent timeline timing on the right. Below, I've drawn what that would look like in Spine's timeline.
This is exactly why I use the curve editor and avoid the graph. The graph is useful for how you describe how you animate. The curve editor is useful for how I animate.
Here's a simple pose-to-pose animation with three keys. I'll add two extreme ease-out curves for illustration purposes.
Now if I want to move the pose in the middle, Spine will attempt to create a beautiful perfect graph no matter the settings.
With separate:
Without separate:
However, what this does is change the entire intent of the movement. What was a simple ease-out from one spot to another is now a complex animation that rounds somehow between the first position and the second, instead of simply correcting the second position as I expect.
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:
Particularly, this tends to happen to keys and curves earlier in the timeline, so I might not even catch the problem until I'm several steps ahead of it.This is easily the biggest time sink for me when using Spine.
All fair points. You're right about the graph view, and it explains why you've done it this way, but as I said creating those cusps is exactly my intention in the first place. I actually avoid the graph view entirely because it doesn't show me what I need to complete my work. It's a difference of paradigms to compare Spine here to my 15 years of experience elsewhere, and perhaps I just need to get with the times, but if I only had the option to not have Spine try to smooth the animation across a graph I could work a LOT faster and curse a lot less.
Thank you for your time, regardless. I feel a little better at least knowing the underlying reason for this behavior. Please consider this thread a humble feature request from an aging animator.
The bot mentioned trying to avoid cusps. Previous threads mention that too. But the cusp is the intention here. I would say 90% of my workflow revolves around adding keys iteratively between existing keys, which is a very common workflow in Flash, Max, and Maya. I would love the ability to not have Spine intervene with what it thinks is smoother or better animation.
To show it also happening when not in separate mode, by adding a key between existing keys. I would have expected the editor to split the curve at the insertion point a la 3DS Max or Maya, not go wild with the separated values.I see several discussions on this going back a couple of years, but no one has given an explanation as to why this happens in the first place. When you move a bone in the editor, even with bezier handles set to manual, and regardless of "match" and "separate" settings, the curves I set prior get corrupted.
Before:
After:
My best guess is Spine is trying to preserve the intent of the animation when a bone is moved. However, my goal is to move the bone and keep the same animation curve intact.
Because this constantly stops my workflow to return my curves back to their intended values, and especially because this introduces jank into my animations when I don't catch it happening, I want to understand the underlying reason this happens in the first place so I can avoid it.
I don't know what causes this, but when renaming image regions you're presented with two opposing options, seemingly at random:
"Clear image path"
"Keep image path"
Could this be normalized to a single option? When I'm moving fast and renaming a bunch of things, having to make sure one is checked but the other unchecked has on a few occasions now required me to throw away several minutes of work after realizing I did something wrong.
You are, as always, fast and thorough with your customer support and amazing at what you do. Thank you for looking into this!
I should ask: 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.
Addendum. As I'm going through correcting these keys, I notice they don't support curves. They appear to be locked into linear interpolation, even though the setting is a boolean. Might be worth the Spine team's time to revisit these things.
Hi, I am said artist. First, THANK YOU for clarifying this. I might have never guessed a lack of an inherit key in a separate animation to the be the cause of our failure. Am I to understand these Inherit keys are global to the entire skeleton, and not just individual animations? It seems that behavior might be inconsistent with other key behaviors, which I rely upon to return to the setup pose when each animation is played. It may also have implications for the Animation Cleanup feature.
Either way, this has been plaguing us for months because it's not something we can test for in the Spine editor nor the Preview pane. Perhaps adding the ability to chain animations in the Preview pane would help us and other developers when these problems arise.
I'd like to explain my choice of workaround for posterity, as all of your suggestions would have worked as well. Adding rotation keys to compensate for inheritance is something I do sparingly, as it's not safe for future animation changes. The transform constraint adds complexity and additional setup time, which is also very useful for the reasons you describe, but requires tree traversal in a file that's already massively complex. Being able to key inheritance is fast, stays within my tree selection, and is animation-safe between revisions. And now I'm armed with the specific knowledge that these keys work differently from other keys.
Thanks again!
Is this related to our inability to launch older versions of the editor from the launcher? I re-installed your latest launcher just ten minutes ago.
Esoteric Software LLC (C) 2013-2022 | http://esotericsoftware.com Windows 10 Home amd64 10.0 NVIDIA Corporation, NVIDIA GeForce GTX 1060/PCIe/SSE2, 4.6.0 NVIDIA 551.86 Launching: Spine 3.8.99 Professional ERROR: Error running legacy Spine launcher: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at com.esotericsoftware.spine.editor.launcher.Launcher.main(_:664) Caused by: java.awt.AWTError: Assistive Technology not found: com.sun.java.accessibility.AccessBridge at java.desktop/java.awt.Toolkit.newAWTError(Unknown Source) at java.desktop/java.awt.Toolkit.fallbackToLoadClassForAT(Unknown Source) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source) at java.base/java.util.stream.ReferencePipeline$2$1.accept(Unknown Source) at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(Unknown Source) at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(Unknown Source) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source) at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source) at java.base/java.util.stream.ReferencePipeline.forEach(Unknown Source) at java.desktop/java.awt.Toolkit.loadAssistiveTechnologies(Unknown Source) at java.desktop/java.awt.Toolkit.getDefaultToolkit(Unknown Source) at s.idh.<clinit>(_:28) at com.esotericsoftware.spine.editor.launcher.Launcher._(_:699) ... 5 more Caused by: java.lang.ClassNotFoundException: com.sun.java.accessibility.AccessBridge at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source) at java.base/java.lang.ClassLoader.loadClass(Unknown Source) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Unknown Source) ... 19 more E r r o r 1 2 7 : T h e s p e c i f i e d p r o c e d u r e c o u l d n o t b e f o u n d . Exception in thread "main" Downloading: Spine 3.8.99 Professional ERROR: An error occurred starting 3.8.99: C:\Users\bwrit\Spine\updates\3.8.99 [error] Spine integrity check failed. Please reinstall Spine. at s.aiT._(_:774) at s.aiT._(_:486) at s.oVr.D(_:42) at s.oVr._(_:32) at s.NuQ._(_:65) at s.gxu._(_:98) at s.NIn._(_:47) at s.yuD._(_:211) at s.voL.S(_:619) at s.cOM8.run(_:267) <events> ERROR: An unexpected error has occurred. Please reinstall Spine. ERROR: http://esotericsoftware.com/spine-reinstallation```- Editado
The Spine License Recovery Tool appears to be non-functional. Two of us are attempting to upgrade to version 4 and we're not getting emails sent to us by the tool. The emails are confirmed to be the same ones listed on the splash screen upon launch. Spine: License Recovery
- Editado
What would it be like if you were supposed to find the mines?
That's what Finder's Sweepers takes about classic Minesweeper and turns it on its head. Become a treasure hunter and search the world for ancient artifacts in this inventive "Reverse Minesweeper" game for all ages! Follow the clues to dig up treasure. The numbers tell you how many treasures are nearby in a square. The colors tell you what kind.
Finder's Sweepers is proudly animated entirely in Spine and is some of our best work yet. Charming paintings and illustrations from animator Alex Linné come to life in the game thanks to Spine! Treasures pop, dirt explodes, and man-eating plants chew your bones. Butterflies flutter around the jungle, and dense snow drifts swirl in and out on the winds of a high mountain. The game is a visual treat and would not be possible without our use of Spine to keep work times speedy and the game performant.
Give the game a try today!
Apple App Store: https://apps.apple.com/us/app/finders-sweepers/id1586844563
Google Play: https://play.google.com/store/apps/details?id=com.exceptionullgames.finders.sweepersFor players outside of our initial Canadian launch, feel free to join the beta and let us know how we're doing!
iOS TestFlight: https://testflight.apple.com/join/0FrxkHLp
Google Play Beta: https://play.google.com/apps/testing/com.exceptionullgames.finders.sweepersThank you, and happy hunting!
