Texture cache collision (assets incorrectly shared)

[ryanmcnz]

When having multiple Spine objects in the Pixi stage that each contain separate assets, they have texture cache conflicts with said assets that share the same names in their skin/JSON hash file.
My suggested fix for this is implementing the use of IDs in the texture cache, eg. perhaps using a UUID rather than just using the image name.

Here is a simple example I made using the AssetLoader, to show this issue:
http://www.mediafire.com/download/eq81sgt15ls5lnj/asset_spine_test.zip

This contains two cannons made in Spine that are purposely in separate files.
These have the same bone names and image names in their skin...but use different texture files, JavaScript objects, etc.

Technically their assets shouldn't clash in the cache.
An example of where this could be an issue is if I had a dog and a human, but they both contained an image reference in their skin called "head", this issue would then occur.

To load these in, I've created two sets of objects with different names in JavaScript, to show that it isn't a conflict with something such as only having one AssetLoader or recycling other objects.

When loading this example, it has a random occurrence of either showing the two cannons correctly with their different textures, or randomly showing two cannons that look the same (aka duplicating assets between them for no reason).

My solution to this issue was to give all my spine skins heavily unique image names such as:
"cannon1_img_head", instead of "head".

[ryanmcnz]

After further investigation, this may not be a problem with the bone names...but instead the image names in Spine skins and JSON hash files.
I've successfully fixed this with two Spine characters that have the same bone names, but unique image names in each of those characters skins.

[englercj]

If you are using our loaders it is possible there is a name collision the texture cache

[ryanmcnz]

Cheers for mentioning that englercj, yes I am currently using the regular AssetLoader.
I can confirm that the texture cache collision is the issue occurring here.

If you'd like to see all of the tests I've done so far, including my fixed cannons and their resources, you can download them all here:
http://www.mediafire.com/download/8lo25av813oryga/fixed_spine_cannons_-_pixi.js.zip

I've updated the issue to explain this correctly, and cleaned up my wall of text :)

[photonstorm]

This happens for BitmapFonts too. It creates PIXI.TextureCache entries based on the character codes, which of course are identical if you've more than 1 font, so at present you're limited to just 1 bitmap font in your game.

[englercj]

@photonstorm I'm not too crazy about the bitmap font implementation in general (I don't use it in grapefruit), so there are a couple issue we should fix there.

[photonstorm]

Yeah I think we're doing very similar things re: grapefruit and phaser! I use UUIDs for the texture cache entries to get around these sorts of problems.

[andrewstart]

While the BitmapFontLoader stores each character in the texture cache, the BitmapText object doesn't actually look at the texture cache, so it is safe to remove that bit from the loader and/or use multiple bitmap fonts.

[choppingblock]

@englercj is there any way to not use the default AssetLoader with Spine objects, or might here be any know workarounds for the collision issue?

[GoodBoyDigital]

hey guys - this issue has been hanging around for a little while! @ryanmcnz the latest version of pixi should have that sorted. If you could confirm that would be ace. Thanks!

[ryanmcnz]

Hi Mat! This issue still appears to be occurring with the latest Pixi.js release.

I've tested this with the latest builds for both the Master and Dev branch (most recently compiled 2014-02-08), using the assets example linked in my first post.
This test was done using the latest release of Chrome, Firefox and Chrome Canary.
These all had the exact same behavior/outcome.

Expected outcome:

• Two cannon spine animations are shown. Each uses a different texture.
• The left one is orange with a small green square at the tip.
• The right one is green with a small blue square at the tip.

What's occurring:

• Two cannon spine animations are shown.
• Sometimes the two cannons are correct.
• Sometimes the two cannons are randomly using the same texture.

I think another test that could confirm if this bug still exists is using multiple different BitmapFonts simultaneously.
Cheers for all the awesome work on Pixi.js btw!

[GoodBoyDigital]

@ryanmcnz sorry about this but I think I responded to the wrong post (I have been going through the issues today) this is something we will definitely be looking at post 1.5.

[ryanmcnz]

@GoodBoyDigital Ah yes no problem, looking forward to 1.5.

[AndreiBarsan]

A very simple way to trigger the texture conflict is loading both Spineboy and Pixie and then trying to render Pixie. The character will look normal, except for the head, which will be replaced by Spineboy's.

[vpmedia]

Hi,
I've the same issue as mentioned in the current ticket, any advice how to solve it?
Are there any existing extensions which allow me to use different caching IDs?
I'm referencing this request too:
http://www.html5gamedevs.com/topic/5445-best-way-to-load-texture-atlases-with-the-same-frame-names-possible-pr/

Actually I'm working on a project which involves sharing assets between Flash and HTML5 client, so i've a fixed naming convention already applied, which is like:

asset.zip/common/spritesheets/buttons.png (which contains sequence of images 0.png,1.png,2.png..)
asset.zip/game1/spritesheets/buttons.png (which contains sequence of images 0.png,1.png,2.png..)

if(gameN/spritesheets/buttons.png exists i use that with frames (0.png,1.png), if not i fall back to common sheet ..

[englercj]

This works differently in v3 now with the new loader system.

[painkkiller]

I use pixi.js v4.5.2, I have a lot of spritesheets containing sequences of frames with names 001.png, 002.png ... etc, and I have a lot of warnings in my console which looks like this:
bundle.js:19178 Texture added to the cache with an id [001.png] that already had an entry
so I suppose this issue still isn't resolved?

[englercj]

Can you open a new issue with a running example of the problem you are having please?

[painkkiller]

Ok, I'll try to do a reproducible example

[gle6as]

Hey, the problem still here. Created new issue here: #4156

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.