Unity multiplying my poly count

Target Platforms Mobile
1

While I was building my level geo it was all broken apart, I’ve got about 8K tris. However, now I’m ready to optimize so in my 3D package I combined them into one object and immediatly Unity is reporting that my poly count is 17K tris.

I thought at first it was my history but there is no history or extra data attached to the mesh.

I’ve reimported the mesh into the 3D package and the 3D package still says it’s only 8K tris.

I’ve exported as .ma, .mb, .fbx, and .obj but no matter what Unity is telling me there are twice as many tris as the 3D package.

If I break it up into the smaller pieces again Unity will tell me I’m back down to 8K tris.

If I use the combine children script in unity I get the same result, it all seems to combine well into one mesh with one material, but the poly count goes up to double as soon as I enable script.

Has anybody else seen something similar, this doesn’t really make sense to me, and even if some sort of latent data was attached to the combined mesh (which I’m pretty sure there isn’t) in my 3D package it should be stripped off when exported as an OBJ as that file format doesn’t hold history from the app.

2

Are you using lights?

3

No lights, purely lightmapping.

4

I always have this problem. I get a model – say 500 polys – and import it into unity at around 1k polys.

My work around is to right click the model in the asset manager, select import settings, and then uncheck “calculate normals.” Depending on the model, selecting the UV tangent option will also lower poly count. (Sometimes it will make the model disappear.) I never get the model to what it actually says in C4D, but it gets close. Instead of doubling the poly count, it will do 1.33x or 1.25x – something of the sort.

I should mention that I have no clue what disabling the calculation of normals and enabling the splitting the UV tangent do. I’m assuming there is a quality loss, but from what I can see – the eye can’t detect it.

I know stuff gets tricky with non-contiguous triangles and what not (I, again, have no clue what this stuff means! I just read it and try to interpret it), which I believe are when two triangles aren’t properly connected. This will up poly and vert count.

Also, try using the optimizing function in your 3D application. This can drastically reduce the amount of polys and verts by deleting unnecessary points at a certain threshold.

Hope I helped a bit!

5

500 poly → 1000 poly sounds like you are looking at polygons in the modeller not triangles.
Realtime 3d rendering only has triangles, no quads+ technically

also modeling software actually are total pretenders.
They show you the amount of “virtual vertices and polygons”. They ignore cases where something has to be dublicated for UV / normal splitting (2 different uvs / normals on a vertex → 2 different vertices in realtime but modeling shows it as 1).

Dublication of triangles otherwise only happens if you have a material that requires multipass rendering

6

Thanks gamesurgeon and dreamora, I guess what I’m getting is the splitting of vertices for the normals and UVs so I’ll look into that.

However, here’s the rub, my surfaces are all hard and don’t have any smoothing across edges so there shouldn’t be any reason for it to be using multiple normals per vertex to smooth across polys.

But really it shouldn’t be for the UVs either because when the geo is smaller chunks it isn’t increasing my poly count and if I combine all the pieces into one poly object but don’t “merge” any vertices I really don’t see any reason why unity should be trying to split UVs either as all the previously small pieces are still their own “poly shell.”

So I’ll look into my normals and UVs but considering what I’ve said here can you think of any other things I could be messing up to cause the increased poly count?

P.S. I am indeed counting tris and not “poly faces”, so it’s not the triangulation.

7

The hard edges explain it. You have it the wrong way around: It is hard edges that require multiple normals per vertex (as a vertex needs one different normal for each connected triangle), whereas smooth surfaces can share normals per vertex (as each vertex uses the average normal of all connected triangles).

8

Let me elaborate just a bit, my surfaces are all flat, if there is an angle, say 90 degrees, that is where I’ve got seperate surface, when I combine it into one there will be one poly object but I’m not merging the vertices so the poly shells remain seperate, since they aren’t merged together there shouldn’t be any splitting of vertices right?

So pretty much every single poly shell is totally planar. This is why it’s so curious to me as to why the poly count is going up. Whether I have many planar poly objects or many planar poly shells in one poly object to me it seems like the poly data should be the same for unity, I’d just like to get rid of the extra data for keeping many transforms, renderers, etc.

9

