Spine-Pixi-v7 4.2 .atlas file is not being loaded

1irakli

It seems that the .atlas file isn’t even being requested - there’s no network request in the dev tools for the atlas file, while the .json loads just fine.

The error happens because the atlas ends up being null when creating the Spine instance.

I initially suspected a webpack issue, but since the request for the .atlas file is never sent at all, it seems to be something else.

I've created minimal application that reproduces the issue. github URL.

This is error is given, upon running the example above:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'skeleton')
    at SkeletonJson.readSkeletonData (SkeletonJson.js:64:1)
    at Spine.from (Spine.js:759:1)
    at index.ts:23:28

Any ideas what could cause the .atlas file not to load?

Spinebot

Based on the context provided, I can see you're working with spine-pixi-v7, but the documentation examples I have are for spine-pixi-v8, which has a different asset loading approach.

In spine-pixi-v7, the asset loading works differently than v8. The issue you're experiencing - where the .atlas file is never requested - suggests that the atlas isn't being loaded before you try to create the Spine instance.

Here's what you need to check:

For spine-pixi-v7, you need to manually load the atlas file before creating a Spine instance. The atlas doesn't load automatically just by referencing it. You need to:

Load the atlas file as text (it's a text file, not a binary file)
Parse it to create a TextureAtlas
Then load the skeleton data using that atlas

Unfortunately, the context I have focuses on v8's asset loading system which uses PIXI.Assets.add() and PIXI.Assets.load(). The v7 loading approach is different.

Recommendations:

Check the spine-pixi-v7 examples in the spine-runtimes repository for the correct loading pattern for v7
Make sure you're loading the .atlas file explicitly (likely using PIXI's loader and treating it as a text file)
The .atlas file needs to be parsed into a TextureAtlas object before you can use it to load skeleton data

If you continue to have issues, consider upgrading to spine-pixi-v8 if possible, as it has a more streamlined asset loading system through PIXI.Assets.

Without access to spine-pixi-v7 specific documentation in the context provided, I cannot give you the exact code pattern for v7. You may want to look at the official spine-pixi-v7 examples in the spine-runtimes repository for the correct implementation.

1irakli

Spinebot
I’ve checked out the spine-pixi-v7 examples, and my minimal setup is almost identical to those - same loading pattern and asset structure.

The only difference is that in my case, the .atlas file isn’t even requested (nothing in the network tab). The .json loads fine, but atlas ends up null when passed to Spine.from().

Given how close the setup is to the official examples, it seems like something’s preventing the atlas parser or loader from being triggered at all.

Davide

1irakli

That means Pixi does not have the atlas loader installed by spine-pixi-v7.
You can check this by listing the parsers with Assets.loader.parsers.

When this happens with Webpack, it usually means that the bundle created by Webpack provides a different Pixi instance to the Spine plugin than the one used in your index file.
You should adjust your Webpack configuration to ensure that any reference to pixi.js points to a single, specific instance. Try adding something like this to your Webpack config:

resolve: {
    extensions: [".tsx", ".ts", ".js"],
    alias: {
        'pixi.js': path.resolve(dirname, 'node_modules/pixi.js')
    }
},

This issue likely occurs because, in Pixi v7, the packages were separated for plugin development, while an umbrella package named pixi.js was created to include all Pixi modules.
Our peerDependencies are:

"peerDependencies": {
  "@pixi/core": "^7.2.4",
  "@pixi/display": "^7.2.4",
  "@pixi/graphics": "^7.2.4",
  "@pixi/text": "^7.2.4",
  "@pixi/assets": "^7.2.4",
  "@pixi/mesh": "^7.2.4",
  "@pixi/events": "^7.2.4"
}

However, you are installing pixi.js, which bundles all these packages together. As mentioned, this probably confuses Webpack, causing it to return a different instance of Pixi to the addon when it is required.

1irakli

Davide
Thanks man!!
Spent 4-5 hours yesterday on it, never would have thought of it