So it looks like it is indeed a limitation with meshes.
With the basic example, I could fix it by forcing triangleRendering on the canvas renderer of the SpinePlugin :
spineboy.plugin.canvasRenderer.triangleRendering = true;

Hello !

I am testing the spine-phaser runtime and have a little question about the canvas renderer. I tried the basic example provided in the spine-phaser repository, and tried out of curiosity to switch the renderer type from WebGL to Canvas.

When doing so, the example was missing some attachments

With Phaser.CANVAS renderer:

With Phaser.WEBGL renderer:

Am I missing something ? I saw that the Canvas renderer has some limitations (no meshes, tinting or blending modes) but I'm not sure why the spineboy doesn't work here (aside from the unsupported meshes?)

Hello

I was wondering if Spine's import editor code can work properly when Unity's parallel importing is activated ?
https://docs.unity3d.com/Manual/ParallelImport.html

I have never used this setting, but I was wondering if it would be a good idea to enable it, for speeding up the editor.
Spine has some custom import code (to create SkeletonDataAssets, Materials, etc...) and it's maybe not recommended or tested with Unity's parallel importing ?

Hello !

I downloaded the latest Godot editor provided by the spine-godot runtime documentation, but the performance is very bad ^^"
The editor runs at something like 10-20 fps, is not responsive, and is kind of unusable.
This is the editor version : "Godot Engine v3.5.stable.custom_build [991bb6ac7]"

Is it a known issue ? I can provide more information if that can help.
(I'm evaluating whether I'd prefer using Godot or Unity for a prototype of Spine integration)

This is awesome, thank you very much ! :grinteeth:

Would it be possible to backport it to Spine 4.0 ?
I see in the changelog 4.0 hasn't been touched since April, so I would understand if it's not doable/not a prio :p

At 0:04, you are modifying the absolute path with the relative path of the images folder.
This is what our artists have been doing, and are still doing currently.

We have therefore two feedbacks :

1. We have developed a pipeline to automatize the Spine project creation from Photoshop files. It would be nice if the Spine project already contained the relative path from the very start of the project creation (from the .json import).

2. It would be nice if the Spine editor displayed the actual images path saved in the project.
   We can see that a relative path is displayed at 0:22 in this video : https://youtu.be/u9_4-auoHKU?t=22
   After moving the project elsewhere, we can see at 0:51 that an absolute path is eventually displayed : https://youtu.be/u9_4-auoHKU?t=51
   We are wondering if the absolute path was the only thing saved in the project file, but displayed as relative in the first case.

This is obviously "Quality of Life" feedbacks and there are workarounds around those issues : but the UX would be much smoother if you could investigate those

The problem has been occurring for as long as this thread has started, but with inconsistent repro rates (I'm working with @edesmet).
Now that we found a 100% repro rate (at least on our machines), I wanted to chime in and detail the issue ^^"

Some additional information :

• if the .json exported from Photoshop contains an absolute path for the images, and we create a project from the .json :

if we don't move the project, Spine editor displays the relative path

if we move the project, Spine editor displays the absolute path, and the images are "MISSING".

• if we edit the .json exported from Photoshop to replace the absolute path with a relative one, and we create a project from the .json :

everything works fine, and relative path is always displayed

We are wondering if the Spine project is somehow retaining the absolute path that was set from the jsx script in the json. But even in this case, we would expect Spine to be transparent and display this absolute path.

Is it normal that the output json from the Photoshop jsx is always containing an absolute path ?

As you'll be able to see in the following videos, with very simple operations from Windows explorer, the relative path are not kept in the Spine project when moving it to a new place.
Bug Spine 4.0.64 - Relative path is kept when copying Spine project : https://www.youtube.com/watch?v=u9_4-auoHKU&ab_channel=MidiphonyM
Bug Spine 4.0.64 - Images are missing when moving Spine project : https://www.youtube.com/watch?v=ODzDYT-I4Xo&ab_channel=MidiphonyM

If I am doing anything wrong, don't hesitate to tell me :wounded:

You'll find attached a .zip containing the original PSD file, the PhotoshopToSpine.jsx file, and the ouput Spine folder.

Hello !

It's very cool to see you are supporting Godot ! :grinteeth:

Out of curiosity, were there reasons to implement this as a module, instead of via GDNative ?

Thanks for the good work

@Nate : backing up @edesmet reply

It would be nice to get back the alert that was removed in 7.20, as it wasn't the cause of the issue.
(and the alert was informative :p)

Just to let you know that the script runs without issue when replacing the "hasBackgroundLayer" function by the one you provided in your last post

Just double-checked, I'm 100% sure I'm now using the 7.20 :grinteeth:

Back with more findings :

• Removing the call to "hasBackgroundLayer" prevents Photoshop from triggering this strange empty dialog error, hanging, then crashing
• I tried to replace the following line :

  first: hasBackgroundLayer() ? 0 : 1,

  ... with :

  first: 0,

On my PSD with no background layer, it triggered a verbose (but standard, not crash-inducing) error telling me the script was trying to do bad things with Photoshop. However, when I wrote the following line on the same PSD :

first: 1,

[/b]

... the script eventually worked ! :scared:

We haven't identified yet the differences between our workstations to understand what is actually happening (it works on some workstations but not on others, with or without the same Photoshop versions... it's a mystery.).

