Would it be safe/wise to run my entire assets folder through an image optimisation tool to bring down the file sizes of all images? The tool makes little to no visual difference but a great size decrease. Does any else use this tactic?
I personally wouldnât. Two reasons:
- It may make no visual difference to the human eye, but what does it do for image formats which arenât designed for direct human viewing?
- The source format doesnât impact the build size of the game. If youâre using version control then making re-compressed versions of files already in the repo will in fact take more space rather than saving some (because itâll then be storing the old one and the new one).
If project size is a concern then Iâd be making sure files are as small as they can reasonably be at the time I import them into the project.
2 Likes
Unity has built-in compression that you can turn on for images. If your worry is load times and game size, you can just increase those values.
If your worry is the size of the unity project files⌠I would look into getting rid of unused assets before messing with your source files, as itâll be hard to fix issues if you donât have the originals anymore.
2 Likes
I normally just crunch my textures via unity import settings or adjust its resolution etc there.
Its better that way as you can up and down the settings on the fly or even for different platform builds.
1 Like
Just to be clear, the image files in your project folder donât actually end-up in the build. For the build, Unity creates itâs own image files in itâs own format. so the compression of images in your project folder wonât directly make any difference in the build.
2 Likes
Yep. A feature Iâd actually really like is perhaps some kind of Scriptable Texture Handling Pipeline, a sort of way to do a deep custom configuration of the entire texture handling process. Itâs a ridiculously niche thing though, so Iâm not exactly treating it like a reasonable expectation.
1 Like
Ok iâm glad to hear all that butâŚ
What if I have a 10mb image that Unity compresses to 7mb
What would happen if I compressed it first to 7mb, then Unity keeps it at 7mb? or compresses again to 4mb?
Unity doesnât just compress files itâs own way. It completely changes the file format of them too. For your example the file in the build would be the same 7 MB because itâs no longer using the file format and compression techniques of the source file format. A PNG pre-build will no longer be a PNG once built.
1 Like
Thatâs not how image compression works.
Usually, the tool doing the compression reads all of the data out of the image into a raw format, essentially decompressing it. Then it runs its own algorithm on that raw colour data.
Because of this, compressing an image twice can sometimes make it bigger than if youâd just used the second compression method in the first place, or the same size but with worse quality. This is because the first compression may cause artifacts which are harder to compress than the original image, and then the second compression will try to preserve those artifacts even though this degrades the image and makes the compression less effective.
Also keep in mind that the output formats from Unity arenât just concerned with the size of a compressed image. Theyâre also often concerned with maximising performance on a GPU. Standard image compression doesnât have to care much about performance, because an image just gets decompressed once. With compressed textures⌠well, things are more complicated than that.
1 Like
You can repeatedly compress an image forever. Itâll turn into a brown/black blur before long.
If you want to reduce texture sizes, itâsoften better to reduce their sizes - eg. go from 1024x1024 to 512x512. You can do that in Unityâs import settings. Itâs pretty common that you canât tell the difference on the screen, but the reduction in size is 4x.
I do this with a program called Dove Compress. https://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Dove-Compress.shtml It only does lossless compression. PNG has a lot of parameters and photoshop and things chose a set that are usually pretty good and also fast, my tool tries something like 400 png algorithms in order to get the smallest. It also removes junk from other formats but without quality loss. I actually wrote this program myself and it uses a pngcrush, optipngâŚ
It doesnât affect the size of your finished product because Unity will export it to a compressed format for the gfx card. It does however cut down on backup storage space since Iâm assuming youâre committing your code and resources. Pngs usually end up 20% their regular size.
2 Likes
I am intrigued! My problem is my artist provides me with some overkill textures. Like 4k grayscale linear gradients than can be downsized to 256 with no loss. Or uses the same content in more than one file name, not reusing the texture file. Or, uses a single-color 4k 32 bit image, could be 4 pixels total. The real problem I have is the time it takes to import this into Unity. Otherwise Iâd write some optimizers in Unity, but no kidding 20 hours to import the project, iâm betting I can get that down to under an hour just by reduce/reuse/resize textures. Donât get me started on meshesâŚ
After you have made a build, go into the editor log, and youâll find what the file size of each file in the build is, with the largest files listed first. (Note, you could have multiple builds, so look for the last one in the log).
You can search for the text âbuiltin_extraâ this is usually text that appears before the file list.
Then click on the file in the editor, choose the platform, and set it to crunched. Usually DXT1 for non-transparent images and DXT 5 for transparent works best.
Maybe try fixing that problem at the source and get your artist to deliver sensible data to you.
2 Likes
Your problem is not communicating properly with the artist what is needed from them. If you are getting incorrect assets, the way to fix this is to correct the assets, not post process them afterwards.
Ask for textures exported at the max size you need, if you do not need 4k textures then do not accept them.
If your artist is unable to do this, then you need to help them get the skills needed, or find an alternative artist.
If you are the developer/designer it is important for you to be specific in what you need, leave nothing to imagination. This includes technical details like sizes of textures, formats, etc
there is the free windows power tools which makes batch resizing image files easy to do. If getting content from the internet a lot of times you just got to do some editing, no way around it. but itâs quick and easy so no worries. you can save the resized images as copies in case you want to hold onto the original full res images.
usually i am keeping full size images on a hard drive, not in the game project. I like to keep the game project as lightweight as possible, makes life better.
if using some auto-magical solution, of course do a small test first.
1 Like
Oh, we told him. He insists that providing such large textures is future-proofing his work (will run on higher res headsets the future), and that we should size them according to our current needs. Heâs not wrong, but then it falls on us to do this monkey work. Iâd really like to automate that.
Thanks. I like Thumbs Plus 10 which has a host of batching, as well as thumbnailing, sorting, comparing etc. Itâs not scriptable AFAIK, for that I might turn to Image Magick or Graphics Magick, but then, thatâs my question: has anyone else already done this. Iâd rather buy a wheel than reinvent it.
In a bunch of the examples you describe, yes, he is wrong. A 4 pixel swatch or a gradient exported at 4k is not âfuture-proofingâ, because it will not effect the image output. In some cases input texture resolution and display resolution have little or no relationship, because the limiting factor is human perception, or the data itself just doesnât have high frequency info to warrant the resolution.
I can understand having duplicate textures with different names if theyâre small and have different purposes. That allows stuff to be tweaked without interfering with other stuff.
But making a swatch or gradient 4K when it could be a tiny fraction of that is just wasting resources by storing redundant data.
1 Like
Right, but everything about him you have said and that he has said points to him being very wrong. Nothing about this is future proofing anything, he clearly has a very limited understanding of how to author textures for production. It sounds like he is just parroting something he read or heard from another production pipeline, and it would be correct there but not for your production pipeline.
It falls on you to communicate this clearly, because if not you then who is going to fix the problem you have in your team? Getting some sort of software to try and hide from the problem is not going to fix the issue - your artist needs to work to your needs or what is the point on having them on board? Nip these sort of problems in the bud early or they spiral out of control at later stages in a project.