too many vertices on import

Hi to all,

I have a 3d model in maya (2009) for my background graphics that counts about 56000 vertices across the whole level.

I import it into Unity (via FBX or via .mb file) and when I test the game the STATS says there are 936000 vertices inside the view frustum.

I think there's something wrong. I know imported model have some vertices duplicated due to material/texture change or UV discontinuity but 936000 is too much.

I've tries with maya 2010 too, same result.

Any ideas?

thanks

 

You should read up on splits.

Every shadow casting light you will add, will double your vertex count. Same goes for materials and uvw maps.

Of course, "doubling" is not a completely accurate term due to the way vertices are split.

You can read all about it in this excellent article:

http://www.ericchadwick.com/examples/provost/byf2.html


P.S: make sure you read the first part as well.

 

My geometry does not need any normal for lighting(it is already baked on vertex color) so I export it without normals at all, so there should be any vertex duplication due to normals inconsistency.

I see the resulting vertices (more than 900000) are more than 18 times the real vertices...it sound strange isn't it?

 

only if your models also doesn't come with any textures applied and if you told unity to not generate normals and tangents

these 3 things can cause splits

 

A simple test done on a cube :

- http://a.samavan.com/Unity/Test_TriangleStrip_Cube_A001.jpg

It will help you to understand vertex count depending of your Uvs and soft&hard edges ^_-.

 

Maya (and most other tools) count vertices differently than 3d engines. 3d tools tend to count only vertices which have different position. realtime engines count actual vertex count (which is fed to graphics card), so if you have one vertex and two trianges share it and it has different UVs it counts as two vertices.


I suspect that there is something wrong with your normals or UVs which is causing vertex count to be increased. I hope you're not checking "export normal per plane" (or something like that) checkbox on in the exporter?

 

the same asset works fine with other engines,

in addition, 936000 vertices are far more than if every triangle had its own 3 vertices (1 triangle per strip). There must be some inconsistency in the count displayed.

Even if it counts 936000 vertices the games still runs smoothly at 400 fps...

 

Backface culling = OFF?

 

I counted manually all the vertices imported for every mesh in my background and the total is EXACTLY 1/10th of the number shown in the STATS. It seems to be some bug in unity (even in unity 3) that prints the total number of vertices multiplied per 10 (it says 960K verts while the real number is 96k verts).

 

Have you counted 96K vertices? All of them?

But seriously: could you post a minimal mesh (like a cube) which reproduces this issue?

 

bet it's to do with hard edges, discontinuous uv's, seams or something along those lines.

it's clearly not a bug on unity's part

 

I did not count them one by one obviously....I simply looked at the imported mesh preview (where imported triangles and vertices are listed) and summed all the vertices of all the objects of my background. The sum is 96K.

The STATS in the game windows says 960k vertices instead. If I reduce the vertices to 80K, the STATS says 800K, it's clearly a display bug.