I'm sending you just in case the Test.psd I used to debug, but this is just a very very basic psd file :\

If we ever find what was causing the issue in the first place, we'll come back here with our new findings !

I've found this community thread about the issue(s) with finding if a PSD has a background layer or not, via JSX plugin :
https://webcache.googleusercontent.com/search?q=cache:on1mEG1EyhYJ:https://feedback-readonly.photoshop.com/conversations/photoshop/photoshop-how-to-check-if-document-has-background-layer-with-jsx-javascript-script/5f5f45f44b561a3d426aa1e9%3FcommentId%3D5f5f48b84b561a3d42353215+&cd=12&hl=fr&ct=clnk&gl=fr

Photoshop doesn't look friendly at all about plugins and the use of old JSX... you are heroes for maintaining this export script

Hello

I just tried the 7.20 version of the script, and it hasn't changed anything in the behaviour :\

To note :

• an "images" folder is successfully created
• there is no json output file created
• there is no "errors.txt" file created

The pending error seems to be triggered very soon in the script, even before the "Collecting layers" phase.

In the meantime, we might try to roll up our sleeves and debug the ExtendScript

After debugging, the "empty" error is triggered on the following line :

return executeActionGet(ref).getBoolean(sID("hasBackgroundLayer"));

After clicking "cancel" on the dialog, the code executes on the following line... :

... before I'm unable to debug anything and Photoshop hangs until it crashes :\

I have found the following post from someone who apparently had the same issue :
Photoshop to spine script error: p74631

I'll get back here after I tried the workarounds you proposed on the other post, Nate

Hello !

Since yesterday, for no apparent reasons, the PhotoshopToSpine.jsx script available on GitHub stopped working.
We tried numerous versions of Photoshop and the script, without any luck.
This is currently happening on (at least) two machines at our workplace.

On a very simple PSD, I get an empty error box from Photoshop when the script is initializing :

Afterwards, Photoshop hangs on and/or eventually crashes.

It sounds like a very nasty issue, and I'm very unsure where to start to look at :scared:

Is it a known issue ? Does anyone have a hint of where to look at ?

Thanks in advance for any help

The fix looks cool, thanks !

If we cannot switch to the 4.1 runtime for X reason before we have to release, I think we will just set the UpdateMode to something different than FullUpdate.
This should prevent the double mesh update during fade out.

Hello !

I have a performance issue when trying to fade out a SkeletonGraphic via code.
To do that, I am using the SkeletonGraphic.color property, inherited from UnityEngine.UI.Graphic.color, and modify its alpha.
My first question is : is it the correct way to do it ? (or should I use a CanvasGroup on top, or another method...)

When profiling, I was surprised by the long time processing Canvas.SendWillRenderCanvases, in particular, CanvasUpdate.PreRender.

After debugging, I eventually understood that :

