Messages

1

Support / Re: Fastest way to load PNG assets?

« on: June 29, 2015, 06:15:43 pm »

Yes, I had the knucklehead realization that putting them into Resources as .png files (rather than .png.bytes) has the same effect as using Unity textures in the first place -- totally uncompressed textures in the package.  So yes, loading becomes radically faster...  and your 2.6MB 2048x2048 becomes 16MB on disk.  Fuuuuuuck Unity and its lack of native PNG support, seriously.

I did continue to go in this direction though, choosing to put all PNG Atlases in Resources as .png.bytes and loading them as TextAssets before upload.  This ultimately doesn't *directly* help with load times (still has the massive spike associated with converting a PNG and uploading it to the graphics hardware), but there were positive indirect benefits:

- Our levels point at SCs that are not needed at load-time, this allows us to only load the TextAssets and convert them to Texture2Ds when we actually need them.
- ...which reduces memory footprint and level load times.
- ...and allows us to actively manage SC memory while travelling between sections of levels that have different SC needs, keeping max footprint down.

All of this for the love of the iPad 2

2

Support / Re: Sprite Collection Mystery Junk

« on: June 27, 2015, 10:01:08 pm »

(continued...)

Of course, the saved "Alpha is Transparency" flag in the .meta file is off, because that's how it's configured after being spit out by the SC builder.  Rebuilding the sprite collection doesn't change anything in the .meta file, I suspect that it actually just forces the Unity importer to update whatever is in the Library before it silently changes things behind the scenes. 

3

Support / Re: Sprite Collection Mystery Junk

« on: June 27, 2015, 10:00:11 pm »

Figured it out.

It was an "Alpha Is Transparency" thing cause by Unity forcing texture importer settings while in 2D mode. 

I keep trying to post this reply but the message board keeps complaining...  what if I keep it shorter?

4

Support / Re: Sprite Collection Mystery Junk

« on: June 26, 2015, 12:22:42 am »

I would love to identify the root cause, but given that I'm 26 months into a project and am trying to ship in a week, I really am not all that opposed to trying workarounds. 

As I've mentioned multiple times in this thread, the texture that is on disk is not the problem.  It does not change on disk AT ALL before vs after.

Is the texture in memory different from the texture on disk?  I don't know, I could try to look at that more closely. 

Is the texture in /Library different from the texture in the project?  I have no flippin' idea how Library works.  How would this even be possible?  Library is getting built from scratch but then is only updated after I click "Rebuild" on the SC?

5

Support / Re: Sprite Collection Mystery Junk

« on: June 25, 2015, 11:39:04 pm »

Ugh, I had completely forgotten about Library. 

Our buildbot does a completely fresh rebuild -- that means there is no Library when it builds. 

So it is precisely at this point in time where the textures for the sprite collection(s) in question are messed up.

I perform a completely clean sync to a brand new folder, run Unity, let it build the library for an hour, come back...  and this problem is there.

I rebuild the sprite collection manually and suddenly the texture draws properly.  The only thing to change in my entire project at this moment in time -- outside of /Library -- is the SC's .meta file, which now has a different buildKey property.  I think I understand what that is well enough to know it's effectively meaningless.

And yes, having just diffed the current Library versus the pre-rebuild Library, a couple of files change.  Including a binary that clearly contains data for the sprite collection in question.

The IMAGE itself -- the actual PNG data -- is not different AT ALL before vs after. 

I'm thinking of writing a script into our build process that rebuilds all Unity Texture Atlas Sprite Collections in our project.  Which is insanely stupid to have to do... but it might work?

6

Support / Re: Sprite Collection Mystery Junk

« on: June 24, 2015, 02:53:51 pm »

I "rebuild" the sprite collection and it starts working, with the only change in the .meta file being the buildkey (as I illustrated in the attached file above).  I submitted that change to SVN but the problem is still exhibited in the build.

OK, that's the .meta file for the SCData prefab.  The .meta file for the .PNG looks extremely straightforward, just like every other imported Unity texture.  I do not spot anything unusual.

I mean, do you look at this image and think "oh I've seen something like that before?"  It looks to me almost like the texture in memory was not initialized properly, like there are a bunch of random bits floating around and the actual Texture got uploded "over the top" of some random gunk.  But that makes about zero sense to me.

I flipped the collection back to "PNG Atlas" and it appears to be working fine, though this is not really a final solution as we intend to use more Unity texture atlases for load-time and load-memory benefits.

Any more specific suggestions you have would be helpful.  Thanks!

7

Support / Sprite Collection Mystery Junk

« on: June 23, 2015, 10:58:46 pm »

Hello Unikron,

Having a mysterious problem.

Our build machine -- which grabs a pristine version of our game from SVN and builds target players from scratch -- is producing builds where a specific (very important) Sprite Collection is rendering with a bunch of mystery junk visible.  This is true in both in our iOS and Steam builds.  If I pull a fresh check-out from SVN and run the game in the editor, the problem is there too.

I don't know how better to describe this, so please have a look at the attached image.

As you can see:

- The image in the generated SC atlas PNG is pristine.
- It does not appear to be indexing out of bounds, it's just drawing garbage of no origin along with the correct artwork.

I can "fix" this by rebuilding the SpriteCollection.  It has NO effect on the SpriteCollection PNG data or the material.  It DOES, however, touch one line in the SpriteCollectionData prefab (also shown in the attached image).

Umm, so what the heck IS a buildKey anyway, and why would it change, and why would it have anything to do with this problem?

Now, the one bit of potentially useful information I have for you is that this particular SpriteCollection recently went through a change.  It was previously a PNG Atlas, and I changed it to a Unity Atlas (for the half-second of load-time increase that might grant us in our iOS build).  The TextureImporter associated with the Texture2D is setup properly.  There is no compression enabled or anything of the sort.

