[RELEASED] Better Build Info - An in-depth look at build and assets

Hi guys!

I created a tool to analyse assets’ usage across scenes, resources and other assets - the Better Build Info. The information provided is, as far as I can see, way more detailed and easier to navigate, compared the most popular plug-ins for build log analysis. I put a lot of effort into making the tool sleek, integrated with the editor and easy to use. And it’s only 10$ and just got accepted.

Asset store link: Better Build Info - Report Tool | Utilities Tools | Unity Asset Store

Background:

I work on a fairly big mobile hack’n’slash game - Bladebound (http://bladeboundgame.com, may not have been soft launched in your territory yet). As with every other bigger project I used to work on, tracking down assets’ usage is an immense pain. A pain that seems unavoidable, because you want to keep your build size low.

There are tools out there that analyse the build log to show you which assets get included in a build, some even show you which scene references which asset. However, I found that they still leave most of the dirty work for you, as they don’t tell you why an asset got referenced - is it because it was a resource? Or maybe referenced by a resource? Or maybe used explicitly on a scene? Also, what other assets get pulled into a build along with a prefab? Which prefabs reference a given material? How do I rearrange my sprite atlases to reduce scenes’ memory usage? The list goes on. Also, the most informative of said tools had a rather clunky feel and just didn’t feel quite right.

My team has been using Better Build Info on this project as it got developed and am fairly pleased with how it feels and works. Reports generated from making the build get passed to art and level design folk and they fix oversized assets/scenes themselves.

Demo:

Some screenshots:

Future plans:

I work on new features (collecting even more info about assets, such as texture format etc., unused assets) and cleaning up the code to release an open the source variant. If you’ve got more ideas, let me know!

So, what do you guys think? What would you like to see changed/added? Any suggestions?

5 Likes

Looks great! Can’t wait to test it out.

2 Likes

We’ve tested it in our projects and it works really great! It allowed us to deal much quicker with tracking sizes and cleanup, it’s a really great tool, highly recommended!

3 Likes

Awww yeah, Better Build Info has been featured and is on the front page :slight_smile:

No time for celebration yet, since the feature I’ve been working on needs some polishing and final decisions to be made. It’s called “extra info” and what it basically does is collects detailed information per asset type. You can then sort/filter by said properties, just like by path, size, category etc. Extremely useful in case of textures.

So far, the info I’m collecting (based mostly on the requirements of the project I’m working on):

  • scene: game objects count, components count, static mesh vertex format, vertex & primitive count
  • prefab: game objects count, components count
  • model: vertex, primitive & blend shapes count, vertex format, optimize flag, generate uv2 flag
  • texture: format, mipmaps, width, height
  • audio: frequency, length, channels, load type

Is there anything else you would find useful?

The new release will take place this week.

1 Like

Hi,
Just purchased this, it’s very cool and useful thanks!
Some questions:
1- What does it mean the total size listed? It’s the sum of what?
For example some fbx report a total size bigger than the size. Same for the fonts.
2-Do Unity embed all dynamic fonts of the same type even if you don’t use it?
Because I have roboto-light, roboto-bold, roboto-italic, etc. But I’m only using one kind in the scene.
3-Are the size displayed actual build size as embedded in the final build, meaning already compressed?
4-Per your experience, can a scene for a mobile game affect the size of the build?
Not talking of the assets included in the scene, but the scene file alone.

Awesome!

I think I explained it in the video, but in hindsight I should’ve included it in a README or maybe provide a tooltip… it is the sum of the asset’s size and sizes all its dependencies; you can basically see how much stuff an asset drag into the build with itself. In case of a fbx it may be imported materials and textures they are using.

I don’t have such test case. Maybe the fonts are in Resources directory? Are there any other assets referencing your fonts?

No, they are uncompressed sizes. In case of Android, I don’t think it is possible to get the compressed size reliably; some assets get embedded in scenes’ files, some are clumped together in sharedassets blobs. Having said that, I guess it would be possible to include the compressed size as an yet another Asset Detail, for assets that seem to live freely in the APK. I’ll check it out.

A scene - no. In our game the largest scene is less then 10 MB, with ~20k Components and ~5 GOs.

However, if your scene count goes in dozens, it is a different story. For us, turning static batching off decreased size of each scene by a few MB. If you have hundreds (or more) of GOs/Components you use for debug purposes only, you might want to remove them in PostProcessScene callback; it saved us ~700 kB per scene.

Nope, they are outside. And the total size also report a bigger size, so if like you explained it’s the sum of the dependencies I guess Unity embed all the variants.

By uncompressed you also mean, the size of the textures is not compressed?
Or just the apk compression?

Thanks for the tips.

Hi,

Does Better Build Info also analyze the usage of the following?

  • DLL
  • Sound (OGG, MP3, WAV, etc.)
  • Fonts
  • Mesh

Thanks

I meant apk compression.

For everything except DLLs - yes, just like any other asset type. Additionally, the tool can store detailed audio clip properties (length, format, channels, etc.) and mesh properties (vertices count, vertex format etc.), like here:

Full DLLs support is coming soon.

2 Likes

Awesome. Thank you for the response. I just purchased Better Build Info after your response.

I am looking forward to seeing the full DLL support hopefully in the near future!

Cheers!

1 Like

The update has been review and accepted. DLLs are now supported.

I also decided to include experimental Unused Assets overlay - see which assets are used and which are not directly in the Project Window.

Let me know what you guys think about it.

Unity 5.5.1p4 Pro

Wow! The new update looks amazing!

The unused assets overlay looks great.

I have a few questions:

  • Many Textures just show the same size of 0.10kB, but they are actually in the Megabytes on disk. Please see the below attached image of this. On the Unity Editor Preview screen and on disk, the sizes are different than what is shown in the Better Build Info. Am I reading this right?

  • The new DLL support looks great so far! How come some dll have the asset path shown, and others don’t? For example, I have 2 dll in my Assets under the same folder, but only 1 of them show the complete path in Better Build, and other dll just shows the filename.

  • Is it possible to show Date Modified column for the asset files? This would be a great feature, especially comparing builds, deployments, etc.

All in all, wow, this tool is amazing!

Thank you

From my experience this may happen if:

  1. texture is a part of a spritesheet
  2. sometimes assets get merged with scenes they’re used on

In both cases, the size Unity reports seems to be related to some sort of asset metadata (just like size of a script).

All the DLLs without full paths you see are the DLLs Unity puts in the build, but doesn’t mention them in the process.

Sounds good! The problem is that AFAIK there are three dates:

  • asset file date
  • .meta file date
  • timeCreated property in the .meta file

I think that the latest of first two will do.

1 Like

Thank you for the detailed explanations.

I am very excited in seeing all the new upcoming greatness for Better Build Info for the forthcoming future!

Awesome

Hey Piotr,

It seems like this is not the case. Somehow the parsing of the textures fails on Unity 5.5.1p4. Possibly the whole 5.5.x branch.
Everything was fine on 5.4, it started showing incorrect sizes for all textures since 5.5 upgrade.
Could it be the new TextureImporter being troublesome?

Tried to debug, however, the confuser does a pretty good job at making the code unreadable after IL decompilation :stuck_out_tongue_winking_eye:

// EDIT

Also, it happens for all the textures inside the build.
If we add a new texure to Resources/ directory (which naturally won’t be referenced by anything), it will be displayed as for example

1 Like

There have been a few API changes in 5.5 and I’m going to submit an update ASAP. However, I unable to reproduce your problems. What platform do you build for?

Also, if running multiple Unity instances, log may become corrupted. Try running Unity from command line with -logFile argument.

Ok, I reproduced it on 5.5.1p4. Unity reports wrong size both in the log and in the internal build report, so there’s little that can be done. Alas, looks like a bug.

As @michal_cwiek_red suggested, size can be estimated by peeking into Library/metadata directory, but there’s no guarantee how accurate this is going to be.

5.5.0f3 works fine.

EDIT: 5.5.2 is also affected. I’ve filed a bug report.

1 Like

Hi! Our team just bought this today and I’ve found it INCREDIBLY helpful! It’s already helped us identify some problem areas in our builds.

However, I’m having a bit of an issue with detecting the total build size. It’s reporting 0.00 kB, and all of the asset categories say NaN% or Infinity%. I’ve attached a screenshot below.

We’re using Unity 5.4.0. Before now, we knew that the problem area likely had something to do with our scenes (the console describes them as taking about 75% of a 20 GB build), which was partially the impetus for me picking this up, to see what is being included in that number. I’ve been trying to make smaller builds with just one or two scenes that were only 1-2 GB in size in case the large build size was the problem, but I was still having this issue even with the smaller builds.

Also, I just realized the screenshot doesn’t show it (I took it as I was heading out the door this afternoon), but I had found a window that showed Scenes were reported as having zero size, which is why I’m thinking they may be connected to all of this.

Any insight into this? (I’m hoping I didn’t just miss a setting somewhere…)

I’m looking into it. Scene size alone should not be a problem, unless we’re approaching 2^64 bytes :slight_smile:

What platform are you building for? Also, could you see any BBI warnings/errors in the console when report was being generated?

In the meantime I will try to reproduce it will artificially big scenes.

I was building for Mac 64-bit.

I don’t have console output here, but I’ll make a couple more builds tomorrow morning/afternoon and check it. I’ll also play around with the scene and see if I can isolate what’s going on. I wouldn’t be surprised if there are crazy shenanigans going on in our scenes.