1. Setting the color property marks the vertices of the Graphic component as dirty :

   public virtual Color color { get { return m_Color; } set { if (SetPropertyUtility.SetColor(ref m_Color, value)) SetVerticesDirty(); } } // from UnityEngine.UI.Graphic.cs

2. The dirty SkeletonGraphic will be rebuilt during the Canvas Update (cf. "SpineCanvasRebuild" screenshot)

3. When rebuilding, the SkeletonGraphic will (re)Update its mesh.

   // From SkeletonGraphic.cs
   public override void Rebuild (CanvasUpdate update) {
      base.Rebuild(update);
      if (canvasRenderer.cull) return;
      if (update == CanvasUpdate.PreRender) UpdateMesh(keepRendererCount: true);
      if (allowMultipleCanvasRenderers) canvasRenderer.Clear();
   }

For my use case, this is redundant : the mesh is already updated in SkeletonGraphic.LateUpdate(), I don't want to reupdate it in the same frame as it was already quite expensive ^^"

So I tried setting the color not via the color property, but directly in the skeleton using skeleton.A or skeleton.SetColor().

Unfortunately, SkeletonGraphic eventually uses this Graphic.color property I'm dreading :

public void UpdateMesh (bool keepRendererCount = false) {
   if (!this.IsValid) return;

   // !!!
   skeleton.SetColor(this.color); // !!! The culprit !!!
   // !!!

   var currentInstructions = this.currentInstructions;
   if (!this.allowMultipleCanvasRenderers) {
      UpdateMeshSingleCanvasRenderer();
   } else {
      UpdateMeshMultipleCanvasRenderers(currentInstructions, keepRendererCount);
   }

   if (OnMeshAndMaterialsUpdated != null)
      OnMeshAndMaterialsUpdated(this);
}

Do you have any recommendation ? How can I achieve my effect, possibly without modifying the Spine Unity runtime ?

Thanks in advance

One way I see to prevent this would be to temporarily limit the updateMode to "OnlyAnimationStatus", while I do my alpha fading.

But I'd be happy to hear other solutions

Up.

Something seems to be failing around here :
https://github.com/EsotericSoftware/spine-scripts/blob/master/photoshop/PhotoshopToSpine.jsx#L1084

It's cumbersome whenever we want to export images/jsons outside of the psd file relative hierarchy.

So, I tried what I could from the Spine but never succeeded to achieve the desired workflow, which is : exporting the json+atlases+texture in the same time, with atlas names matching the folder hierarchy.

Erika escribió

You can also just run texture packer several times to have the different atlas names as you prefer them if it helps?

This would work... But the attachment paths lose the actual path.

In the Spine project, the image path contains the full path (e.g. "event_H/arm_L").
When exporting from Spine editor (with atlas packed per "Image folder"), the attachment paths also contain the full path.

However, when running texture packer for each image folder (from Spine GUI or from CLI), the paths are stripped from the attachments (e.g. "arm_L" instead of "event_H/arm_L").

Hence a little surprise in Unity when the SkeletonDataAsset couldn't resolve the atlases.

I found a user who had the same issue :
http://fr.esotericsoftware.com/forum/Mix-and-match-outfits-Addressables-loading-issue-16427?p=71940#p71940

pathfinder escribió

Besides this, a little question about exports. Since we are using a folder structure each export png is named after the skeleton (avatar_avatar_1, avatar_avatar_2), for organization purposes, how could we map the names to the folders used for the pngs? I saw that with a post build script could be possible, but I could not find some examples to base on.

So I'm a little disappointed this apparently common use case isn't implemented out-of-the-box in Spine, from GUI or CLI (that would be a really nice feature ! )

I end up doing what is suggested here :

Harald escribió

So you could use a bash script to automatically setup directories and copy your images following the desired directory structure. E.g. for attachment names like "myskin/arm" you would below a top export directory "export" have a directory "myskin" where you place the attachment image "arm". Then you would run the texture packer via the command line interface on the "export" directory. Then you can continue with setup for the next atlas, export it via the CLI, and so on.

It works quite well (thanks Harald), but I have to say this is not the most intuitive and straightforward way to go ^^"