How Much Memory Does A Mesh Take?

I’m looking into replacing many of my large textures with 2D meshes. I’m thinking this will save me boat-loads of RAM.

  • A 1024x1024 texture, 32-bit RGBA takes up 5-6MB.
  • How much would a 550 Vertex mesh take?

The mesh uses a basic black transparent diffuse material. No texture whatsoever. I basically want to build a very large level for the iPhone using 50-100 unique objects. If I go with textures, RAM craps out and build size is enormous. I wonder if make 100 unique 550 vertex meshes, would they all fit in under a couple of Megs? I don’t intend to draw more than 10-20 on screen at a time, so draw-calls aren’t a major concern, only memory.

I can get away with drawing ~8000 vertices on the iPhone on screen at any time and still keep 30 fps, right?

For an uncompressed mesh, you’d have at minimum 12 bytes per vertex and 6 bytes per triangle. It’s an additional 12 bytes per vertex for normals, and an additional 8 bytes per vertex for UV info (and more if you have vertex colors or an additional UV set, etc.). However there is mesh compression, so it’s less than that, though I think it varies with the mesh as to how much less exactly. My impression is that it discards some of the float precision for vertices where it’s not necessary.

–Eric

That’s amazingly low.

12 + 6 + 12 + 8 = 38 bytes per vertex triangle X 180 vertices = 6.8 KB for a mesh that I used 1MB of texture for!

Are you sure you’re right though, cause when I examine a 180 vertex mesh’s FBX file, it’s 41KB large. I wonder if that’s how much the iPhone requires to run it in memory, or does it get compressed along the lines you say?

P.S. in case you’re wondering, I was able to reduce the 550 vertex mesh to 180 by simply unifying all normals. x3 more efficient!

FBX files contain massive amounts of metadata that are totally unused when storing actual mesh data in Unity. In the same way that an uncompressed 32-bit RGBA texture always uses 4 bytes per pixel no matter if it was originally a PNG or a huge Photoshop file with dozens of layers. In other words, the source file is irrelevant and unused in the end product.

–Eric

I believe a compressed mesh is identical in memory as to an uncompressed, it merely costs less on disk.

Sure you can but that’s highly dependant on your model - if it is supposed to have hard edges you can’t just start unifying all normals because it won’t work.

Every time you model a hard edge or end up creating uv islands , you will introduce new vertices - there is no way around it.
For instance, you can drastically change # of vertices in your final model by simply recreating your uv maps in a different way without even touching a single vertex.
It may not show up in your 3d app as such but it will in whatever final GPU friendly format you end up exporting to.

Yes, I’m lucky in that my models are all flat 2D cut-outs with a single face. Therefore, I can get away with 1 normal per entire mesh – very handy. Most models are NOT like this and won’t benefit as much from my approach. But hey, it’s a phone and I gotta get creative!

I’m taking paths from Photoshop, exporting them a Illustrator paths, importing them into 3DsMax and creating a flat mesh out of it. My game – which, used to require 100MB+ worth of textures, can be done in under 1MB! That’s x100 optimization.

It’s a bit more work this way, but hopefully I won’t have to worry about performance any longer.

No, the normals are stored in the vertices. So you either have normals for every one, or you don’t use normals at all (which is fine when you don’t need lighting, except Unity is really annoying and gives you a warning message about not having normals when you don’t want them - I’m not quite sure why not importing them is even an option if Unity’s just going to annoy you about it).

Yeah, every vertex still stores it’s own normal, but they’re all parallel, so I don’t have to worry about multiple smoothing groups and duplication of vertices for purposes of split normals.

I didn’t know there was an option for not using normals at all. Where is that set?

Look at the context menu → Import Settings for a given Mesh…similar options exist for other assets like sound (force mono) and textures (mip maps) etc…

I don’t think it’s in the Mesh Importer if you’re not using Unity 3. That’s where it is if you are. :wink:

Edit: Maybe I’m wrong if BoredKoi says that. I honestly don’t remember what options there were when the Import Settings menu item existed.

If you use a shader that doesn’t require normals, then you don’t get any warning messages about that.

–Eric

If only that were true! Not only does the warning message come up, but the normals are even recalculated (or so says the Console). Because what you said was true prior to Unity 3, I assume it’s an issue with the mesh preview in the Inspector. (I have no idea if this means that the normals are used in the build, but that would suck and need to get fixed.)

Go check with Beta 5 (unless you did) when you have time. It probably needs to be reported (and I’ll do that this afternoon if you like).

Sorry, here’s one if you don’t have one lying around. (Some built-in lightmapped shaders probably don’t use normals but I don’t know for sure.)

370167–12828–$no_normals_432.shader (87 Bytes)

Oh, I didn’t know we were talking about Unity 3…yeah, I’d say go ahead and report that. (Most of the particle shaders don’t require normals.)

–Eric

Thanks Jessy, I’ll give that a try. How much performance do I look to gain by not using normals? Would it even be noticeable I wonder.

Hey Jessy, yeah it’s there in the 2.x/1.7 import menu – I’ve been so headsdown on wrapping up a current project I haven’t played with U3 yet as much. I’m stuck in the dark ages! By the way Eric, said project will feature a little Vectrosity action :slight_smile: << more on that later, which I’ll post over in that thread.

Back on topic here, do you guys have comments on turning off the Cast/Receive shadows properties (which are on by default) for the mesh renderers in iPhone projects? I notice when I do that I see changes in my VBO allocation in the Editor Stats window. Since dynamic shadows aren’t part of the iphone equation I never worried about it until now (hyper optimization mode).

I never looked at the stats, actually. I turn them off because

  1. I hate the lies!
  2. If dynamic shadows ever come into play, my games will run worse and won’t look the same. I’ll want to manually enable instead of manually disabling.

Fortunately it’s very easy to make an Editor script to take care of it:

[MenuItem("Custom/Turn Off All Shadows")]
public static void TurnOffAllShadows ()
{		
	foreach (Renderer renderer in Object.FindObjectsOfType(typeof(Renderer)) )
	{
		renderer.castShadows = false;
		renderer.receiveShadows = false;
	}
}

I keep this in a class with some other related utilities, like

[MenuItem("Custom/Turn Off Skin Normals")]
public static void TurnOffSkinNormals ()
{		
	foreach (SkinnedMeshRenderer skin in Object.FindObjectsOfType(typeof(SkinnedMeshRenderer)) )
		skin.skinNormals = false;
}