Hey guys,
I have some serious performance problems with my game and currently have no clue on how to improve that. By using the Profile I found out that rendering is the main reason for the low FPS what was expected. However, according to the stats, culling makes up around 98% of the time it takes to render, while drawing is only about 2%. Is that usual or is this an indication that there is something seriously wrong?
Thanks in advance.
% is meaningless, honestly. It only matters when you have a full game as itās all relative. If it takes up 1 ms and 98% itās because its the only thing doing any workā¦ see? Wait till you have a whole game then you use self ms and ms to track down the expensive functions.
In this case you should sort by self ms and do a deep profile to properly track down the cause of this. If it is a complex project it could be a bug, but please provide more info.
Thanks for your answer. Actually the game is pretty much done, so Iām looking on things to improve in order to have it run more smoothly. Never did a deep profile (didnāt even heard of it yet, Iām still a beginner), so I think this is the next step for me. Despite the lack of information: Do you think such a great difference between culling and drawing is normal?
Iāll get back to this thread when I have more information on the issue.
Yes. Culling can indeed take up a lot more time than drawing. But we still need to see detailed profiler stats and so on to be of any help. How many ms is culling taking up? 16ms in total for scripts or rendering will be the point where it starts to dip below 60fps.
Culling takes up between 10 and 12 ms. Does this value include both, frustum and occlusion culling?
I think so. But 10-12ms for a desktop is large still, what are your system specs and number of cullable objects?
My system is as follows:
Intel Core i7-3610QM CPU @ 2.30 GHz,
8 GB RAM,
Graphics Card: NVIDIA GeForce GTX 660M
Actually itās a pretty strong system, although itās only a laptop.
Is there a convenient way to obtain the number of cullable objects?
Basing on my experience with Unity the past years I would assume that you do something that actively breaks culling, forces it to do extra work or you simply bomb it with too many objects so I hope you donāt mind me asking a few questions to hopefully help you:
- how many drawcalls do you have?
- How many skinned renderers are claimed to be active? (both available in the status overlay of the game view)
- Do you ensure to not dynamically enable and disable objects all the time so culling is able to do its job?
- is dynamic batching enabled in the player settings
- what polygon and triangle count does the status show
- Do you own Unity pro or free
Regarding cullable objects: none that wouldnāt waste even more cpu time as Unity will do the test independent of anything you do.
Its also relevant to mention that the culling is already implemented as optimal as possible, if it rears up like it does on your end then its often related to 1 and 2 above especially but a so called ādynamic occlusion systemā might just as well trash it.
I attached a screenshot of the stats window below. This is pretty much the worst case scenario where the number of objects in the field of view is highest within the scene. Generally I have many objects in the scene but they share a few materials so Unity is able to batch a great share of it. Culling might struggle from it though.
Regarding the other questions:
- Iām not enabling, disabling any objects at runtime
- dynamic batching is enabled
- I own Unity pro
Thanks for trying to help!
No screenshot attached I fear.
I included an image in the post above showing only the stats window. Isnāt it there? I can see it when I look at the thread. It is placed below āCulling might struggle from it though.ā If you canāt see it I messed it up somehow.
Iām adding it below, again. Hope it works.
I do not see the screenshot. Host it with imgur or provide a html link please.
I had to switch to IE to see the screenshot. It may have something to do with the browser cacheā¦I think this is a known glitch in the forums.
Regardless, here is the text from his stats:
Graphics: 11.5fps (87.3 ms)
Main Thread: 87.3 ms Rendrer: 27.6ms
Draw Calls: 1565 Save dby batching: 10404
Tris: 404.6k Verts: 1.8m
Used Textures: 7-6.8 MB
Render Textures: 0-0 B swtiches: 0
Screen: 797-598 - 5.5MB
VRAM usage: 5.5MB to 90.9MB (of 0.86 GB)
VBO Total: 4148 - 78.6 MB
Shadow Casters: 0
Visible Skinned MEshes: 0 Animations: 41
Network (no players connected)
2 Likes
Thanks for your effort! Maybe I shouldāve simply typed these things as you did.
My pleasure. It will be nice when they fix that glitch.
Andā¦as far as your topic itselfā¦to me, Unity DOES seem to spend a lot of time culling. Especially with terrains. But a lot of your items are being batched, so maybe that explains it?
Iām not sure. Right now the whole project seems to be pretty messed up regarding performance.
Another question on that culling stuff: I have some objects that only move in a very simple way. For example I have some robots in my level that are just hovering (moving slightly up and down in a regular interval) to have the environment appear more vivid. As these robots do not move in any other way, I marked them as occludee static. Occlusion works fine, but may this have a negative impact on the performance of culling: to have objects as occludee static although they are a bit moving?
Do you have anything set to static (culling) that shouldnāt be like the skinned meshes?
Thats what I feared, it has nothing to do with culling at all but with the meshes thrown at it.
Simply put: with that many batches it will never work.
It does not matter if you enable static or dynamic batching, it simply will break down.
The next step for you is to reduce the amount of meshes itself that are in the scene, prior any batching.
You can do this either in your modeller or by using the ācombine childrenā script from the āScriptsā package that comes with Unity which you apply to appropriate parent objects to group objects within a given area.
That way no runtime mesh combination will take place and the massive cpu hit you take there will vanish.
PS: you probably cause it yourself too so just to be sure: Never use renderer.material.xxx at runtime, this will clone the material and break batching too.
1 Like
A screenshot would help. What is this, a forest?