It would help if I followed instructions I did an in-place update instead of a full proper delete-and-reimport update. Sorry for the false alarm!

First of all, thanks for 4.2 and all its amazing features!

I just updated to 4.2-2024-08-08 and am getting the following compiler error:

Assets\Spine\Runtime\spine-csharp\SpringConstraint.cs(38,34): error CS0535: 'SpringConstraint' does not implement interface member 'IUpdatable.Update(Skeleton.Physics)'

I'm guessing / wondering if this is because we're beyond Unity 2023.1? We're on 2023.2.7f1.

If it is because of that, do you know when you'll be supporting newer Unity versions? If it's not and something else is going on, let me know!

For now I've just added this bit to that script to get things at least running again (not sure about any side effects yet):

public void Update(Physics physics) { }

Hello!

We're seeing a very strange new issue on the live version of our game. Only recently, several new Chinese players have reported soft locks when loading into certain levels. We dug around in our logs and found that one particular Spine skel is erroring out:

Error reading skeleton JSON file for SkeletonData asset: Grogthud_SkeletonData
Invalid JSON.
  at Spine.SkeletonJson.ReadSkeletonData (System.IO.TextReader reader) [0x0002f] in <6a185d91fb6246c5b7702c2c758bf6e4>:0 
  at Spine.Unity.SkeletonDataAsset.ReadSkeletonData (System.String text, Spine.AttachmentLoader attachmentLoader, System.Single scale) [0x00014] in <6a185d91fb6246c5b7702c2c758bf6e4>:0 
  at Spine.Unity.SkeletonDataAsset.GetSkeletonData (System.Boolean quiet) [0x000a5] in <6a185d91fb6246c5b7702c2c758bf6e4>:0 

We've never seen anything like this before (the game has been out for over a year, with fair numbers of Chinese players that whole time, as far as we know). AND it's only happening for Chinese players. There is no separate Chinese build - it's all the same SKU, so the only difference for those players would be what the game language is set to, and/or what their system language is set to. I've tried reproducing it by changing both on my end, but no luck.

Kind of a strange one! Basically just wondering if you've ever seen or heard of anything like this before? Thanks for any insight you can provide

Chris

Amazing! Thanks again as always, you guys are the best

Thanks for the reply!

Harald escribió

Are you using SkeletonAnimation or SkeletonMecanim? I remember your project, but not which component's you were using.

We're using SkeletonAnimation yea.

Harald escribió

So you could benefit from this feature if you have many off-screen skeletons active, and are not already disabling them in some way.

I saw that actually! Very exciting for future projects, but in fact we already do our own offscreen disabling in this one.

Harald escribió

Apart from these changes, IIRC SkeletonAnimation should not have seen dramatic changes in performance.

Ok good to know, sounds like it's probably not worth the hassle then. Appreciate the advice.

Harald escribió

I second Nate's advice to automate the export of your assets. If you have a script ready that exports a single asset, you should be able to adjust it to cover even 140 assets in relatively little time.

We don't, no. Not that I know of at least... the only person who's ever inside the Spine application is our animator, and he doesn't really write scripts / do much coding at all. It absolutely sounds like something we should do on future games though. Do you have any documentation or good sources for this?

Harald escribió

And once again I have to say that your game is so cute, those little critters are just so lovely!

Thank you!

Ah dang, that's a bummer! Let me ask you this then - the reason we want to update is to try to benefit from any performance / optimization improvements that have been done in the meantime. In your opinion, do you think there were significant enough changes in that area to warrant us doing a full re-export on every Spine skel (₁₄₀) in our already-released game (https://www.moonlightkids.co/the-wild-at-heart)? I know you can't make the decision for us, but if you were just to give some advice from that angle. We've been dealing with a lot of performance issues coming from Spine Updates as we port to Switch.

Hello!

I'm doing a Unity runtime update from spine-unity-3.8-2019-10-14 to spine-unity-3.8-2021-07-12, but when I finished, if I run the game or just click on a SkeletonData asset in the Project view, it's saying the skel has to be re-exported with a newer version of Spine, even though both runtimes say "This Spine-Unity runtime works with data exported from Spine Editor version: 3.8.xx".

Any ideas? Is this by chance a known issue? I realize I'm jumping a big time gap here, but since they're both supposed to be compatible with 3.8.xx I thought I'd be ok.

If it helps, here's the full error printout (note that this error is for asset "WaterRipple_SkeletonData", but the same error is happening on all of our skels):