you couldn’t combine the vertices on the edge even if you wanted, they will remain seperate for rendering due to the hard edge.
the same would be true if you have a UV seam on the surface. UV seams like “light seams” mean that you will get split vertices.
the polygon count though should not be affected in this case.

if its only the polycount for example that goes up then its commonly really a matter of your modeler not giving you triangle data but quad, n-gon data

its close to granted that statistics from modelers fail to remain correct on a realtime environment that has to process the data for realtime handling instead in an efficient way. You should only use the data in the modeler as a guideline.

10

Thanks Dreamora, I’m happy to say I’m following you, almost completely, perhaps with one more question/example I can get my IQ up one more notch and follow you completely. I’ve done a VERY simple test with just a cube.

STAGE 1: first image
I create a cube in the modeler which as expected reports it at 12 tris and 8 vertices, which is of course incorrect for what will happen real time.

In Unity it is 32 tris, 24 verts. I expect the triple vert count because each vertex shares three faces, so I follow, but to me this should still only make 12 tries, but please continue. Because here is where it gets interesting.

STAGE 2: second image
In the modeler I separate each of the sides of the cube to it’s own poly object so that now I have six separate objects, I even move them out a bit so that each side of the cube does not touch any other side. The modeler now also says 24 verts (because they are definitely separated) and it says 12 tris.

Now, Unity matches exactly as well, 12 tris and 24 vertices. This completely makes sense to me! JOY! The problem is now I’ve got 6 objects with transforms and renderers, etc. So now that the modeler and Unity match why not put them under one transform by combining?? But wait, my troubles are about to return.

STAGE 3: third image
In the modeler I combine the poly objects into one object, they are still separated in space and I have not merged any vertices, they are several poly shells under one transform. Modeler still says 12 tris and 24 verts.

Unity now goes back up to 36 tris and 24 verts. boo :frowning:

So why for the love is the poly count going up just by combining separated poly shells, I have not tried to combine vertices or UVs, there has been no change to the normals, they are just as broken up as when each shell had it’s own transform. I would still expect this to be 12 tris in Unity so this is where my understand breaks down and I would be eternally greatful for a more thorough understanding as to why this happens because I can’t optimize my geo if what seems like it should help to me actually more than doubles my poly count. :x

321056--11327--$screen_shot_2010_06_03_at_41739_pm_193.png
321056--11328--$screen_shot_2010_06_03_at_42003_pm_174.png
321056--11329--$screen_shot_2010_06_03_at_42011_pm_111.png

11

There’s a video from Adam Mechtley (of Unity iPhone game Touch KO) on the autodesk site here. Not only is it an excellent talk on optimizing for the iPhone, but he talks a lot about the issues you’re having here, so it could be worth watching.

12

Thanks Murcho, that’s an excellent video, and really reiterates well what dreamora was explaining.

What it sounds like is that I’ll be keeping my level as the separated pieces as it sounds better to let Unity batch together what it needs instead of me minimizing the number of transforms but having Unity draw extra polys/verts, so this basically solves my problem.

As far as the extra tris/verts, it was definitely happening in the “stripify” process but it still seems odd to me that the exact same geo/verts/uvs would create a different result just because they’ve been combined under one transform.

Thanks to all for the help, and I recommend anybody reading this thread to check out that video, it’s really great.

13

The link for the video doesn’t work anymore. My search for that video was unsuccessful … hopefully someone can find it somewhere.

14

its because of UVs and hard edges.
I can recommend the book “Creating Game Art for the iPhone with Unity” from wes McDermont, aka 3dninja.
He is explaining this and other things very good and made also videos.

15

Any news about the video of Adam Mechtley that Murcho recommends ? can’t find it anywhere either.

16

I think it is this one: http://video.unity3d.com/video/3274807/unite-09-optimizing-for

17

Thanks, I’ll check that out.

18

I realize this is an old thread… but one reason you would get more vertices in Unity, is due to the hard edges on your cube. The way a game engine works with a hard edge, is that it has to duplicate the vertex normals along the hard edge… and to do that it creates more vertices (i.e. it “splits” the vertices)

If you were to take your original cube, grab all the edges and smooth them (so each vertex has only one shared normal) you should see a decrease in vertex count.