Resource Checker (FREE) - List Texture/Material/Mesh Memory use in scene

Not even sorry about going necro on this thread - this tool's perfect and I hope more people get a chance to use it.
Thanks for sharing!

 

Absolutely brilliant tool. I was trying to find out where my memory bottleneck was and within 15 minutes I found all the issues and reduced my texture usage by half. So, I went from a game crashing on the Wii U to one that is not only running, but running smoother.

 

I've just discovered this tool. It looks really handy! But most of the textures are showing up as "0k" even when that should be impossible (e.g. a 2048x2048 image with 12 mips).



Any idea what this means?

 

If you're referring to the "Some GameObjects are missing graphical elements" error in the screenshot, here is what I found, while quickly looking through the code.

"Some GameObjects are missing graphical elements" means:

• If a SpriteRenderer has no sprite is assigned.
• If a MeshFilter/SkinnedMeshRenderer has no mesh assigned.
• If a MeshFilter has no MeshRenderer on the same GameObject.
• if a MeshRenderer/SkinnedMeshRenderer has no material.

 

I'm not. I'm referring to the 0k (zero kilobytes) shown for all textures in the screenshot after the top two.

 

The ASTC texture format is just not handled in the code and then it reports 0 KB. Take a look at the GetBitsForPixel method.

 

Aha! That's a pity, but it's also useful, since all my textures should be in ASTC — I need to take a closer look at the ones showing a size!

 

Hi,

I've been working on related texture memory stuff in Unity and thought i'd make a quick update to the code here so that it fully supports the reporting of the correct memory size regardless of format types. It uses the native Unity methods to obtain the memory size via Reflection, the same methods that Unity uses to state the size in the Inspector preview window. As such this should now work correctly regardless of format type ( or changes to types in future by Unity ) and compression, including Crunch.

I've only performed basic testing, but the changes are minor so it should work across platforms from Unity 5.6.7 upwards.

However the original class was written quite some time ago and things have changed greatly in Unity since then. As such this code really requires a full rewrite to address various issues and more robustly deal with all the different texture types. It would also be nice to streamline the code into more classes. So while I can see that some information will be incorrect depending on Texture type ( e.g. mipmap count or getting depth for 3D volume textures ) the actual memory size reported should always be correct as it comes directly from Unity's own native methods.

You can grab the new version from here
https://gist.github.com/noisecrime/2f70b5d4ea827cb5965d38504ad1591c

 

Thanks for that !

I use this tool already ten years and its really nice!



I'm getting some error when calculating:

Material doesn't have a texture property '_MainTex'
UnityEngine.Material:get_mainTexture()
ResourceChecker:CheckResources() (at Assets/1. Okimika/ResourceChecker.cs:868)
ResourceChecker:OnGUI() (at Assets/1. Okimika/ResourceChecker.cs:238)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

 

Can you make the mesh count buttons a bit larger?, the number does not fit in the button in my scene
Or make the table fit to the window width.
See screenshot

 

To make the buttons bigger I changed the width to 100 ( was 50 )
+" GO",GUILayout.Width(100)

 

No problem.

I wont be making fixes to this that don't directly relate to the code change for displaying the native Unity memory size.

As mentioned the original code from github ( 2015 - 2017 ) is pretty old and I can see numerous issues with just the texture aspects, let alone anything else. So at this point I would say its better to rewrite it from scratch than trying to fix issues as they come up. Doing so would also allow you to make a much nicer looking UI too. Its on my to do list since i'm already writing some other Texture profiler utilities, but not sure when I'll find the time.

As for making changes, you're best of doing what you did and changing the code yourself. The code has minor changes from the original so it should be pretty simple to update or just grab my new bits of code and back port to you own version. WinMerge is a great way of comparing two files.

Having siad that I imagine replace line 868 with the following *should* address that error?

Code (CSharp):

1. if ( tMaterial.HasProperty("_MainTex") && tMaterial.mainTexture)

However after a quick mess around I've been unable to cause that error, even creating shaders that don't use a _MainTex. Might be useful to post the shader/material that is causing that problem.

Hope you understand. My main priority with this update was just to address getting reliable memory sizes.

 

Code (CSharp):

1. if ( tMaterial.HasProperty("_MainTex") && tMaterial.mainTexture)

Yes this made the error go way!

Thanks

It happened only when I had "look in behaviour fields" on

Yea don't worry about UI, I fixed the buttons sizes myself.

 

@Noisecrime, I hope you'll consider re-integrating your changes with the latest at handcircus version and submitting a PR. The handcircus one is still being updated — last change just a couple months ago — but still doesn't do memory size calculations your way (and I think your way is more correct). I found integrating your changes to be a little tricky since so many other things have changed since you forked.

Thank you all for your efforts — this is such an incredibly useful tool, especially when developing for resource-constrained systems like Quest.

 

Thank you, great work!

 

Damn this tool is so good for optimization, thank you very much!

 

Cheers dude, thank you for this!

 

Couldn't find which object was using a texture reported by another tool(there was an issue with it), this solved it in like 5 seconds.

 

thanks ! amazing tool using for all my projects

update: i cant build with this.

 

Thank you for your great work. I think it will be useful to avoid scene overload. Given, to work for a mobile game!
On the other hand I have a question, we can know the weight, by decreasing of the objects of the scene, but can see those who are the most gourment and the most important to change (I would say to change necessarily for the necessity of the proper functioning of the game?) thank you

 

Great find, thanks a lot!