Error reading skeleton JSON file for SkeletonData asset: WaterRipple_SkeletonData
Unsupported skeleton data, please export with a newer version of Spine.
at Spine.SkeletonJson.ReadSkeletonData (System.IO.TextReader reader) [0x000b2] in C:\Users\Chris\Documents_MoonlightKids\the-wild-at-heart\Assets\Spine\Runtime\spine-csharp\SkeletonJson.cs:103
at Spine.Unity.SkeletonDataAsset.ReadSkeletonData (System.String text, Spine.AttachmentLoader attachmentLoader, System.Single scale) [0x00017] in C:\Users\Chris\Documents_MoonlightKids\the-wild-at-heart\Assets\Spine\Runtime\spine-unity\Asset Types\SkeletonDataAsset.cs:258
at Spine.Unity.SkeletonDataAsset.GetSkeletonData (System.Boolean quiet) [0x000c4] in C:\Users\Chris\Documents_MoonlightKids\the-wild-at-heart\Assets\Spine\Runtime\spine-unity\Asset Types\SkeletonDataAsset.cs:173
UnityEngine.Debug:LogError(Object, Object)
Spine.Unity.SkeletonDataAsset:GetSkeletonData(Boolean) (at Assets/Spine/Runtime/spine-unity/Asset Types/SkeletonDataAsset.cs:176)
Spine.Unity.Editor.SkeletonDataAssetInspector:InitializeEditor() (at Assets/Spine/Editor/spine-unity/Editor/Asset Types/SkeletonDataAssetInspector.cs:147)
Spine.Unity.Editor.SkeletonDataAssetInspectornEnable() (at Assets/Spine/Editor/spine-unity/Editor/Asset Types/SkeletonDataAssetInspector.cs:84)

Hello Nate! This is Chris, also from the Moonlight Kids team! I can help answer some of your questions, to keep communication flowing:

The lower numbers are of course better. Was there a noticeable performance difference?

Unfortunately not really, no. Maybe a frame or two, but it was hard to tell. No major change in performance stood out though. As you said, our skeletons already weren't that unreasonable, so perhaps those stats just aren't the bottleneck.

x25 of these skeletons is still a lot of processing (_10k vertex transforms) but it's very dependent on the hardware.

Yea, and we're talking 60-70 of these skeletons (plus 2-10 more for Player Characters and any on screen enemies) when the game is at it's most stressed. On old Xbox One hardware to boot (not exclusively, but that's our most problematic hardware at the moment).

Did unchecking constant speed help?

Our animator has just recently made this change, so we'll be doing build tests asap! Will report back when we know.

Still curious how many paths you have. You can filter the tree to only show paths, select the first, then shift+click the last to select them all and it'll tell you how many paths are selected in the tree properties.

Our animator checked and he says there are 4.

Oh, also how many path constraints do you have? Each one does a fair amount of calculations (see the PathConstraint class).

Our animator says also 4. To quote him: "I always use them together I never do paths without a constraint. So 4 paths and 4 path constraints"

Hope that helps give more info and context! We'll report back on the Constant Speed test asap.

:bigeyed: just like that huh! Thanks!

Hello! Glad I found this thread Wanting to do the same thing - get depth info for our spine objects so that we can use depth of field effects. However, when I try toggling on "Write to Depth" on a Spine/Sprite/Unlit shader, I get the following weirdness:

https://www.dropbox.com/s/hq4putsjdionnih/depth%20write%20issue.gif?dl=0

Is it because all of the skeleton's sprites are in the same z-space, so they're just all clipping? Maybe that's not the case, just a hunch! Happy to provide more details, but figured I'd just start there. Thanks!

Ah yea, good point! With that in mind I think we're all set!

Awesome thank you so much! Implemented these changes and so far so good! Since it's rare I'm still gonna keep an eye out, but we have what we need now to track it if it happens to pop back up You guys are the best!

Sent!

Haha well thank you so much, very kind of you to say We'll be showing it at GDC if you'll be there and want to check it out!

Do you have a secure/private way for me to send you the project?

Major breakthrough! I was putting together that sample project for you guys and was doing some testing in it to make sure I could actually repro the issue. It took awhile... the issue is really rare (maybe 1 in 200-300 attachments). But once it did happen I decided to take a peek at the runtime materials on the skeletons, and I think I found the issue! It looks like the defective materials are using the "Standard" shader, instead of the "Spine/Skeleton" shader. I have no idea why it would be getting the wrong one yet, but definitely progress.

Here's a vid of me poking around at runtime (apologies again for my green play mode tint!). The vid capture doesn't see any popout / dropdown menus, so there are some dead moments in there where you can't see what I'm doing (e.g. 0:45-1:00 can pretty much be skipped), but you'll see around 1:30 I manually change the defective material from the "Standard" shader to the "Spine/Skeleton" shader, and all is well again.

https://www.dropbox.com/s/s6adhrz43nimq8h/issue%20is%20wrong%20shader.mp4?dl=0

While I continue to get this sample project built for you, any ideas off the top of your head why it would randomly assign the wrong shader? Or maybe any ways to force it?

Cool cool, just wanted to throw that random thought out while I had it, in case it triggered something you knew haha.

PS: You should perhaps refill the red and blue pixels in your Unity version .

Oh haha, I just have it set to change green when in play mode, so I don't do anything stupid like make a bunch of adjustments in the inspector, forgetting the game is running haha.

Ok cool, yea I figured... but it was easier to do a little write-up than pack up a sample project haha. I'll work on getting you something though, thanks for the attention so far!

A little more insight into those thoughts:

• BCoroutine.WaitAndPerform just kicks off a coroutine yea. Normally if that second param is >= 0, it'll do a WaitForSeconds, then do the action. If you pass in -1 like I'm doing though, it just does a yield return null (waits 1 frame), then does the action.
• _carryable.DisableRenderingForSpineAttachment(true); is just disabling the sprite on the in-game pickup object, since we're resource-loading a new sprite to attach to the skel, and we don't want the pickup's image showing on screen twice while the agent is holding it. They're separate sprites, and separate objects - I'm pretty comfortable saying that couldn't be interfering.

EDIT: Hmm just had a quick thought - would it be problematic if the skel was being disabled or enabled in the same frame that the sprite was getting attached? That would be possible in rare cases if the agent was changing face direction in the same frame that they were picking something up, since we use separate skels for their different face directions.

To add little more detail there, for face directions the agent isn't in we disable both the MeshRenderer and the SkeletonAnimation components.

An enabled face direction:

A disabled face direction:

(p.s. I don't know how to make my reply show as a new message! it just keeps showing as an edit to my last message... hopefully this notifies you as if it's a reply haha)

Oh thanks for the compliments! I'll pass that along to our artist

Good to know it's not import settings, I suspected as much but nice to get that affirmed. Yea let me give a little more stack context and see if that helps at all. If not we can then try sending a minimal project over!

The call stack basically goes like this:

• The agent's PickUp() is invoked (from a coroutine that's actively checking and updating the agent's state) when it comes in contact with a pickup. That function looks like this...

public override bool PickUp(BCarryable _carryable)
   {
      if (_carryable != null && _carryable.OnCarry(this)) {
         CurrentlyCarrying = _carryable;
         if (_carryable.HasRequiredHolders && !_carryable.IsHeavy) {
            AgentAnimator.SetAnimation("Idle", "", CurrentlyCarrying);
            _carryable.transform.SetParent(transform);
            updateCarryablePosAndFace(_carryable);
            //Wait one frame before attempting so the anim has a chance to set
            BCoroutine.WaitAndPerform(() => attemptAttachToSpineSkeleton(_carryable), -1);
            //Play some sounds
            if(agentPlayerComponent != null) {
               BFMODInterfacer.Instance.PlayPCPickupSpriteling();
            } else if(agentSpritelingComponent != null) {
               if(!_carryable.IsHeavy) {
                  BFMODInterfacer.Instance.PlaySpritelingPickupItem(transform.position, _carryable.WorldObject.ObjectType);
               }
            }
         }
         return true;
      }
      return false;
   }

...

• In it, the agent's animation is updated to Carry (if it has one) in AgentAnimator.SetAnimation. (I'll share the entire AgentAnimator class below.)
• Then some non-animation-related behavior happens.
• At the end of that function, attemptAttachToSpineSkelton() is queued up, but it waits 1 frame before getting invoked. We had to do this to make sure the spine animation had actually updated first before attempting the attaching.
• That looks like this...

