2D Toolkit Animations on Macs

[VGT]

I have been making sprite collections on my workstation for a while now.  It is windows 7 64-bit with 8 gigs of ram.

Recently we included our artists in the use of 2D toolkit.  They use MacOS 10.6.8 64-bit with 12 gigs of ram.

I have found out that when creating large animations that require multiple atlases at the size of 4096, my windows machine can make two or even three but the macs that the artists are using can't go beyond one.   Unity crashes way more often on their machines due to running out of memory.

We are sure to compress our atlases and check the box multiple atlases.  We also disable sprite thumbnails.

We are all currently using 1.61 but are considering upgrading to the latest version.  (we wait on this because it must be company wide and therefore approved)

Is there an improvement to the Mac performance of 2D toolkit in the new version?  If not, is this an issue that Unikron is aware of or are there settings that are different on Macs that can be used to improve this?

Thank you for the assistance.

[unikronsoftware]

This is most likely an issue in Unity and/or the OpenGL driver. Which version of Unity are you running? I can attempt to reproduce this issue and raise a bug with the Unity guys if I am successful.

You're doing all the right things there by compressing the atlas and disabling sprite thumbnails. When you say you've got the multiple atlas checkbox ticked, how many atlases are you creating from one sprite collection? How many in total used by one animation? What compression mode are you using?

As you have enabled the options in there (compressing and disabling sprite thumbnails), all the system does is refer to these directly which seems to be sufficient to cause a crash, implying that there is a difference in the way the resources are managed on Windows & Mac.

There isn't any improvement in 1.7 specific to the Mac; unfortunately this looks like a bug/limitation in Unity. Hopefully once I get the info I need from you, and I am able to reproduce this, I'll be able to send Unity a bug report.

Look forward to hearing from you and somehow identifying/solving this issue.

[VGT]

The version of Unity that the both of us are using is 3.5.1f2.

In reference to multiple atlases, the mac cannot create more than one atlas when the first one is 4096x4096. I can try to create the same exact image sequence on windows and Unity will not crash and multiple large atlases will be created.  Windows can create 2 to 3 full sized atlases before unity runs out of memeory (depending on the amount of alpha in each frame and thier sizes).

As far as compression goes, we've both een selecting the plain 'Compressed' option. One of the artist says that selecting the 'Force Square' option made unity crash less often which I found interesting (and failed to mention in my first post).

After you mentioned that this might be an issue in Unity, it could make a lot of sense.  Another artist who does most of his Maya rendering on a windows machine that is far less powerful than his mac because Maya works way better on it.  This could be because of a similar OpenGL driver issue or an efficiency with resource handling on the Mac side.

I truly apprecaite the help and hopefully if this is a Unity side problem, we can point this out for them so they may further develop their engine!

[unikronsoftware]

Thanks for updating this. I'll look into this and try and produce a bare-bones test case for the Unity guys to look at. Hopefully we'll get to the bottom of this soon.

Would it be possible to test with Uncompressed or 16bit reduced instead of "Compressed"? Creating a compressed texture does use a LOT more memory at the end of the atlas generation when building the compressed texture, but a lot less when using the texture, for example in the animation editor. I would greatly appreciate it if your artist could try it with just an Uncompressed texture to see if he gets any further.

Also, I suggest not using the "multiple atlas" option, but rather split up the atlases by hand. This will end up requiring less memory as all the texture won''t have to be resident at the same time.

In any case, I'll go ahead and build this test case to see how far I can get with it on the Mac. I'll keep you posted

[VGT]

Is there a compression format that could be specific towards Macs that could fix this?

[unikronsoftware]

Don't think so. Unity doesn't expose specific details in there, though Mac and PC use the same gfx hardware and the compression formats are the same. I'll get back to you after I do a few experiments

[unikronsoftware]

I've managed to find a bug (I hope) where the texture size is significantly larger than expected. Its really easy to reproduce - eg. drop a 4096x4096 texture into the Unity project, and then make sure the max texture size is 4096, and set compression type to Uncompressed. Restarting Unity and simply clicking on this texture increases memory footprint by around 400MB. This isn't good at all, a 4096x4096 uncompressed texture with mip maps should take around 85MB of memory. 400MB is a LOT of memory to be throwing away.

Second issue, once that texture is clicked, the 400+MB is never regained. This could be a very big issue long term.

I've managed to isolate these so it happens when creating a texture from code as well - this is what 2D Toolkit does. Creating multiple 4096x4096 atlases will be leaking around 400MB per texture, and could cause serious issues. I've submitted a bug report to Unity about this. I'll update this thread if I hear anything.

I've got a couple of ideas to try out to reduce memory overhead working around the Unity limitations. I'll let you know if any of these work out.

[unikronsoftware]

I've got a response the Unity support guys. Apparently a lot of things get allocated when a texture is loaded in (multiple copies are created for various reasons) which explains my repro case. I will have to create a new one to try and narrow this down further - I am still convinced there is a problem specific to Mac, my previous repro case exhibits the same perf on both Mac and PC.

I've also got to try my other idea, where it bypasses saving textures using the Unity Texture2D class. I've only got a really naive TGA saving thing right now, I'll experiment with that to see if I can save any further amount of memory there. In terms of raw memory, the usage for each of these textures should be very very low. A 4096x4096 texture is only 85MB, so if I can bypass the Unity overhead, it might be worth doing this.

[VGT]

Thank you for the Update. For now we are putting sprite collections together for our artists on windows machines, but we look forward to a day when we can do this on Macs.

[fatclike]

I'm not sure if this is the same issue that's being posted here.

I have a sprite collection which I committed.
I made a ton of sprite animations from the sprite collections and then made prefabs using those sprite animations. Everything was working fine. I then copied the project folder into a dropbox for a coworkers use. When I reopened the scene none of the sprites were showing up. I clicked on the animations and receive the Warning: "Invalid sprite collection found. This clip will now be deleted."  So basically I am now redoing the 50 plus animations. I also need to link the corresponding prefabs to a different animation and then relink to the correct animation before the prefabs register the animated sprites correctly. This is setting me back a ton, but luckily I'm early on into the project otherwise this would be terrible. I made sure to reopen the sprite collection editor after committing the collection. When I closed the project and reopened it, all of the fixed animations are showing up. I guess that's a fix for my problem, although it's very worrisome that I need to remember reopen the sprite collection editor before closing the project otherwise the collection with become invalid.

Is there something I'm completely missing. I am new to this program although I have a lot of professional experience using other game editors.

[unikronsoftware]

Hi fatclike, could you start a new topic, please. I believe this issue is different. It does warrant a full and thorough investigation - I've had a few reports of this happening but no one has had any reliable way of reproducing this.