App Thinning / Texture Atlas Clarification

Hello, I am trying to understand how app thinning and texture atlases work together regarding optimizing images. The underlying question is related to the inclusion of texture atlases in "Thinned" applications.


I understand that your images are selectively included using the .xcassets catalog, but it is unclear as to how that works with regards to texture atlases. What structure should be used when creating a iOS 9 compliant "thinned" app, which includes texture atlases?


In the past, I have created .atlas folders for both @1x and @2x graphics, and included the appropriate graphics in code, depending on the multiplication factor. In that case, does app thinning still execute on graphics within those seperate atlas folders? What is the recommended way to support @1, @2, and @3 graphics in a forward compatible way, honoring app thinning, while using texture atlases?


Finally, seeing as you can create texture atlases at runtime, is that recommended? I could see an environment where the images are stored in an Asset catalog, (getting "thinned" on installation), and then on-device compilation into a texture atlas upon the first app initialization. But in that case - testing is sure to be impossible.


Thanks for any insight related to this topic.


Cheers,

keny

In order to take advantage of App Thinning on Texture Atlases, you have to add your atlases to your app's Asset Catalog. In the Asset Catalog, Click the "+" button and select "New Sprite Atlas".


This is terribly tedious, so I've written my own set of toolchain scripts to generate the atlasses in the asset catalog format.

Karim:


I reread your post and realized you said to load your Atlases in the asset catalog. (I originally read that as images) By doing such, I am assuming you are somehow creating the .atlas folders somewhere else and generating the atlas and the definition files.. How does one coerce sprite kit into reading the plist containing the image mapping? Can you please elaborate on your method to get SK to use texture atlases via asset catalogs?

Sure. So I'll walk you through the steps, but recognize that this isn't really practical to do by hand... You'll probably do it once, then get so tired of it, you'll want to write a script.


  1. Open up your Asset Catalog (or create one if your project doesn't have one already)
  2. At the bottom of the assets list, click the "New Sprite Atlas"
  3. Name your new atlas item just as you would name a *.atlas folder, but without the extension
  4. Drag your texture images into it just as you would any other Asset Catalog collection


Usage:


For manipulating the Atlas images, you do this just as you would any other Asset Catalog image

For interfacing with the Atlas in code, you do this just as you would before. In fact, if you don't change the atlas name, and you don't change the texture names, you probably won't have to change any of your code.

Sorry, the forums ate part of my post. #2 should say: "At the bottom of the asset list, click the "+" button then choose "New Sprite Atlas"."

So i looked in the application bundle and cannot see where the atlas is being created using this method. Not sure if it is actually creating an atlas (compiled image where all the images are combined into one)


Can you cite the appropriate documentation as related to this?


Thanks, and regards,

Keny

I can't point you to any documentation. I'm just detailing what an Apple engineer showed me at WWDC.


As for where the resulting atlases would be, the entire Asset Catalog will be compiled into an opaque file called "Assets.car" in your compiled app. I've not personally found any way to examine this file.

If there is nothing actualyl compiling the images inside an atlas folder to an actual altas image (a big one, with many images in it), then it's not actually a real atlas and in such a case there is no value in using that approach at all, granted that using sprite atlases still speed up rendering due to the fact that the graphic rendering code and/or hardware still can render all that stuff in just one cycle etc etc. This needs to be sorted out. I'm not sure but I guess any OpenGL game/software would still benefit from using sprite atlases. Not sure about Metal based ones.


Having said that, I didn't realize we can now create Sprite Atlases inside asset files. I'll try this out.

On another note, iPhone 6 Plus still do not choose to render 3x images frmo 3x atlases even on iOS 9.0.2, if using the "old" way of atlases (folders ending in .atlas). That was a bug and it's still not 100% fixed... unless that works with atlases in asset files. I'll try this out.

Back from testing.


3x atlases still don't work. They are generated, both if inside an assets file, or outside. However SPriteKit and iPhone 6 Plus for some reason don't use the 3x atlas. It still only uses the 2x atlas.

Please, if you can, report back.


Atlases and their auto-generation is claimed to be a feature useful for designers to help them more rapidly iterate through art creation.


But from the inception of Sprite Kit it's had problems of all sorts, none of which are easy to discern and/or resolve for designers, the group for whom this feature (apparatently) exists.


Conversely, designers (especially for games) tend to have enormous experience packing their 2D assets in the traditional ^2 sheets for programmers to use, and even go so far as pixel peep (not to annoy programmers) to make sure there's no edge bleeds or other issues when it's unpacked in the engine.

Guess what, I think I just got it to work. My last comment was using a deployment target of iOS 8.4... well, I changed that to 9.0 and what do you now, my iPhone 6 Plus suddenly shows the 3x graphics (I put 3:s in the images to be sure). It's a very basic scene (albeit with some physics going), but I get 60 fps so far. I'm exalted right now :-)

