Paper2D spritesheet - extreme large sprite texture files in UE4 after importing via spritesheet

Development Rendering
1

Hi all,

Project : Unreal 4.12.5 - Paper2D project.

Skills : Not new to UE, but fairly new to Paper2D.

When I use TexturePack to create my spritesheet and accompanying texture file and I use for instance the PNG-32 (PNG-8 gives a similar result) texture format with whatever pixel format, I end up, at the TexturePack-side, with multiple texture files (2048 max size) and they are all around 4 MB each (around 1 MB for PNG-8). But after importing them into Unreal via a Paper Flipbook, the same texture files are generated in Unreal but are over 20Mb each … … so a couple of animations, one would expect to be max a couple of MB’s in texture files, end up near 100 MB !!! My customers will need super-devices with extreme large drives on to have a game (with very few animations) work like that …

Correction : these large uasset texture files are after packaging (cooking ?), see my next entry. The result however is the same. I end up with a game of 4 sprites each with an animation of about 30 secs and a packed pack of over 300 MB …

I looked at the settings for all UE files (like the texture files in UE), but did not find anything useful.

I played with the source texture file settings in TexturePack and I had the best results, but still unacceptable, for settings : PNG-32 with pixel format RGBA5551 (I need the alpha). There, I ended up with texture-files of 15 MB each in UE.

Looked on google and the forum, but did not find anything useful.

Any help would be appreciated.

Cheers,

Geert

2

Well, well … … in unreal one of these texture files is approx 15000 Kb (bits, not bytes)(in windows explorer app 4000 KB - close enough), but on my android that same file is around 14,6 MB (mega bytes) …

For the windows (32 and 64) packages, I cannot see the individual files as they are packed into one large file. But the total size of all packages are ruffly the same (300+ MB).

Any insights on this would be appreciated …

BTW, I have only one level and no extra content is present in the project. I set the project up to only cook that one level anyway.

Strange …

Cheers,

Geert

3

No ideas at all ? Looks like I’m the only one having this problem or is nobody using Paper2D and spritesheets (from TexturePack) ?

Since in UE the size of the texture file is acceptable, but after packaging, it is not, I suppose it has nothing to do with TexturePack, but is possibly some mistake in cooking ?

For a moment I thought I had found the answer, as for android, the cooking must be done for the diverse formats supported, but, as I mentioned before, the same problem must be for the Win32 & 64 as well as they have slightly smaller packs, but still at least 250 MB after packaging.

Have looked around so far to find something on it, but nothing so far …

Again, any help or insides are appreciated !

Cheers,

Geert

4

Just did a quick test in 4.13 to see if it might be some known and fixed bug, but the result is exactly the same. A texture file in UE that has the size of 4 MB grows to 16 MB after cooking …

… tested it on android and windows.

This time, unchecked the pak file option, so I see the details now and it is exactly the same as for android … … 16 MB for one single sprite with one movement of about 6 secs (the complete movement exists out of a multipack of 5 texture files and is around 70 MB for 30 secs !!!) …

Since I do not get any replies and I need to go forward, I will have a look at the competition if they can deliver a better working solution for 2D.

Cheers

5

For those interested : in case of 2D, some of the competitors do a much better job … … and package way smaller packs when spritesheets are used !

For 3D, I still like UE a lot - the graphics are so good looking ! It is a shame for the 2D part …

Cheers

6

Hello,

When importing from texture packer with the unreal export setting then by default the compression method is uncompressed meaning a 2048x2048 texture is aprox 16.5mb.

You could always use the standard ue4 compression method that would make the texture 4 times smaller but with some compression artifacts. Most of the Time you won’t be able to see the difference But in some cases You might need to use bi linear to regain some of the detail.

You must also understand that spritesheets are not ideal for every situation. They are only good for small animations. If you need more that 10-15 frames per whole animation you should start using more advanced tools like skeletal meshes and real time tweening
Cheers.

7

Hi ,

Thanks for replying !

The 2048x2048 textures are compressed in UE and are app 4MB in size. That is not the problem. It is after packaging (cooking) that these files go to app 16 MB each and that is unacceptable and to be honest I do not understand why at all …

I’m currently using a lot of spritesheets combined with some code in Unity and it works not only faster than in UE, but smoother as well and no problems found so far. The packaged files are all very, very, very small in comparison to UE, because the spritesheets are are compressed … … and the startup time on android for instance … … no longer waiting for 30 secs, starring at a black screen, before the splash screen pops up. No, right now on android, within the 2 or 3 secs, the splash screen shows up, out of the box …

