Harald Thank you for the answer and clarification (and welcome back)!! I will take a closer look at these two potential solutions in the coming weeks
JulianRice

- 7 févr.
- Inscrit 7 janv. 2022
Misaki Thanks for letting us know! We'll see if we can figure something out in the meantime.
Is this the accepted answer? Just want to make sure unless a developer has advice or thoughts.
Thanks,
JulianHi, we've been working with SPINE for the last 5 years now and it's been wonderful. Our game, Shujinkou, is finally releasing next month and we're gearing up to fix a bunch of remaining bugs and apply polish as the release date inches closer.
With lots of small issues across different platforms coming up, we've found the need to swap platforms (PS4 to PS5, PC to PS4, PC to NX, etc), and every time we switch platform, the 1,000+ SPINE projects we have in the game (not .spine, but the resulting .png/.json/.asset etc files) seemingly get reimported. This has been present ever since we became able to swap platforms in order to port the game (over 2 years ago), and it wasn't a big deal back then (we could wait), but with urgent bugs and the need to quickly implement fixes and test at a fast pace, we're being slowed down by the reimports taking up 20-30 minutes each time we switch platform.
Is there a reason for this happening and is there a way to stop it from reimporting every time a platform is switched? No files / project files actually get modified in terms of Git differences FYI.
Version: SPINE 4.1
Unity: 2021.3.41f1Warm regards,
JulianHarald
Hi, I have had my eyes on this post for a while now, but noticed someone else posted about this error log here (https://esotericsoftware.com/forum/d/25724-fatal-exception-indexoutofrangeexception), so I'm following up here to say that I've been encountering a similar issue too.I am not quite sure where the bug is coming from, but I can give some details:
- It only happens in builds (not in Editor)
- On our end, it only happens when we first load up our environment (a town). Every town has a bunch of NPCs (30+) using SkeletonAnimation, and a couple of menus that each have one or more character SPINEs (SkeletonGraphic), but the error only pops up for four NPCs when loading up one specific town (initializing all SPINEs). I can't figure out which ones are throwing the error (at least based from the log).
- The game doesn't crash or break as a result, and from what I've seen, the NPCs look fine.
- However, these four errors pop up every time during play and messes with our error tracking.
Some thoughts from me:
- Could this be as easy as going through all of the NPCs in the town, resetting the SPINE (whatever default assets/materials are set already), building, and testing it again?
- Based on the stack trace, the LateUpdate() from Unity's ScrollRect is triggering this error, but only four times... so there has to be some kind of mismatch or issue with timing.
- Again, it's only in one town, and because this is a SkeletonGraphic issue, I assume that there's a menu in the town that is causing an issue when first initiated... I'll keep taking a look and will keep you updated, but please let me know if there's anything else I can do to find out the issue for this (and why it seemingly only happens in builds!)
Here's the full stack trace
Uploading Crash Report IndexOutOfRangeException: Index was outside the bounds of the array. at Spine.Unity.MeshGenerator.BuildMeshWithArrays (Spine.Unity.SkeletonRendererInstruction instruction, System.Boolean updateTriangles) [0x00bb8] in <6dd7f65da0cb495b8b298cec8c065fc6>:0 at Spine.Unity.SkeletonGraphic.UpdateMeshSingleCanvasRenderer (Spine.Unity.SkeletonRendererInstruction currentInstructions) [0x0006a] in <6dd7f65da0cb495b8b298cec8c065fc6>:0 at Spine.Unity.SkeletonGraphic.UpdateMeshToInstructions () [0x00040] in <6dd7f65da0cb495b8b298cec8c065fc6>:0 at Spine.Unity.SkeletonGraphic.Rebuild (UnityEngine.UI.CanvasUpdate update) [0x00035] in <6dd7f65da0cb495b8b298cec8c065fc6>:0 at UnityEngine.UI.CanvasUpdateRegistry.PerformUpdate () [0x0015b] in <8feb70aa6437467687fee8eb58d4b3e7>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) Sentry.Unity.Integrations.UnityLogHandlerIntegration:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception, Object) UnityEngine.UI.CanvasUpdateRegistry:PerformUpdate() UnityEngine.Canvas:SendWillRenderCanvases() UnityEngine.Canvas:ForceUpdateCanvases() UnityEngine.UI.ScrollRect:EnsureLayoutHasRebuilt() UnityEngine.UI.ScrollRect:LateUpdate()
Regards,
JulianHarald
Sorry for the delayed response and thank you for pointing this out to me.I was able to select the settings you pointed out and got it to work pretty smoothly! While the colors weren't as purely red (for example, for the blush) compared to the SPINE editor / original PSD, I feel that it's close enough that it will work just fine. We've opted for Linear color space to work with 2D URP in our environments, hence the inability to easily swap to Gamma color space.
Regards,
JulianHarald
Thanks for the quick response! I missed that line in the documentation, so thanks for pointing that out.Wow, I looked into disabling
Advanced - PMA Vertex Colors
in the SkeletonGraphic component and it looked like it worked. Thanks!While I'm here, I just wanted to bring up one more strange color discrepancy I noticed when comparing the standard SkeletonGraphic displayed in Unity compared to how it's shown in the Spine App.
What confuses me is that what I see in the Spine editor differs from what's being shown in the game/build. I know there are a lot of variables that go into affecting how things are displayed, but the rest of the colors (other than the semi-transparent red blush) are rendered fine, which has me stumbled!
Should I make a new thread for this?
Regards,
JulianHello again!
As we continue to develop our game, we've noticed cases where some of the SkeletonGraphics that we use for our dialogue system (strictly UI/Canvas based) lose saturation for certain colors/layers—specifically, blushing.As a developer (not an animator), I assumed it was just an issue with perhaps some settings regarding the animation itself, but (owning a pro license) checking the
.spine
project and liaising with our animators resulted in no easy or known solution from what we could tell (correct us if we're wrong please!).But, I took a look at the settings within Unity for the Spine/SkeletonGraphic shader settings and noticed that some of our portraits had the
CanvasGroup Compatible
setting checked, while others didn't. Running a quick test of this in-game (during testing) showed that this setting affects how saturated things like the blush are (as seen in the screenshots below). Is this an unknown bug, a new bug, or actually part of the intended functionality? We're currently using SPINE 4.1.Thank you in advance!
Julian.PS: For the time being, we'll be unchecking this setting as it would look weird to have so many blushing characters in our game with bruise-like marks
Harald
Hi Harald! Sorry for the delayed response, but I just wanted to let you know that after a lot of investigation and conversation with the people at Unity, this is not a SPINE bug but rather a bug with the URP Lighting system!Thank you for taking the time to look at this issue! It helped guide us towards the right path.
Right now, this is a known bug in Unity LTS 2021 and will be fixed hopefully in the coming weeks. For you (or others who may reach this point), the main forum post can be found here:
Unity Forum Link (Bug Case: IN-38390)Hi! After updating to
SPINE 4.x+
, I've noticed a new issue appear revolving around Mesh data and how it's seemingly (?) saved into prefabs that contain instances ofSkeletonAnimation
.Our game has a complex prefab system for managing towns and other environments—each town has a number of NPCs, each NPC being its own prefab variant (of a baseline NPC) that has most of its settings saved to the prefab variant (exceptions being position in the town, etc., which are saved in the town prefab).
When saving an existing Town prefab, the file size of the prefab jumps 30-50x, from general sizes (
SPINE 3.8
) of around 1-5 mb to 50-90 mb now. I wasn't sure what the problem was and didn't know why 1,500,000 lines were being added to the.prefab
file when checking the diff for prefabs on GitHub, but a few things tipped me to the idea that it may likely have to do with SPINE.I'm finding that the
Mesh
data's triangle, position, color, indices etc data are all being saved into the parent prefab (town), and this seems to be the cause of the prefab file size bloat. Within the Town prefab, I'm seeing millions of lines (relating to the NPC prefab based on theguid
) like these:- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1388] value: 463 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1389] value: 462 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1390] value: 460 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1391] value: 461 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1392] value: 459 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1393] value: 461 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1394] value: 460 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1395] value: 458 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1396] value: 459 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1397] value: 460 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1398] value: 442 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1399] value: 459 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1400] value: 458 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1401] value: 444 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1402] value: 442 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1403] value: 458 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1404] value: 443 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1405] value: 454 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1406] value: 457 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1407] value: 455 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1408] value: 457 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1409] value: 454 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1410] value: 456 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3} propertyPath: m_Triangles.Array.data[1411] value: 455 objectReference: {fileID: 0} - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21, type: 3}
A look at the NPC prefab in question shows a new dropdown that I haven't seen before-I assume it's a new
SPINE 4.x
addition or a new addition toUnity 2021 LTS
(was working via 2020 before).
A look at an example Town prefab that has jumped in size due to millions of new lines of seemingly redundant (?) data also is reflected with this strange dropdown. Each mesh applies a couple hundred thousands of lines of yaml data to the.prefab
file.
A look at the inspector when clicking one of the mesh data items in the dropdown shows this:
Is there a setting or option that I'm missing somewhere within theSPINE 4.x
setup? I've looked through the documentation and forum for potentially similar issues but have yet to find something similar to this one. I'm not sure if the +50-90mb bloat affects the gameplay performance that much (I haven't noticed major drops in play), but I can only assume that so many redundant lines being added to existing prefabs (only on save, by the way!) is probably not the intended behavior? If this is not a SPINE issue, please let me know! ??
Ah! I would also like to note that one of our larger towns went from a prefab size of 20 mb to 232 mb after trying to save the prefab with the existing SPINE that were present in the town. It also takes 1-2 minutes to save the prefab now, compared to the 5-10s that it took before. Any advice or things to try out would be greatly appreciated! ??
- Modifié
Hi Harald,
I just wanted to provide a status update on this issue—the TLDR is that we've resolved the problems!We updated Unity to LTS 3.2021 and realized that it involved a mandatory upgrade from SPINE 3.8 to 4+, so we bumped it to 4.1.
From there, all 1000+ SPINE projects had to be re-exported, but it was automated via a shell script that I wrote (after the version updates) that synced up and auto-exported all of our projects from a SPINE GitHub repository to a repository with our game's assets.
Thanks for the advice and help, and I hope that others who may have this issue note that it's been resolved ?
- Harald a écrit
Most likely you need to enable or disable Straight Alpha Texture at your Material to fit your export settings.
Thanks for the reply Harald!! I've read through both links of documentation.
We're currently using SPINE 3.8, so I believe theAtlas Texture Settings
option on Unity isn't present (?). Is there a way to assign from somewhere other than the SPINE section of the preferences?Looking at the rest of the details... particularly the
Correct Texture Packer export and Texture and Material import settings
forStraight Alpha
:
Even after checking sRGB, Alpha is Transparency, and Straight Alpha Texture, the lines still appear. I assume this is because it doesn't match the texture packing settings in SPINE (no premultiplied alpha, yes Bleed). We've experimented with re-exporting some portraits with the correct settings marked in SPINE, and the portraits work just fine after that. So the question is, would re-exporting (even if it takes a lot of time) every project from SPINE and re-importing into Unity with those settings applied be the best solution for this case?Drako a écritI have a suspicion that there is probably something like this somewhere in Unity. Somewhere around loading textures from png-files.
I've looked around everywhere on the Unity-end and did find some texture importing settings within the code, but nothing clear that sounds like a "premultiply alpha" setting or something along those lines.
Thanks both of you ?
- Drako a écrit
I'll write right away that I have no experience with Unity. I am only expressing my assumptions, so you should not expect much from me.
Regardless of your experience with Unity, your experience with SPINE itself is helping me a lot, so I appreciate the time you're taking to respond!
Drako a écritIn Spine Web Player we have "premultipliedAlpha" parameter with "true" default value
Generally when importing SPINE files into the project, we work with a JSON, PNG, and Atlas file. I assume the JSON stores information on the actual movement/animation, whereas the PNG is where the assets/layers are and the Atlas is a summary of sorts(?) of the png and its layers (or bones).
I've already sifted through all three files looking for some kind of "alpha" or "multiply" (those kinds of keywords) but haven't found anything. So that made me think that it's labeled as something else... or somehow integrated into the png data itself.
Drako a écritBut for Unity, are there separate runtimes for each separate version of Spine?
Nah, I mean there's a unitypackage that SPINE releases for us to integrate into our Unity project, but I don't believe those are "separate runtimes"... if I'm answering that question right~
Drako a écritBtw, I see this yours "bits" in picture in first post too.
Yeah I just noticed that it was in the original picture too ?, thanks for pointing that out! I already talked to our artist and have that fix on the way. The issue with the outlines is still prominent among the other SPINE projects that have yet to be re-exported though. Hoping to find some kind of solution in the coming week >_<~
Thanks for the tip Drako!
Drako a écritI forget to check "Unpremultiply alpha" when unpacking textures
Do you mean not selecting Premultiply Alpha in the settings? We tried exporting one of the SPINE with that option deselected and played around with the materials in Unity (with URP) and managed to get most of the extraneous outlines to disappear. However, some of the pieces (layers I assume) seemed a bit blockier, and there were some bits of white/transparency that appeared for the first time as a result. Do you have any idea what this could be?
Also (aimed more towards the SPINE developers), in the case that this is the best solution one can reach in the given circumstances/software versions, is there an alternative to re-exporting every single SPINE project with this single checkmark toggled off? We have 600+ SPINE projects for the project we're working on, and if there's something in the code (I have yet to see anything obvious in the .json/.atlas/.meta files) that we can prepare a program to crawl through and auto-update/edit for us, that would be a big time-saver for the artists on our team.
Thank you!
Hi! I've encountered a visual issue with SkeletonGraphics after switching the project we're working on to URP.
In the past, this issue was resolved by applying the material belonging to the SkeletonDataAsset into the inspector (for SkeletonGraphic). However, now that URP is active... regardless of if theSkeletonGraphicDefault
material or the SPINE's actual material is selected, (in this case, it'd beShu_Material
) the lines that are seen around the mouth area and other parts (collar) won't smoothly disappear. I believe that the lines are different "layers" that our artist prepared before animating the file, but these things should go away (they have in the past) when working in Unity (both Game and Scene views). I have already imported the URP SPINE extra shaders/etc., but I noticed that they are not to be used with SkeletonGraphics.If you have any pointers, advice, or ideas, that would be awesome! Or if you need more information, I can post more screenshots and details. Thanks in advance!
Edit: We're using Unity 2019.4.28f1!
- Modifié