Confusion about results from CombineMesh

Unity Engine
1

I’m working on some code that generates a plane by instantiating smaller plane prefabs in a 50x50 grid. I then roll these 50^2 prefabs up into a parent GameObject for organizational sanity. I ran this simulation and ended up with 178 draw calls and 2443 batched calls that was running between 65-70 FPS in the editor.

In an effort to improve this I figured I would run CombineMesh on all the small planes since they were all instantiated from the same prefab. This got me down to 5 draw calls with 0 batched.

Here’s where my confusion lies. 1) I have nothing else in the scene except a few management GameObjects so why isn’t my draw call count 1? 2) Why is the editor still telling me I’m running at the exact same framerate (fluctuating between 65 and 70) despite my draw calls being lower? 3) In general I feel like I should be getting better than 65 FPS since there is nothing else in the scene (in total its 5.1k tris, 10.1k verts).

2

I think the editor’s FPS might be capped. I noticed this too with an idea I was tinkering around with. I’m not sure how to ‘un-cap’ it though.

3

A little off topic but if you can combine the mesh why not just create one plane?

4

The best way to test FPS is in the built game. There are a few scripts around for checking the FPS. Some games that run around 70 in my editor run around 700 or higher in the build. Depends on your PCpower.

5

Eventually each “tile” could have a different material so my goal down the line is to run CombineMesh on groups of tiles that use the same material. This seemed easier than trying to do a single plane and manage all the UV coordinates over a texture atlas.

Curiously though - if textures are atlassed and therefore batched into the same draw call is there an advantage to running CombineMesh at that point? Is a single draw call more efficient than 1000 batched ones for example?

So it seems FPS stats are not accurate in the editor - this is a relief as I wasn’t sure, at this point, where else I could get a performance gain.

6

  1. FPS has nothing to do with framerates. Actually when you combine it like that the framerate on a more limited GPU will dip, same goes for ATI on OSX where ‘high poly models’ are deadly due to a problem in the drivers.
    What you are actually doing with your mass combine is that you force the whole thing to be rendered even if only 1 edge is in view

  2. If dynamic batching batched already that much then it implies that the rest is either not batchable (each material is an own drawcall no matter how you do it) or that it didn’t make sense to be batched (transparent materials must NOT be batched as they will not correctly depth sort otherwise)

  3. perhaps you have too many polygons. a single mesh can at max have 60k triangles and 60k vertices

7

Interesting points - hadn’t even occurred to me. Thanks dreamora. So it would seem that CombineMesh is definitely not the way to go and just atlassing as many textures as I can should do the trick.

Polygon count shouldn’t have been an issue with this simulation since the 50x50 grid came out to 5k triangles and 10k verts according to the stats readout.

8

I don’t mean to rez my own thread but this is nuts. Still working on a tiled grid and was concerned because initial generation was taking a long time. Just out of curiosity I did a build to see what the standalone would do. What takes 66-70 seconds in the editor takes 4-4.5 seconds in a standalone build.

I knew there would be a discrepancy but I never would have thought it would have been this bad. Word to the wise folks - don’t base your optimization worries on what happens in the editor.

9

Looks like this is not a big issue given your last post, but the answer is sometimes yes. It costs (CPU) to batch things, if you have one object with lots of verts it will get rejected early in the batching process.

But as Dreamora said, this is only true if you generally see most if not all of the meshes at one time. Combining them forces everything to be drawn if any of the mesh is visible.

Also many other factors … best bet is to experiment within the scope of your requirements.