Thanks again for replying, but I’m more and more convinced that Unity will be my 2D tool from now !

Cheers

8

You must use PO2 textures in order for them to go through the streaming method in UE4. Check if the “never stream” option is checked. If it is then regardless if the texture is referenced or not it will load to memory resulting into slower loading times.
I have to agree with you that Paper2d still needs a lot of work, and i am giving them hell every chance i get, but on the other hand i can feel that most of your issues are not related with paper2d but a general understanding on how Ue4 and game design in general works. As a vague rule, UE4 is massively more complicated than unity and that results in a much larger footprint of the engine. It is true that Unity might be better suited for mobile (i haven’t tried anything mobile to be honest) and if you develop for them maybe you should stick with Unity.

But in my humble opinion, you are using bad practices regarding the usage of sprites and sprite sheets that as your game becomes bigger and bigger you will face VRAM , loading time , project size and draw calls issues that are going to be very difficult to fix regardless the game engine. The fact that are compressed does not mean that they will be loaded that way into memory!

Just my 2 cents.

Cheers.

9

Really dude ! “My issues …” ?!?

I’m just testing out something and discover that an imported PNG in Unreal is of size 4MB as uasset file. After cooking, the same file is found as a 16 MB file on android and that is not paper2D/UE4 related ? If it is me not understanding “the gaming industry and all their special little secrets”, how come that Unity does not have that problem ? I presume the only conclusion, if I follow your logic, must be that Unity is not a game engine …

You know what, I am a programmer for over 30 years now (diverse languages) and have dozens of certifications (and experience) in IT in general. So I think I can make my own judgments in that field.

I’m not a Unity fetishist , nor am I an UE fetishist and I do not “like” c++, delphi, c##, java, virtualization, linux, ITIL etc in particular.

I like “things” that offer me solutions to the problems I face and then use these for the projects they fit best for.

An extreme slow starting splash screen, is something every programmer had to face in the early '90’s when the computers were a little slower and keeping memory consumption and processing power low was of capital importance. You just started your program with a small external program that pops up as the splash screen and then, with a small delay (giving the UI the time to draw it to the screen), you start the actual program …

Your remarks on the memory usage and draw calls are founded and I already took them into account.

To be brutally honest, I’m closing this discussion as I still have not heard anything that would count as a reply for the original question …

If you wanna have the last word and reply, fine by me. You are the best and I wouldn’t even dear to question your knowledge and skills in game creation and UE in particular.

Cheers

10

Well that escalated quickly! :slight_smile:

And that is one of the reasons that I have stopped participating in the forums…

My sole purpose here is to try to help you. I had no intention to make you angry.

Now back to our topic.

As I said earlier paper2d and unreal are not perfect. Far from it. But I want you to think out of the box here for a second. Let’s say X Game engine can package your game at 200mb and Unreal does the same at 400mb. It is double the size. Not good.

What if instead of trying to compare apples to apples you started using one texture for 100 animations and the same game would pack in ue4 for lets say 50mb?

Would it matter then if unreal is not as efficient as X game engine size wise? Because in all other aspects it runs circles around it except for the size.Would you pick an inferior X game engine just because of this ,when you can cure it with another method?
See what I am trying to say? Everything is relative. Your argument would be valid if you had exhausted every other way to reduce size and that was the last one.
And as a veteran coder you should have known by now that brute force is not the best option. There are always alternatives to any given problem.

I wish you the best and good luck with your project.

Cheers,

11

I’m by far the least qualified to answer this question but my stab in the dark is to think that this might be something regarding Mipmaping. Unreal engine will generate a mipmap file for you without you having to provide it. You might gain a smaller footprint with uassets if you tool around with these settings in the texture file, as well as compression and streaming. With texture packer I usually approach it via the smart folders that they provide, and use standard quality with a fixed power of 2 at 4k by 4k with multi pack and seem to drop my usasset size to those 1mb or 2mb per texture file that comes in. I also use TGA instead of PNG. not sure if that helps. Another nifty trick I learned that tends to drop file size is creating assets without an alpha channel and then providing the alpha channel via it’s own texture (also helps with smoother 2d textures.) just requires a little more material system setup.

Also each frame size for my game is 512 by 512 (which is SUPER huge, but we’re going for a more painterly thing.)

Also I recommend reaching out to an engine dev dude on Twitter, they’ll be able to tell you straight what’s up haha. That’s what I do whenever I run into an issue I cannot outright figure out or know that it’s well beyond my means of google-fu’ing.