My team and I have just created our first complex map and we are having troubles with optimization.
The artist made the map in a modullar way, I think too much modullar because the map is composed at least by 2k objects.
In the editor the load time of that scene from the main menu is short (around 3s) but in a build the scene load time is about 40s !! it is unacceptable for a multiplayer online game with short matches.
so, I think the artist have to make the map in another way because the 2k objects is increasing the scene load time a lot and dropping the FPS.
Is that the way? or may I can do something to reduce that time as a programmer?
That 2k more or less modular objectss (all have a renderer) and lights, I disabled all but the walls and duplicated all the walls like 5 times to reach the number of all objects and it is lasting more or less like before (3~4s in editor 40~s in build)
You need to provide more information on what type of objects are in your scene, how many vertices are used by the all the meshes, and any code that might be using reflection or loops inside any of the functions Unity calls.
Thanks for your answers, I’ll take a closer look but there is only one background sound, no plugins and the common PBR shader, in textures we use 4K and 2K textures.
There are 3 reflection probes in the scene but they are not active.
There isn’t any code in the scene, is only a map where I spawn the players that in other map works perfect and fast.
How do you check how many vertices are used in a unityScene?
I believe you can click and enable the “Stats” button when using the “Game” view in the Unity editor. It will display the total number of “Tris”(triangles) and “Verts”(vertices) if you zoom the camera out to encompass the entire scene. My guess is an over abundance of 4K and 2K textures if there are no scripts in the scene. It would also be helpful if you provide a picture of the scene view, the number of textures, the total file size of the client folder after building, the target build platform, the specs of the system you’re running the build on, and the current version of Unity3D that you are using.
Ok, here is the Stats view if I align a camera in a view where I can see all the scene
but when I’m playing looks like this
I don’t understand anything It is supposed that our artist used low poly and the player is inside a room so… I don’t know how unity is rendering 11.1M tris, he is in a room not seeing all the map, I suppose that unity doesn’t use oclussion culling and frustum culling automatically right?
EDIT: I have 1970 Gameobjects (counted them by script) and our wall modules for example Have 86 verts, I don’t know how is rendering 15M verts because that means 7.614 verts per Object in average :/.
I’ve counted the number of vertex by script of all gameobjects and the is 1.7M vertex (counting all the gameobjects.sharedMesh.vertexCount), I don’t know how Unity reach the 15M.
I know now what happens, if I deactivate the lights It goes down to 1.7M vertex but with lights it raise to 15M
Unity automatically culls objects that are not in view. I wanted the total vertex count to see how many vertices you are trying to load at run time. Please provide the rest of the information I requested.
Unity 5.4’s new deep memory debugger in the profiler can tell you exactly what is being loaded into memory and how much memory it is taking. Should be able to work out problem area’s from there
I had an issue with thing’s being loaded into memory that didn’t need to be in the build at all. Fixed the issue by tagging them OnlyInEditor before doing a build
To improve my loading times, when my level is saved in the editor, a script removes all meshes and meshrenderers and saves the meshes and the gameobject’s name to a serializableDictionary in a ScriptableObject.
When I load my game, I use a mesh combiner to combine all the meshes stored in the dictionary, using the gameobjects transform scales rotations and positions. Also to prevent any objects from popping up, I have my camera fade in to the level.
I should add that my game is 2d, and that you might not want to do this if you want to combine every mesh together if you plan to use occlusion culling. You could combine small portions of meshes that are in the same place
Modular scenes are a GOOD thing. You actually, on big projects, don’t want to have 10 million tri’s combined to a single object. This will prevent you from taking advantage of occlusion culling although it will benefit your draw calls (batches).
There are a bunch of ways to optimize this, and as mentioned above, some issues you need to consider. Generally speaking, breaking your level up into smaller chunks and bringing them in through LoadLevelAdditiveAsync is a good way to go for faster loading.
Then you can load say, only a Cube first (think : immediate load) then lazy load the rest of the scene in at a reduced LOD (think reduced simplified meshes) and let the system up the mesh count slowly. You can also use this to take advantage of GI and light baking, so it doesn’t have to rebake the entire background level for example, if you are re-using it through 50 scenes.
That said, the second issue you are going to run into quickly is your FPS. Generally speaking, you want to aim for around 1.5 million tri’s and 2,500 batches at most on desktop (this is where I’ve found the sweet spot to be on VR anyway). Vive excluded, it has some bad SteamVR stuff that needs to be optimized in their camera loops if you want to push that much to their minimum spec systems (nested, iterative, GetComponent calls per frame, just bad design - but I digress).
I don’t know what happens
