8) Thanks for the insights,

this will help me build in a failsafe for most occurences.

Yes you are right about Start(). I just like to do my recurring initializations of pooled objects in OnEnable. Most of the code in question is just Setting up a queue of Animations for the lifetime of the object. Is there something planned to expose the AnimationState (replacing "Initial Animation") to the editor?

Hey,

I am having a lot of trouble with at runtime instantiated Spine-Animation Prefabs running into a null reference with AnimationState on iOS. I have tried two solutions.

• Deferring all Animation-Calls to Start()
  This helped with most of the cases, but there are still situations where I can run into a null reference on device.

• Deferring all Animation calls via Coroutine
  I also tried to hack in a Coroutine, which checks the AnimationState reference per frame if it is still null, if not it starts the calls. However, I still can get a null Reference from the AnimationSate-Getter as well as sometimes having animations that never leave the coroutine (never get a non-null Animation State).

The funny thing is, the assets/prefabs seem to be ok, because some times they work, sometimes the become null at the same "place" in code as well as game-flow. We are using Skeletongraphics as well as SkeletonAnimations

Can you offer any help? When can AnimationState actually become/stay/be null? Would it be possible to have an "IsInitialized" Callback? I also noticed that the AnimationState is also null when entering OnEnable, which would be great improvement when using runtime instantiated Animations.

In Editor and on Android I do not have these kind of issues.

Pharan a écrit

Also see the new Spine preferences. :cake:

:sun: Thanks! These changes do actually help to save quite some time.

Thanks for all the pointers

I will look through those and check back with our code base and will leave you an edit here about the alpha-issue. Maybe it has something to do with the AnimationSates as well.

Masking in Unity is supposed to change/have changed in 5.4 or 5.5 (2D alpha-features etc.) also there are different Plugins that implement their own Shader. I tried with the Masking Shader from the UI Extensions GitRepo with no satisfying result. Maybe something in our project is broken. I will look through our shaders/settings and add a more detailed description in the edit as well.

Just pulled the Master Branch and saw the Sprite to None change. You are fast! Quick Question: Would you rather have me comment/post/provide at Github directly rather than this board?

I guess than this might actually be an incompatibility with Textmesh Pro? Seems rather strange, because I get Edtior errors. I might ask over there, maybe their scripts are Hijacking the meshrenderer for their Purposes at Editor Time and has nothing to do with the runtime itself.

Setting the Skins does work for me as well now. Editor has gotten so slow (because of the described endless logging of said errors) that I had a problem setting those.

You do not have any issues at all neither as RawSkeleton Data nor as instantiated animation? The Inspector can also show you all attachments on the Skeleton Data?

Spine Preferences:

• It would be really helpful to have in the Spine section under preferences the option to set a default import scale as well as Textureformat and alpha setting. With our workflow we have to (re)set those on every (re)import.

Last Frames:

• With animations fading out the alpha of graphics we have reports that if the last keyframe is alpha null the animation might stop semi-transparent alpha instead of a flat zero, to counter this we added a few empty frames at the end of most animations to make sure nothing gets lost.

• Also Custom Events seem not to get triggered on the very last frame as well, we don't want to use the Complete callback for workflow reasons and have to buffer here at least one frame as well to get the event.

SkeletonGraphics:

• Is there an update about (soft)masking these? I have seen that the SekeltonGraphic is deriving from MaskableGraphic, however in our test cases they are clipped as a whole. Is there something wrong with our setup, or how would it be possible to to have them dissected/clipped inside the animation graphics?

• Would it be possible to have the SkeletonUtility for SkeletonGraphics as well?

Atlastextures:

• When the texture gets imported, is it possible to pass the regions of the single sprites as well? So we could use the the sprites on the atlas directly in unity as well? Otherwise it would be nice, if the texture import would set the SpriteMode to None instead to avoid confusion inside projects.

Contacted you via PM, could send you a zip with the animations generating these errors.

Hi Pharan,

is it cool, if I send you a dummy animation causing this error: http://esotericsoftware.com/forum/Skins-files-with-multiple-skeletons-Guest-star-Unity-6733?p=31166#p31166

Kind Regards,
Benedikt :coffee:

That's even better! Thanks

I did a quick & Dirty setup last night:

• Because some fields in spine-sharp are marked as internal, the whole spine-sharp library would have to be copied over in to spine-unity and could not be used as separate reference. For some or all of these fields might be a public variant present I did not check (quick & dirty as I said)

• Removing the UNITY_EDITOR fields was painless. Having the OnDrawGizmo -functions not captured in UNITY_EDITOR should not make a difference to any build, since it would not be called anywhere outside the editor. There where a maximum of 2/3 situations where Application.IsEditor would be really necessary and should do the trick.

• I found some platform defines (mainly Windows phone/store related). I did not look into them further, but they might break Multi-Platform support through a single library. There would still be the possibility to have several unity-libraries and marked inside the editor for their distinct platforms, but this is kind of a bad workaround.

• Folder-Structure: I messed up your project structure badly in my branch (Again doing a quick test here). I am not sure how you would prefer a data structure that is maintainable especially regarding the spine-sharp library code. Also I would advise having several *.dll Maybe: spine-unity.dll, spine-unityeditor.dll, spine-unityUI.dll, spine-UnityUIEditor.dll, spine-UnityModules.dlll
  Unity handles its new UI system as "Extension" inside their code base, maybe having the reference here apart from the main library might give enough flexibility for future restructures on the engine part. Additional unitymodules just sound like a plus for the user (in terms of modularity), but I am not sure how much of a gain or workflow improvement this might be.

