Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spine atlas with semver in url won't load textures correctly #493

Closed
heorhiy-kharvat opened this issue Mar 24, 2023 · 12 comments
Closed

Spine atlas with semver in url won't load textures correctly #493

heorhiy-kharvat opened this issue Mar 24, 2023 · 12 comments

Comments

@heorhiy-kharvat
Copy link

heorhiy-kharvat commented Mar 24, 2023

Hi,
my game spine assets are located on 'https://cdn.domain.com/game/1.2.3/resources/spine/'
.atlas files are loaded correctly, but all textures .png files are attempted to load from 'https://cdn.domain.com/game/resources/spine/
'

Since 'makeSpineTextureAtlasLoaderFunctionFromPixiLoaderObject' uses 'core.utils.path.join'
extname for 1.2.3 is true, and before normalisation path for texture looks like
['https', 'cdn.domain.com', '..', 'game', '1.2.3', '..' 'resources', 'spine'] and that results corrupted texture url.

Anyway to fix that without modifying 'join' util or writing my own atlas parser?

Environment:
Chrome: 111.0.5563.64
pixi.js: 7.2.1
@pixi-spine/loader-3.8: 4.0.3
@pixi-spine/runtime-3.8: 4.0.3

Potential solution:
we could use just normalize and perform join of array of parts
const url = core.utils.path.normalize([...atlasBasePath.split(core.utils.path.sep), pageName].join(core.utils.path.sep));

Thanks :)

@SisterWang
Copy link

I encountered the same problem. Do you have any solutions now?

@heorhiy-kharvat
Copy link
Author

I just have a temporary workaround, so it won't block our migration and testing on dev environment.
Patched https://github.com/pixijs/spine/blob/master/packages/loader-base/src/atlasLoader.ts#L100 locally to change it to potential solution line mentioned in issue description.

@JonnyCodes
Copy link

I've got the exact same issue.

Assets are being hosted at https://www.domain.com/static/gameName/assets
But when the textures are loaded from the atlas it is going to https://www.domain.com/gameName/static/gameName/assets.

Loader.mjs:77 -> utils.path.toAbsolute
Looks like assets fetched from the atlas don't start with a forward slash, so it is using the base url not the root url.

@JonnyCodes
Copy link

JonnyCodes commented Apr 24, 2023

Dug a little further, @heorhiy-kharvat is correct.
AtlasLoader:62 creates a new TextureAtlas.
When the texture atlas is loading an asset it eventually calls the return function in makeSpineTextureAtlasLoaderFunctionFromPixiLoaderObject which strips off the starting forward slash

const makeSpineTextureAtlasLoaderFunctionFromPixiLoaderObject = (loader, atlasBasePath, imageMetadata) => {
  return async (pageName, textureLoadedCallback) => {
    const url = utils.path.join(...atlasBasePath.split(utils.path.sep), pageName);
    const texture = await loader.load({ src: url, data: imageMetadata });
    textureLoadedCallback(texture.baseTexture);
  };
};

No idea why it get's split and then joined again, but that's whats causing the issue.

I'd probably add an isAbsolute check:

const makeSpineTextureAtlasLoaderFunctionFromPixiLoaderObject = (loader, atlasBasePath, imageMetadata) => {
  const isAbsolute = atlasBasePath.startsWith("/");
  return async (pageName, textureLoadedCallback) => {
    let url = utils.path.join(...atlasBasePath.split(utils.path.sep), pageName);
    if (isAbsolute) `/${url}`;
    const texture = await loader.load({ src: url, data: imageMetadata });
    textureLoadedCallback(texture.baseTexture);
  };
};

@florinnutiu
Copy link

We encountered same problem on Safari 14.1 and older, because url is missing a "/" after it passes through makeSpineTextureAtlasLoaderFunctionFromPixiLoaderObject from atlasLoader.
Waiting for a fix.

@klesun
Copy link

klesun commented May 25, 2023

@ivanpopelyshev could you take a look, please? The library appears to be non-functional at current version due to that forward slash bug. Can Jonny's fix be merged to master? #500

@miltoncandelero
Copy link
Contributor

It's an upsteam bug and #500 won't fix the issue.

I will see how I can work arround it

@miltoncandelero
Copy link
Contributor

Should be fixed in 4.0.4

@klesun
Copy link

klesun commented May 26, 2023

Hm, I updated to 4.0.4, but png url is still lacking the leading slash - script page directory is still prepended to the path.

Upd.: sorry, never mind, had some debug left, 4.0.4 fixed it, thank you very much!

image

@florinnutiu
Copy link

4.0.4 fixed our Safari issue.
Thank u so much!
image

@BALAGAASHOK
Copy link

miltoncandelero

I am using relative path for loading spine, sprite files.

const app = new PIXI.Application({ background: '#1099bb' });
document.body.appendChild(app.view);
// Add the assets to load
PIXI.Assets.add('spriteOne', '../assets/games/dist/spriteOne.jpg');
PIXI.Assets.add('spriteTwo', '../assets/games/dist/spriteTwo.jpg');
PIXI.Assets.add('spineboyPro', '../assets/games/dist/spineboy-pro.json');

// Load the assets and get a resolved promise once both are loaded
const texturesPromise = PIXI.Assets.load(['spriteOne', 'spriteTwo', 'spineboyPro']);
// When the promise resolves, we have the texture!
texturesPromise.then((textures) => {
console.log(textures);
const spriteOne = PIXI.Sprite.from(textures.spriteOne);
app.stage.addChild(spriteOne);
});

I am getting 404 for spine png,but json & atlas files are getting loaded.

image

It's working for sprite but not spine files.

image

I am same using spine version of 4.0.4 but facing the same issue, can please take look

Pixi.js version 7.3
Pixi Spine version : 4.0.4

For your reference I am attaching sample project. Please find the link below;
code repo

@JonnyCodes
Copy link

Finally got around to updating our version of pixi-spine and can confirm it's fixed in 4.0.4

Thanks for looking into it 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants