When I run my game on the iPhone, the vertex count shown by the profiler seems to be about double what the actual vertex count of the objects on screen should be. Any ideas what might be causing this?
What sort of materials are you using?
All materials are vertexlit or transparent/vertexlit in the case of alpha blended textures.
Try changing the import settings for whether normals are calculated, and also realize that if your model’s UVs aren’t continuous, then you’ll get vertex duplication along the UV seams. In other words, if you have a box the UVs of which are all adjacent/continuous, you’ll wind up with just 8 vertices. But if you make it so that each face of the cube draws from a different part of the texture that is not connected to the adjacent part, then new vertices are generated for each face.
Ok, the objects in question are using baked textures to avoid having multiple materials assigned to the object, so the UVs are almost certainly not continuous. Is there any other way to optimize such objects? Oh, and thanks for all the replies!
Hmmm… not that I know of. However, you should be able to bake textures so that the UVs can be continuous. Just make sure you have continuous UV mapping before you perform your texture bake. At least, that’s what I do in Cheetah. I can’t speak for your particular modeler.
I’m using Cheetah as well, but I’ve been relying on the UVs generated by the texture baking instead of unwrapping the UVs myself. I’ll have to try manually unwrapping and see if that helps.
Try using the UV mapper tool. Then use something like spherical or cubic UV mapping to have it automatically generate the UV coordinates for the object. Make sure you write those coordinates to the correct UV set, then do a bake. That should generate continuous UVs. Though it’s possible an automatic UV generation like that may not work in your case, but if your object is pretty much convex, one of those UV mapper modes should work for you.
Automatic unwrappers are usually very wasteful of texture space, you’re best of manually UV unwrapping pieces of your object, letting the software pack it, then fixing the pack yourself…
UV mapping is not likely to double the number of vertices, but flat shading most certainly will.
Your vertices will be split if there is a uv seam, a material seam and if your material lighting requires “hard” transitions.
There is no such thing as “flat” shading using face normals anymore; all data resides in the vertices, so even within one material, if you need a hard edge, those vertices are duplicated so light calculations don’t smooth the transitions.
Why are you concerned about this? On modern graphics cards, anything under 500 vertices makes absolutely no difference in performance. I don’t know what the numbers are on the iPhone (obviously much less), but I doubt it is going to present a real performance problem.
The real issue on iphone is the draw call limitations. As long as you are rendering one mesh, you will have one draw call; so try reducing the number of meshes you send to the renderer before you optimize vertex data.
Actually, certain lights, certain material methods etc, will result in additional drawcalls.
The unity manual goes to some lengths to suggest you limit vertex’s to less than 10,000…
That’s not a great deal 
If you are really worried about not creating any additional vertices, then you are going to have a hard time making a modern 3d game.
If you need 10K original, untouched verts, then you will need a very primitive texture map, 1 material, and smooth shading. But, like I said, I really doubt the vertex limit is going to play as large a role as draw calls and, object overhead, and skinning calculations to name a few.
What game do you imagine is not going to be limited by draw calls, but cannot afford to duplicate vertex data?
Ah… just saw that you said shading can increase draw calls; of course it can. But that doesn’t change the definition of a draw call: sending a mesh to the renderer. Same in openGL as in DirectX … are you suggesting this is not the definition of what a draw call is??
my point is simply this: I wonder why the original poster is concerned with vertex duplication on a system that is bottlenecked primarily by draw calls.
The reason I began to suspect the vertex count was the information I was getting from the internal profiler. Here is a typical sample while my game is running:
----------------------------------------
iPhone Unity internal profiler stats:
cpu-player> min: 0.5 max: 10.3 avg: 6.0
cpu-ogles-drv> min: 12.5 max: 18.2 avg: 15.8
cpu-present> min: 19.3 max: 23.4 avg: 21.5
frametime> min: 48.2 max: 51.8 avg: 50.0
draw-call #> min: 7 max: 7 avg: 7
tris #> min: 8093 max: 8093 avg: 8093
verts #> min: 8107 max: 8107 avg: 8107
player-detail> physx: 0.9 animation: 0.1 skinning: 0.0 render: 3.9 fixed-update-count: 2 .. 3
mono-scripts> update: 0.6 fixedUpdate: 0.0 coroutines: 0.0
mono-memory> used heap: 188416 allocated heap: 356352
As you can see, despite the low draw-call count, overall frametime is really bad which made me consider the vertex count as a possible reason.
I wouldn’t say the iPhone is primarily bottlenecked by drawcalls. I would say that both draw calls AND vertices are a significant bottleneck. Even with a tiny number of draw calls, a mesh of 10k verts is going to be pushing the edge on the iPhone. If your mesh is only 5k verts, and you still need a few more objects in-scene, then a duplication resulting in 10k verts is definitely going to cause problems, so he’s perfectly justified worrying about vertex duplication. If his objects were only quads or something, then it might be a different story.
JTBentley, actually, what you want to do in Cheetah is automatically unwrap the UVs, then rescale it the way that makes the most sense for the job, but the automatic unwrapping will at least get rid of lots of seams that may be there. That’s my reason for recommending that first. Depending on the mode used, however, it can still lead to seams, but it’s worth a try.
Oh, another thing I forgot to mention: in Cheetah specifically, the default UV unwrapping does create lots of seams, which is why I recommend using the UV mapper tool to apply spherical, cubic, etc, mapping to the object. Then scale appropriately.
I’ve attached the UV map of one of the objects I’m currently using. As you can see, even with just the one piece, I’m witnessing a doubling up of the vertices in Unity.
170451–6138–$meteoruvs_155.pdf (7.39 KB)
Hmmm… looks like it’s pretty well optimized as far as seams go. You’re going to get duplication on the seams, but that’s not going to be too much, and that’s unavoidable. Try setting the import settings to recalculate normals.
Yes, if your limit is 10k, obviously anything that puts you near or over 10k is going to be a concern. So, I’ll go ahead and assume the game requires such a high resolution mesh, and the problem at hand is tracking down generated vertices (although, this is a requirement that should be seriously questioned in the design phase).
The places I know of are:
-
map seams or separated multiple textures (not using uv sets) where the uv data must be duplicated (but this is very rare in my experience)
-
material seams where the mesh itself is actually split, resulting in 1 mesh / matl
-
hard-lit edges where vertex normals are used to simulate face normals
It looks like you guys have ruled out uv map seams, and if I remember correctly have tried it with a single material. Go ahead and smooth your normals from within your modeling tool and see if that makes a difference.
A single material, simple uv, soft-edged export must produce a mesh with very nearly the same number of vertices as the original.
the stats are not really correct.
for each material on a mesh, the stats will output another time the full amount of vertices and triangles on that object, even though only the geometry related to that material is beeing drawn.
the only thing that should raise is the draw call amount.
the only thing that really can double the geometry is lights in pixel mode because the iphone has no pixel lighting and the fallback kicks in there
That’s why I’m baffled by the stats. The object only has one material on it, and the two lights in the scene are vertex lights.