I have no per-pixel light, nor the background mesh is lit (it's per vertex pre-lit), I don't have projectors or nothing else that could raise vertex count at runtime.

Moreover if I actually had 960k vertices they should take a huge amount of ram but they don't.

here is a screen grab of one of the 7 objects in my background (they are all very similar in complexity)

 

Sorry, but I can't reproduce it locally. It works just fine for me. Checked the code too, there is no obvious problem.

Number of vertices in stats it's not just a number of vertices in the scene - it is a number of vertices fed to graphics card, for example if you have multi pass shader it has to feed vertices to graphics card several times. There is a number or factors like this which can increase your vertex count.

Just try dropping your mesh into new project and new scene without any shaders (i.e. with default one) and see if you get the number that you're expected. If not, then submit a bug with your mesh attached.

 

You should provide FBX or something if you want help and answer to your questions.
PM or on the forum, up to you

 

Here: http://dl.dropbox.com/u/2826000/Dungeon2.rar

can be downloaded the FBX of the model I've shown you in my last post.

it is imported with about 18900 verts but the STATS reports about 322000

any help or idea will be appreciated,

thanks in advance.

 

Imported fine for me.

20248 verts, 16676 tris, 23 submeshes

 

ok but try dropping it into a scene, what your camera STATS says?

 

404.8k vertices in forward, 809.5k in deferred. Depending on which rendering method is used, and around 23ish draw calls or 40ish in deferred. It's because you've got a single model with a ton of different materials that's causing it. Cause it has to redraw the model everytime for each material, as well as splitting vertices for hard edges, so while that's all well and good, it means it's also redrawing other parts of the model too. Basically it's drawing it over and over, the whole thing, all them vertices, give or take a few draw calls for other things, and extra or fewer vertices for hard edges and so on (so you don't bother getting a calculator out to try prove it wrong, just trust me on it).

It's a moot point anyway, cause you need to split this model up, as it stands you can't lightmap it properly, and it can't benefit whatsoever from occlusion culling. It's quite possible to split the model up in MAX and then save the scene as a single .fbx file but with separate objects within the .fbx. You'll be glad you did.

Other than that though, it's a great model and I'll be interested to see the final result!

 

404K verts are about 21 times the original one...it's like unity is trying to redraw all 21 times. I sounds strange to me.
I'd like to point out that is not my first aproach to a 3d engine. I've already programmed a couple of (lesser) commercial titles and I've never had this problem both with home-made engines or commercial ones.

The model I've posted doesn't have "a ton of different materials" it has just 23 (you can check it by importing it in a 3d modeller like maya or max).

The same model, used with another commercial engine works fine with the right number of vertices (about 19k). I'm having this problem only with unity (with 2.6, and now with 3.0).

If you open the FBX in maxor maya you can see it has about 10k "unique" verts. Importing it into unity gives 19k verts due to uv discontinuity, different materials and so on.....split, split, split......ok, 19k is a feasible number.

I've already pointed out that my model is pre-lit with baked vertex color, so I don't need per pixel light. What I can't understand is why the renderer is trying to push 404k verts into the graphic hardware to render this quite simple model.

The model has 16676 triangles. Even if the unity stripper tried to make 16676 "one-triangle" strips (in the worst case) I would get 16676*3 (verts per triangle) = 50028 vertices that are far less that 404k!

With the whole background scene (7 object similar to the one I've posted) unity tells me it renders 2.0 millions of vertices but the game runs smoothly at more than 200 fps on a medium pc. I think 2 millions of vertices are really heavy to pass to the hardware; just think a vertex as 3 floats + 1 vertex color+ uv (no normals) 12+2+8 = 22 bytes per vertices ---> 44 megs of data transfer!!! It sounds impossible to me.

Just think the same background model runs smoothly on a psp at 60 fps with all the game logic. There must be something weird that alter that STATS vertex number.

 

galadhrim, you might be right (I love persistent users with strong opinions ) it looks like it renders many submeshes (as much as you have materials) and it adds almost all vertices to stats every time. The stats probably should be fixed, but I'll let our rendering programmers do it, because they undersntad better what these vertices in stats supposed to mean. I'll ask them to post the conclusions here.

 

Thank you for your time (and your patience =) ) Paulius, what's important to me is that my game is not going to flood the hardware with tons of vertices. I'll rely on what fbx importer says about them.

If there should be a bug in STATS vertex count, I'm glad to have been useful to find it out.

 

Did you tried to export your level with one material only?

And you will see the difference

 

levels normally don't have 1 material.

 

They're normally not built from one single mesh either.

 

Hey guys, there is no point flaming here. You do your levels they way you prefer.

I think it doesn't matter if it is one mesh or multiple, because one mesh is actually split up into submeshes for rendering, so you actually have the same performance. It just that there is something wrong with stats, which is going to be fixed thanks to galadhrim, because he took his time to report and convince us that there is a bug.

 

Who's flaming, it's pointing out a fact is all, normally levels of high complexity aren't built from one single mesh. Even some of your own peers have said so elsewhere on the forum.

 

You do not understand.

Here are the result of my test with your model of 19260 vtx with the given result in the Unity perf window :

- You original model : 373.3 k vtx
- no vtx color : 340.3 k vtx
- full soft edges : 333.7 k vtx
- one material only : 20.2k


Those test take about 5 min and are the base of debugging thing under an engine.

What I could say is you should separate all object with a different material. (20mat = 20objects)
What could happened is Unity renders your object for each material and doesn't separate the faces by material before rendering.
Then if you have 20 materials on your model it will render the same object 20 times for each materials.
But if you have one material on each parts it will render each "small" part one time with the right vertex count.


Keep us updated once it's done

 

And to be sure it works I did the test :

 

Unity does split up the mesh and renders only subparts, so there is no problem in the rendering. The problem is in stats.

 

And if we separate the object like I done, do you know if it help unity when rendering?
I mean, when Unity separates an object by material dynamically when you have a single object with 20 materials.
Could it be an optimization to do when it comes of iPhone? Or this is really not important?

 

The splitting is done during import time, so there is no performance impact for runtime.

 

OH! didn't know that! Thanks!

 

Hello.

Has this issue been fixed in 3.4? We are using Unity 3.3 and we still have this problem. It is really bothering since it is hard for us to know how to optimize our scenes for iOS because we don't get the correct vertices count.

Thanks