void attemptAttachToSpineSkeleton(BCarryable _carryable)
   {
      //If the agent is a spriteling, attempt attaching the sprite to the skel
      if (GetComponent<BSpriteling>() && AgentAnimator.AttachCarryableToSkel(_carryable.Type)) {
         //If it succeeds in attaching, disable the renderers on the in-game object since the skel version is active
         _carryable.DisableRenderingForSpineAttachment(true);
      }
   }

...

• So it's in there that the actual AttachCarryableToSkel function is called. That kicks off a new stack in the BAgentAnimator class, which I've posted in it's entirely here: https://gist.github.com/csumsky3/9916618e5095b2b6bf176c3aefa2d97d
• Basically AttachCarryableToSkel retrieves the right sprites based on the pickup, then, only if the sprite isn't null, kicks off attachSpriteToSkeleton, which is the original function I posted to you.
• One pretty important note about our animation setup: each agent has 3 separate skel files: Front, Back, and Side (which gets duplicated, flipped, and then assigned to the left and right vars respectively in BAgentAnimator). We enable/disable them appropriately as agents move and rotate around.

Hopefully that's a decent amount of information for now! If that still doesn't get us anywhere, I'll send you a simple project to check out Thanks for the help!

Other random notes:

• All of these animations were originally made in spine 3.6 and imported via the spine-unity runtime 3.6. The problem was originally happening there (rarely).
• We recently updated the runtime to 3.7 (in preparation for some new things), but didn't update the animations. The problem was still seen, as rarely and inconsistently as before. Didn't seem to change anything.
• Just today we also updated the animations to be exported out of spine 3.7, and also changed the pipeline to use atlases created from spine, instead of tk2d (because tk2d is pretty badly broken as of unity 2018.3.... but that's another story lol). I haven't seen the issue yet, but as I've been saying it's pretty rare so that doesn't say much yet. I'll keep trying.