I have briefly noticed this in other, similar SCs -- rebuilding generally has "made the problem go away."  We're < 2 weeks from ship and I don't like mystery problems this close to the end.  Any ideas?  Any way to make this NOT happen again?

Thanks in advance for the support!
David

8

Support / Fastest way to load PNG assets?

« on: May 27, 2015, 04:55:25 am »

Hello,

Our load times on older mobile devices (e.g. iPad2) are dismal.  We load quite a bit of 2D art, all of which is stored in PNG Atlas style sprite collections.

Anyway, after doing some research on the interwebs, I discovered that the standard 2DToolkit method for loading PNGs (calling LoadImage on a TextAsset's bytes followed by Apply) is quite a bit slower than loading the asset using Resources.Load.

I hacked together a test -- put one of my 1024x2048 .png assets into Resources and loaded it both ways on an iPad 2 -- and lo and behold, the LoadImage / Apply method timed at about ~0.75 seconds vs ~0.13 seconds for using Resources.Load.

I'm curious if there's some reason I shouldn't just be spitting built sprite collection .PNGs into /Resources with unique names, saving those names in the tk2dSpriteCollectionData, and then loading them via Resources.Load instead. 

Additionally, this isn't accounting for the benefit of not having to load those PNG TextAssets just to create the actual Texture2Ds, which Unity automagically does if the Sprite Collection is referenced in a level anywhere.  It certainly seems like it warrants a further experiment on my end, unless there is some clear reason this won't work that I am missing. 

So is there some clear reason this won't work that I'm missing? 

Thanks in advance!
David

9

Support / Shader can't be changed on PNG Atlas Sprite

« on: March 03, 2014, 06:38:33 pm »

Repro case:

1.  Build a sprite collection with Atlas Format = PNG.
2.  Add sprite to level.
3.  Change sprite's shader to anything else.
4.  Run the game.  Sprite shader will reset to its default, which is undesired behavior.

Workaround:  change sprite collection to Unity Texture format, rebuild, change atlas material, change sprite collection back to PNG atlas.

10

Support / Re: PNG Atlas vs Not-PNG Atlas?

« on: February 19, 2014, 06:57:00 pm »

Personally, I like having the choice!  Which is why the PNG Atlas tool is so critical, in spite of its rough edges -- because Unity currently doesn't let the developer choose easily, and instead always opts for speed over package size.  Which is great on PC... but on mobile, it's almost always the wrong choice.

I made a post on the Unity Feedback system endorsing a native implementation of such a feature:

http://feedback.unity3d.com/suggestions/png-and-jpg-texture-format

Please go vote on this issue!

Using PNG Atlases brought our package down from 800MB to under 200MB...  we're going to release a big game for mobile no matter what, but it can't be in the GB range.  But it should be even smaller -- a number of our textures, including stuff we aren't using 2DToolkit for, or stuff we're using in conjunction with the Spine animation system can't be easily compressed. 

Native Unity support for PNGs is the best long-term solution and people should feel free to make some noise about it

11

Support / Re: Sprite Scale

« on: February 19, 2014, 06:47:31 pm »

Wouldn't sprite scale be more useful if it actually scaled the size of the image as it gets packed into the sprite collection?

I believe that if it worked that way, it'd be insanely useful -- then our artists could by default import art at maximum size and selectively scale individual images down to optimize their sprite collections, without having to touch the source art.

I'm not sure what the point of exposing this in the sprite collection editor is otherwise?

12

Support / Re: 2.4B1: Sprites sometimes not displaying in Editor

« on: February 12, 2014, 04:12:23 pm »

I'm seeing something almost identical to this with sprites from my very first PNG Atlas in tk2d 2.3.3 (with the latest sprite unloader code that you emailed me the other day).  Suddenly all the sprites from that particular atlas go pink in the editor.  If I press play, the pinkness goes away (and stays away when I return to edit mode).

I'm trying with the sprite unloader disabled today, will report back later.

13

Support / Re: Sorting Order automatically set on activation?

« on: February 11, 2014, 07:58:05 pm »

Transform, Mesh Filter, Mesh Renderer, tk2dSprite, Mesh Collider. 

Of course, now that I've changed the Order in Layer to 1, I can no longer reproduce this on this particular object just by changing it back to 0.

It's still happening to other objects, however, like an animated sprite on the same loading screen, which has Transform, Mesh Renderer, Mesh Filter, tk2dSprite, and tk2dUISpriteAnimator on it.  Its Order in Layer goes from 0 to 1003...  why?  I have no idea.  It doesn't happen consistently to all sprites.

I have no explanation for this...

14

Support / Sorting Order automatically set on activation?

« on: February 11, 2014, 01:49:07 am »

Upgraded to 4.3 and noticed some sort order issues.

Apparently if an object doesn't have an Order in Layer specified, it will automatically have one assigned.  For example, I have a loading screen background sprite which suddenly sees its Order in Layer go from 0 to 1001 once the parent GameObject is activated in-game, and I have no idea why. 

I tried placing a breakpoint inside the setter for SortingOrder but it doesn't get hit.

Is this some weird Unity thing?  It seems like if I set the order value myself, it won't be overridden at runtime.

15

Releases / Re: 2D Toolkit 2.4 beta 1

« on: February 10, 2014, 05:54:39 pm »

Just to verify:

Is the "experimental PNG atlas usage detection and unloader" feature the same in 2.3.3 final as it is in 2.4 beta?

I'm looking to do our (hopefully) final 2DToolkit upgrade before ship and would rather be on an official release than a beta, and I don't think 2.4 has anything else we absolutely need.  (We absolutely need PNG atlases)

Thanks,
David