• Resources/Editor/Shader files would have be kept outside of the library and be packed into an UnityPackage again. Except the raw textdata is stored inside the library and would recreate/overwrite the files at there destination every time the user starts up the editor. This is a possible solution but sounds a bit like a crutch as well.

My compilation did not work inside the Editor. I did get Constructor errors from some Editor Script. I won't have time to investigate here further for now, but if you are interested I can push/you can pull my WIP branch.

*edit: Was this of any help?

Pharan a écrit

So I tried a skeleton with skins but with an empty default skin. Seems to work fine.

Did your test include having several skeletons with the same atlas asset and mixed skin setups on those skeletons?

I am using [SpineAnimation] and [SpineEvent] for making my facade classes more user friendly. In almost any case I use SkeletonGraphic and SkeletonAnimation indiscriminately, which turn out was more complicated than I thought with both classes not being properly interfaced.

When using these attributes in this way, the attributes drawers fail for SkeletonGraphics that are on a different component than the string field reference. For SkeletonAnimations this works, because the Attribute drawers try to get the SkeletonAnimation Component from the childobjects, if they can not find any. As a workaround I would add following lines to SpineAttributesDrawers.cs at Line 56 to have the same functional fallback for SkeletonGraphics:

if (component.GetComponentInChildren<SkeletonGraphic>() != null)
{
    var skeletonRenderer = component.GetComponentInChildren<SkeletonGraphic>();
    skeletonDataAsset = skeletonRenderer.skeletonDataAsset;
}

Hope this helps!

Error Log from the Skeleton Asset:

UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type layoutType)
UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options)
UnityEngine.GUILayout.BeginHorizontal (UnityEngine.GUILayoutOption[] options)
UnityEngine.GUILayout+HorizontalScope..ctor (UnityEngine.GUILayoutOption[] options)
Spine.Unity.Editor.SkeletonDataAssetInspector.DrawUnityTools ()
Spine.Unity.Editor.SkeletonDataAssetInspector.OnInspectorGUI ()
UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean rebuildOptimizedGUIBlock, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect)
UnityEditor.DockArea:OnGUI()

Scope was not disposed! You should use the 'using' keyword or manually call Dispose.
UnityEngine.Scope:Finalize()

Internal_GetGUIDepth can only be called from the main thread.
Constructors and field initializers will be executed from the loading thread when loading a scene.
Don't use this function in the constructor or field initializers, instead move initialization code to the Awake or Start function.
UnityEngine.Scope:Finalize()

Error Log from Instantiated Asset:

Retrieving array element that was out of bounds
UnityEditor.SerializedProperty:GetArrayElementAtIndex(Int32)
TMPro.EditorUtilities.TMP_MeshRendererEditor:OnInspectorGUI()
UnityEditor.DockArea:OnGUI()

´NullReferenceException: Object reference not set to an instance of an object
TMPro.EditorUtilities.TMP_MeshRendererEditor.OnInspectorGUI ()
UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean rebuildOptimizedGUIBlock, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect)
UnityEditor.DockArea:OnGUI()

Strangely the instance error references TextMeshPro, even though the object in question is not using any TMPro asset. All Errors are endlessly stacking up.

The graphics are on the atlas.png, the imported atlas asset has them correctly referenced and visible. Names seem to match with the Skeleton.jsons in question. But I am also not sure for what to look out for exactly.

I had the idea to edit the instance in debug-inspector mode and changed the "Initial Skin" by hand in there from default to a specific skin, and everything popped into place for some of the instanced objects at least. I just realized, might this have to do something with the fact, that the "default" skin is empty though the other skins are not?

No it doesn't log them, they just won't show up on the skeleton I attached an Inspector screenshot, that made me curious Hope this helps !

I am mid production so I won't have the time to branch immediately as well, but if I find the time before your do I will let you know.

[ExecuteInEditMode] Should be called and executed the same way as in an open script file. I have not used this attribute in actual production code, but if I remember correctly it worked fine last time I tried. Other exotic attributes like [RuntimeInitializeOnLoadMethod] are working as well, so it is a safe bet. If this is the only Editor/Runtime trespass the restructure should work rather swiftly.

Important is not to have any UnityEditor.dll references in the main *.dll since it will break any build.

You are right, versioning should be left to the user for obvious reasons. Having a build project is more than enough.

Thanks for letting me know! Sounds great

I had a quick look into it last week before posting. I guess the biggest issue would be the UNITY_EDITOR prepocessor directives, specifically if they are in the non-editor part of the library. as well as dissecting Editor code into a separate spine-unity-editor.dll. Application.IsEditor should help out here, no Idea if there are any performance repercussions for the current code.

For Unity Versioning having the same preprocessors as the engine (like UNITY_5) should help with compatibility, however I guess the library should also be linked against the unity version the user is using. Most of the time it is save to have it build against a different version (been doing this a lot), but sometimes it leads to a startup crash. I have some experience with this for our own code base which I groomed for the last few years, if you are interested in more pointers, let me know!

Was thinking to look more into the code myself, but I am not as versed int the details of your runtimes to dissect the code without breaking editor functionality.

I am just curious if it is possible to maintain a c#-project in the unity-spine git repo fo precompiling a managed-dll Version of the runtime? I would want to keep compile times in Unity low. Also Unity-Packages are a pain.

Thanks,
Benedikt