koobas.hobune.stream
Calc tris and verts pr. frame in webplayer
Hi there, I have some people who says parts of a level is slowing the FPS down. As the users can build the levels themselfs, I would like to examine the FPS and verts/tris in certain areas/levels.
I have a FPS running now, but how do I calculate the verts/tris run-time in a scene?
I cant find anything in script reference, so I guess its gotta be manually somehow. Is it "for each child gameobject in scene, calc verts/tris and check every child within too recursively" ?
if so, where do I find the verts and tris?
The Mesh-class has all you need. Every mesh is made up of vertices and triangles. With Mesh.vertexCount you can get the vertex count of this Mesh. The triangle count can only be queried by reading the length of the Mesh.triangles array and divide it by 3.
To get the overall vertex / triangle count in the scene just use this:
// C#:
int vertices = 0;
int tris = 0;
MeshFilter[] allMeshFilters = (MeshFilter[])FindObjectsOfType(typeof(MeshFilter));
SkinnedMeshRenderer[] allSkinnedMeshes = (SkinnedMeshRenderer[])FindObjectsOfType(typeof(SkinnedMeshRenderer));
foreach(MeshFilter MF in allMeshFilters)
{
vertices += MF.sharedMesh.vertexCount;
tris += MF.sharedMesh.triangles.Length / 3;
}
foreach(SkinnedMeshRenderer SMR in allSkinnedMeshes)
{
vertices += SMR.sharedMesh.vertexCount;
tris += SMR.sharedMesh.triangles.Length / 3;
}
Debug.Log("Vertex count: " + vertices + " triangle count:" + tris);
awesome! I found another script that did some calculations too, but it doesnt count all my dualsided alpha leafs I think or something else, because the editor shows one thing and the counter another... strange! Will try this one now. Thanks!
still get different stats from the view inside the editor and then this script. any clues to why?
Well, the statistics in the editor are the true vertices and tris that are send to the graphics-device. Frustum-culling and occlusion culling will reduce the vert / tris count. On the other hand there are some things you almost can't track: the GUI!
Every GUI element have at least one drawcall, a button usually have two, one for the background-image and one for the text / image.
There are even other things that causes draw-calls like particles, cloth, GUITextures...
I'm not sure what you want to achieve? The vertex or tris count doesn't say anything about performance. Draw calls are the real problem. If Unity can batch a lot stuff into just a few drawcalls you can have millions of vertices. Also very important is what shaders you're using. If you have a bad combination of transparent shaders you will have a high fillrate (due to many overdraws)
drawcalls? batch... oh crap! I have around 500 drawcalls because our world is build up of small instatiated objects that grouped with a section parent.
yes, we have some bad(expensive) dual-sided alpha planes used for leafs on trees. Have thought of doing them as a "face the cam" plane ins$$anonymous$$d and reducing the numbers.
