Our team has just finished designing a scene in Unity, and its looking quite swell!
But the problem is that it is incredibly unstable, has thousands of draw-calls and therefor runs poorly.
Using the profiler, I have noticed that Camera.Render, and WaitForTargetFPS is the badguys, taking sometimes up to 80% of the CPU usage.
I have little, almost to none experience of this stuff. We’re on a deadline, so even if you don’t know the answer, a hint or guess would make perfect! Here is a screenshot of the profiler : Screenshot - 0abeaf3555d192251ffdf386476796d0 - Gyazo
I dont have pro, so I’m not familiar with the profiler but I would say that WaitForTargetFPS is caused by vSync ( propably set to sync every second blank from the looks of you screenshot). What target platform do you have? mobile?
Generell rules are:
Try to use as few unique Materials as possible.
combine meshes
Atlas your textures
Occlusion Culling
Alright! Our platform is Windows so far. We have indeed used a lot of different materials, so we’ve got to look into that for sure!
Thank you element_wsc
Please remember too that the editor monitor is a rough estimate and you usually are going to be a little faster in a full build. It also looks like your shadow caster count is a little high.
WaitForTargetFPS is just how they name the idle state of the main loop (sleep() function in C) so that it doesn’t suck up all the CPU power availble on your machine. It just means that you have some free calculation space remaining per frame.
You’re probably just having too many draw calls as you said but hard to tell exactly with just the screenshot (plus I haven’t had my hands on pro for a while :/)
Aren’t you having bug lag spikes on GC Collect ? If that is a visible problem, then search for “new” with notepad++ or whatever soft on your script folder and revamp your code to make sure you put all thoose in Start() or Awake().
Yeah, it runs a bit smoother when I build it. But its still a BIG problem, since my computer is really good, and even my pc is having trouble running it :S
We’re aiming pretty high with this game, so we’d like everyone to be able to play it… If you catch my drift
Yeah the shadow casters are a bit high. So basically, I have to go in manually and shorten the amount as much as I can? I’ll look into it
Thanks for the post!
Draw calls wise, I’d say you’re actually OK - I’m at around that number and my game runs smoothly enough on a GeForce 8800. It never hurts to decrease it but it’s not what I’d focus on.
The shadow caster count looks insane. Assuming that most things in your scene don’t move, you should use lightmapping to prerender their shadows. That’ll decrease the shadow caster count, and also lower the polygon count from 1.4M (which is about double what it should be).
I find it quite weird that I have so many shadow casters, since I have lightmapped the whole scene except the “pickable” objects.
Here’s an screenshot of the actual scene if you’re interested: http://gyazo.com/44acacf5a7ae2db84b673a3eec32920e
Yeah… We maybe underestimated the polygon counts while modeling :SSS Is there a mesh “extruder” in Unity?
Thanks for the help as always!
Well, if you’re already lightmapping and you’ve marked most objects as Static, then the number of shadow casters is definitely very strange. What’s your shadow distance (in Edit → Project Settings → Quality Settings) ?
It would help if you show another profiler screenshot with the Camera.Render line expanded down a couple of steps, so we can see exactly which parts of Camera.Render are taking the time.
Did you setup occlusion culling ? That will reduce the amount of verts by “hiding” what is not visible.
GC is short for garbage collector, the part of the system that manages memory for you, except it comes at a cost and it can be too high in some cases I won’t explain for the sake of simplicity, causing regular lag pikes. You see it in the profiler when you look up frames where the FPS rate drops and it appear in the script list as GC.Collect(). If this is a problem for you app (maybe it isn’t, you have to check) then the solution is to get rid of object instanciation in update loops by either using an object pool manager or instanciating everything in advance in the Start() methods.
Another thing I noticed, you have many particles draw calls, do you use shuriken or legacy ? (Shuriken is supposed to be faster)
ps: did you try to use the built-in mesh optimize setting ? If this is not enough, I happened to stumble once on some asset in the store that seemed to be good at it, might be worth checking…
I tried occlusion culling, but because I have a “waking up” animation on my camera, the setting gets confused and removes things INFRONT of the camera (like the roof for example) I’ve tried some settings and it doesn’t seem to work that well.
I’ll check into the other settings and see if I can do something.
hm weird it shouldn’t remove the things you’re supposed to see, otherwise there is no point in it xD Did you try changing the grid thing to various size ? (again sorry I haven’t had a pro for over a year now so it’s been a while since I used this stuff, maybe it did change).
It seems you have quite a few lights on on the profiler screenshot, I thought you lightmapped you scene ? Maybe you should use light probes but I have never used it so I can’t help with how to…
hmmm, now that I think about it, I think we added some lights again just for the shadow for the pickable, not lightmapped objects. We would still like shadows for the mobile objects, how can I achieve that? Does lightprobes cast shadows?
Lightprobes don’t cast shadows; they alter the per-vertex lighting calculations to include lightmapped light.
Looks like you’re using the Deferred lighting pipeline. 62 lights shouldn’t be an issue for that pipeline, but 62 shadowcasting lights will be. I’d start by turning off shadows for as many lights as possible.
Next I’d look at the Shadow Distance setting in the Quality Settings - I can’t remember how it works for point/spot lights but it’s worth a try. You can bring it down to ensure that only shadows closest to the camera are actually rendered.
The other thing you could investigate is to find your most expensive shadowcasters/lights (expand further in the Profiler to see, and look in the right hand pane to see which objects a call is dealing with) and if a particular shadowcasting object is taking a long time to render due to being very high-poly, you could set up a ‘shadow proxy’ for it - a low-poly version, using a shader that only renders as a shadow, in the same position as the high-poly visible mesh (which you turn off shadows for).
Alright guys, sorry for not answering in a while, but anyway I think I found the bad-guy. (even though it was pretty damn obvious almost haha)
It was indeed the lights. I tried to remove all the lights as an experiment to see the difference, and I got over 200fps in the scene. Basically, we have to go through every light source and fiddle with the settings, and reduce the shadow casters with A LOT! Currently we have like 7000 shadow casters, and even though I even have 20 in shadow distance, it still costs greatly on performance. So I’ll add some hours into the schedule haha.
shadow distance will effect point light and camera rendering, so its’ a magic game there…
also, you could try putting them onto a different layer… have a single light source and all casting objects on that layer with objects they need to be casted on.