It's a great shame (sham?) that Apple doesn't feel compelled to do better, current and informative documentation for Sprite Kit and Scene Kit.


Thank you, Karim, for taking the time to impart the knowledge gleaned at the only place where they seem to share and discuss things pertinent to their frameworks.


Once a year. In America. For a few days. In between presentations. In the "free-for-all" labs.


// Anectodotal story approaching:


I filed a support ticket to do with shouldRasterize not seeming to work, and actually causing problems in CA a couple of years ago.


Every attempt to focus on the issue was met with obfuscation.


Not a denial, didn't ever get to addressing the actual problem. Instead several walks around and through other distractions to (seemingly) deliberately avoid discussion of the issue despite sending several demonstrations of the problem in complete isolation.


Eventually received two suggestions:


"focus on the latest hardware because by making it perform great on that you help Apple sell more newer devices." Despite the problem existing on all hardware.


And....


"...come to WWDC if you have more problems..."


I don't live in the USA. They know that.


Many moons later the issue was magically fixed, despite having occurred throughout all of iOS 7 and 8, all of a sudden a late update to iOS 8 fixed it.


No announcement. No notifications. Nothing.

Sure, I probably agree with you to 90%.


But what if you sell product A to user B in the year of 2010 for a fixed sum of money. Until how long will you proceed to support it? FOrever? I don't think so, the math doesn't work that way. You need to eat etc :-) At some point you want to make product C just for an excuse to have something to sell again to user B.

It's the same way with apps... anyway, it's probably a bit off topic.😁

I think you misunderstood (and I poorly explained) the context of the comment about focusing on the current Apple products from the Apple employee tasked with communication on the matter.


We were sending sample projects with varying values for all iPad models, to illustrate the problem.


Each differnt iPad's CPU/GPU performance abilities meant the issue reared up and demonstrated itself at differeing values, dependent on the hardware.


We had even gone to the trouble of identifying some of those crunch points.


His comments about focusing ONLY on current generation hardware came (seemingly obliviously) as a result of us demonstrating concern for the experience of ALL potential customers on ALL potential hardware capable of running the latest iOS version.


We thought that sort of consideration of all user experiences a good thing. He dismissed this.


We also had no idea what hardware they'd be testing on, so sent them our numbers of objects at which choke points occurred for different hardware, all of which demonstrated a failure of shouldRasterize.


Imagine our surprise when he suggested we ONLY focus on the current gen hardware, because that's better for Apple sales.

Wow, that's pretty telling right there. So what are developers supposed to do when users with old hardware upgrade their OS and find their apps no longer work? Tell the users to rush out and buy the latest iOS device? Are you kidding me? What happened to putting the customer experience first?


I know I know, log a bug. Very helpful Apple...

Well, I see that I am not alone. I must admit it is kind of dissapointing to see a bunch of responses but not much taking the available information further but instead to be greeted by a bunch of vented frustrations.


There must be some statistical reasoning behind apple's focusing on other things, e.g. tech that will sell new devices etc...


With all the competing 2d solutions out there, my opinion is that Apple needs to either step up their game here or kill it. Like they killed the 5C design.


I haven't really began my next app yet and am considering switching back to Cocos2d after these revelations.


apple devs: Can we at least get some documentation that illustrates what in fact to do with sprite kit texture atlases?


enhancement request:

22963983

App Thinning / Texture Atlas Clarification
 
 
Q