Tk2D Bundling - Duplicate Memory?

[jmcguirk]

Hey Folks,

Was wondering if I could get a little help on our TK2D asset bundles.

We're building a mobile trading card game and are using the Spine framework to animate our characters. Skins are created by our artists at 4x resolution and cut up into a series of PNGs. We resize those PNGs into 1x and 2x sizes and create dedicated TK2D sprite collections for each atlas. We then create a dedicated asset bundle for each character that contains the tk2dSpriteCollectionData and some configuration data about the skeleton. We then serve up the appropriate platform bundle to the client at runtime. What we're seeing is Unity is including the original PNGs in the IPA/APK - I think this is because TK2D maintains a reference under Resources/Tk2D to each Atlas thats been created for use by Tk2DSystem. Having the duplicated copy of the texture atlases shipped with the client sorta defeats the purpose of bundling

Here's a deep dive of our workflow

http://i.imgur.com/RARAFtj.png

1.) Each skin is imported as a collection of PNGs and propped up into a platform specific tk2d sprite collection.
2.) A prefab is created that joins the rig data, the texture data and some game configuration about the skeleton. This prefab does not live under a resources directory
3.) Platform specific bundles are created that reference the prefab created in #2.
4.) Inspecting the Resources/TK2D shows that there are references maintained that point back at the atlas - this appears to be because Tk2dSpriteCollectionBuilder.cs makes an unnamed loadable object.
5.) Build output confirms that the atlas is indeed bundled with the final build. Even though the only "usage" under a resources directory is the Tk2D index reference.

Outside of creating a dedicated project to build my bundles (which I'm a bit loathe to do since its a logistical pain) - is there any way to get Tk2D to NOT reference these atlases as I'm explicitly managing loading them?

[unikronsoftware]

Your assumption is correct.
The 1x, 2x and 4x multi atlas workflow is meant for local use not asset bundles. If you're building asset bundles, why not build the 2x and 4x atlases (or whichever way you're going) manually?

I'd personally just set up a little workflow there whereby the sprite collection is mirrored into a new one, and built into a sprite collection right before the build, bypassing the 2x and 4x workflow altogether. This will get built into the asset bundle. The code is all there, and should be relatively straightforward to extract into your own workflow there.

Alternatively, using a separate project could be one way to go.

One more option:
1. Add some code to not add these to the tk2dSystem resources folder.
2. Make the @1x, 2x etc sprite collections selectable from the interface, so you will be able to use them.

[jmcguirk]

Cool - thanks for the quick reply.

We are indeed side stepping the mutli-platform support in Tk2D since we came to a similar realization - namely we'd be shipping the high-rez textures to low rez clients even though they wouldn't be used (and vice versa). So we have dedicated 1x/2x/4x sprite collections and build them as part of our build process

I'm a bit hesitant to setup a second project, since I'm worried about code drift between components attached to prefabs created in the separate project and the core project itself.

For now - I think we're just going to hack it out and delete the Resources/tk2d_*.asset files that we know reference collections we intend to bundle as part of the build process.

Longer term - is it a reasonable request to have a flag on the sprite collection data that indicates this collection should be excluded from the index (so it doesn't get created as part of the sprite collection builder and also doesn't get picked up on tk2d -> rebuildindex)? This would indicate that this sprite collection is either intended to be shipped as part of an asset bundle or is not inuse at all.

[unikronsoftware]

Adding the flag is easy, but the problem with doing that is that the rest of the editor code, etc. will just fail to work. This is basically making an unloadable, unusable sprite collection - except through asset bundles, and this is a bigger change than you'd think it will be. I'll think about adding it to a future version, and I will if I can come up with a nice solution.

[miningold]

I'm about to start a new project and I would like to use asset bundles for platform sizes 1x, 2x, and 4x to help with bloat. I was wondering if you could elaborate on how to manually create 2x and 4x atlases/sprite collections. You also mention that "The code is all there"; where is this code that you speak of?

Thanks

p.s. I know this thread is a little old. Let me know if I should create a new one.

[unikronsoftware]

When you add 2x and 4x platforms to a collection, it creates a 2x and 4x collection which is then added to the tk2dSystem loadable list.
This means it will be referenced from Resources, and will be included in your build, and won't be selectable in the list.

Code: [Select]

// Make loadable
tk2dSystemUtility.MakeLoadableAsset(data, ""); // unnamed loadable object
in sprite collection builder makes it loadable. You need to detect these collections you want to make asset bundles from and make them not-loadable. By doing this you'll get 2x and 4x atlases which aren't linked to your build, but have synchronised sprite Ids, etc.

The second thing you need to turn off is managed sprite collection. It should be false for the platforms you want to build asset bundles with.

Code: [Select]

font.data.managedFont = gen.managedSpriteCollection;
font.data.needMaterialInstance = gen.managedSpriteCollection;
and

Code: [Select]

gen.spriteCollection.managedSpriteCollection = gen.managedSpriteCollection;
gen.spriteCollection.needMaterialInstance = gen.managedSpriteCollection;

By the code is all there - tk2d does almost everything you need, use as much as possible. You can do this by turning off a few things, starting with the above. If done correctly, you should be able to explicitly select the @2x / 4x collections in the list, and it should no longer be included in the build. You can build an asset bundle out of these now.