How many draw calls should I target for PC

Hi,

I'm currently developing a PC survival horror game in 3D and I'm targetting something around 2K drawcalls with Unity's "beautiful" quality. When doing tests I'm watching at the "SetPass calls" number and not "Batches" in the stats window.
Does 2000-2500 draw calls sounds reasonable for modern games targetting PC ?

I'm quite new to game development so please give me advices or numbers if I'm actually wrong. I'd like a game with very rich graphics but I don't want to overload GPU or CPU.

I'm using Unity 5.

 

For draw calls counts the same as for graphics in general: As much as necessary and as few as possible. Saving drawcalls that doesn't harm quality is a no brainer. The rest depends of the performance. Imho the most important thing is the fps at your target platform.

 

But there's a relationship between fps and drawcalls number no ?
In my tests it seems I stay capped at 60fps.

EDIT: I've noticed that above 2500 draw calls fps drops below 60. That's why I'm targetting 2K drawcalls.
But my PC is not the same as other users I guess. Currently using a GTX 760 Twin Frozr OC as GPU and i5 4670K processor with 8GB ram.

 

The key thing is having options to let people turn down the level of detail and effects. Unless you have a range of hardware to test on, you're working blind anyway - you can make life a lot easier by allowing players to fine tune things for themselves. It's not just draw calls, it's shaders and fill rate and overdraw and post-processing so forth.

It's hard to let go of all the beauty pass stuff, but PC gamers expect options.

 

There are so many combinations of CPUs and GPUs that there simply isn't a real number for this. I would simply aim for a mid-ranged system, which is going to be roughly equivalent to your development system, and offer graphical settings for those who are not on that level of hardware.

You'll want to profile as you develop to determine how you need to adjust your scenes to meet the hardware.

 

Of course. There is also a relationship between number of vertices and fps. As told, the golden rule is as much as necessary but as few as possible.

The usual suspects for example is that everything static with the same material should be one mesh. This means that you may want to create an atlas for some of the graphics to union them into one mesh. Of course just where it makes senes. There is the 65k limit.

VSync is capping here. Have a look at the quality settings, and turn off VSync in the quality setting that you are currently using. That way you get the full fps. Just don't forget to turn vsync back on again ...

 

I find having static objects separate works better for some platforms though. Means Unity's culling system can ignore parts that are out of view.
EDIT: That's probably what you meant by "where it makes sense" (oops! )

 

Thank you for all your comments. This is insightful!

 

Sounds excessive to me, even in a large RPG I never had more than a thousand after optimisation.

 

What kind of optimizations, could you extend please ?

My level is a town in mountains. I've already taken the best advantages of Umbra Occlusion, so my objects are split into sensible pieces (roofs, bars, walls, floors, fences, voltage lines, etc...), but I guess I can combine some object meshes a bit more without loosing occlusion advantage.
The textures are already pretty well atlased.
My terrain is currently not splitted (1000x1000), will do that soon.

Just to be sure, I'm talking about 2K drawcalls in "Fantastic" setting which is quite high in details.

 

How many pixel lights? that will make draw calls go sky high.

 

I used what Unity set by default: 4 pixel lights in Fantastic.
Just noticed my directional light is set on "Realtime". I'm going to do a test in "Mixed" and "Baked" modes to see if it saves some drawcalls.

EDIT: With "Mixed" mode on my directional light the draw calls count drops to 1000-1500 but the shadows are pretty hard, despite the fact I have soft shadows enabled.

 

Batching and material sharing, if you're repeating geometry make sure you have static batching switched on.

http://docs.unity3d.com/460/Documentation/Manual/DrawCallBatching.html

 

So much this. It's also good to test game with computer built using 2-3 years old components. If it can run there, it'll widen the audience.

And frankly, graphics, even for AAA titles had gotten to the point where difference between year old and a months old videogame are hardly noticeable for most people. E.g. I barely see a difference between GTAIV and videos of GTAV (and I'm talking vanilla GTAIV here, ICEnhancer doesn't even run on my machine).

So little downgrade (if you are aiming at AAA level of graphics) so it will run on 2-3 year old PC won't hurt and you'll get more people to play it.

 

Games that don't rely on fidelity last longer than those that do. MineCraft's graphics are impressive as good today as several years ago. An even better example is Chess.

 

This step also works when you develop on such hardware. I am about to do so soon.

 

Well because in massive games, generally they'll use real-time GI (if they use GI at all).. Which doesn't do much for lighting quality, one of the biggest de-limiting factors is how many lightmaps you can stuff into your game ..

 

Well, speaking of lightmaps I realized I had a lot of street light (spot lights) set to realtime lighting. I switched them to "Mixed" mode so I guess I'll have a drawcalls drop once again. Currently baking my scene.

 

I get some crashes with "out of memory" message when baking scene with the following settings:
- Precomputed Realtime GI, Realtime Resolution at 2.
- Baked GI, Baked resolution at 40.
- Baked GI, Baked padding at 2.

Seems it tries to allocate 13GB of memory somewhere near the end of baking but then fails (I have 8GB of RAM, I expanded GI cache size to 100 GB but it doesn't change anything).

Anyone else have this problem ?

EDIT: Retried with lowered settings it baked fine:
- Precomputed Realtime GI, Realtime Resolution at 1.
- Baked GI, Baked resolution at 20.
- Baked GI, Baked padding at 2.

Can a giant reflection probe be the culprit ? I have one that covers the full terrain (1000x1000), may be that...

EDIT2: This is crashing too:
- Precomputed Realtime GI, Realtime Resolution at 1.
- Baked GI, Baked resolution at 40.
- Baked GI, Baked padding at 2.

As soon as I set Baked GI, Baked resolution above 20 it runs into "out of memory" error...

 

Another question: my street lights are currently set to "Mixed", if I switch them to "Baked" only my player and other dynamic objects under these lights will look disconnected from the environment.

I guess the solution there is the use of light probes, but is this of any benefit for large scenes (terrain is 1000x1000) ?

 

I have used lightprobes for a large scene myself, and yes, wherever you can use them, stuff them in!
And I might as well put a sample lightprobe setup here:

By looking closely here:

You can see how I have placed some probes inside the shadowed area, and some around the outside of the shadow.
In the big shot above this one, I also place probes around the middle of the lit areas, so that the entire area is properly covered, of which avoids artifacts.

Just some tips for using lightprobes. Not sure how it would work for a terrain though; try posting a top-down view of your terrain, and I will see what arrangement might suit it.

 

@FuzzyQuills Thank you for clarifying about light probe placement I was in doubt about how to use them.
Sure I'll post a top-down screenshot of my scene when I'll get back home!

For a whole scene, is it better to have just 1 light probe group containing all scene's probes, or several groups depending on their place in the scene ?

Another list of questions, because I tried to bake my lights, but I had different results than using realtime.

Does using light probes allow for dynamic objects to cast shadows over static objects ?

I used to use "Baked" directional light and it lower drawcalls noticeably, but then trees (SpeedTrees) are not casting shadows on the terrain, is this normal ? Is this fixable ?

I tried "Mixed" directional light, but then I have strange tree shadows: it seems they cast on terrain, but not on other trees and speedtree grasses. I noticed too in this case my player cast shadows on terrain, but not on roads and slabs (roads are static).

For my street spot lights, I tried to "Bake" them and it lower drawcalls by a good amount, but then I have a strange light artifacts (sort of intense reflection in some places) on some voltage lines posts (I'll try to post a screenshot), can it be the lightmap scale of the object ?

EDIT: All my point lights are baked without noticing any problem, but they don't cast any shadows so for them it's good.

 

Here is my scene, currently baked only main directional light and point lights, all the street spot lights are realtime:


Well for me the goal would be to bake all these street lights and determine light probes placement to properly cast lighting/shadows for dynamic objects. With this my street lamp shadows will be nicer tought I need to fix light artifact problem on voltage lines posts on this case.

 

Depends on your scene setup; In one game, I have two groups, one for one part of my racetrack, and a set for the second part. Another good example is a set of probes for each village or something.

Yes, although mixed mode would be needed for that to work.

If your speedtrees aren't marked "static," they won't be part of the calculations. Not sure about how terrain trees work though, it's most likely a limitation if the terrain's trees aren't considered static...

Could you post a screen on this? Which rendering path are you using?

If there isn't enough space allocated to an object in a lightmap, there can be some really bad artifacts, but I don't think that's your issue; it sounds like something else is causing this.

 

Ok, but I've read in a post from a UT guy that mixed mode is dedicated to sunlight so I should set mixed mode only on my main directional light, right ?
Here's the post: Unity 5 - How to light large scenes.
If yes how my street light will cast shadows from dynamic objects ?

I've read in another post from UT guy that terrain tree shadows where not baked in lightmaps currently in Unity 5. But maybe I didn't understood...
Any trick to getting terrain trees to cast shadows on lightmap?
EDIT: just found this post, GI not working on static terrain's trees, maybe light probes is the solution for my tree shadows...

I'd like to set my speedtrees prefab to static, but it seems I can't it's not enabled in the prefab inspector, check below:

Any way to enable it and set it as static ?

Sure, I'll post a screenshot as soon as I will have baked my street lights. I'm using deferred rendering path, linear color space.

I'll post a screenshot of that problem too.

 

Well, give mixed mode a try. The guy recommended that it only be sued for sunlight because of performance reasons. And he's right there; rendering spot light shadows aren't cheap!

Yes, just drop an instance of that speedtree into your scene view, do whatever you want to it, then put it somewhere
in your project folder. Then, on your terrain, swap the tree there for your new prefab.

Ok then, I be waiting.

 

I understand that a lot of spot lights isn't cheap. Are there any tricks to fake street lights ?

On another hand, what I don't understand is why to use light probes if my lights are in mixed mode... How are the light probes improving things ? Does rendering of objects is improved with light probes in this case ?

Thank you so much!!! Didn't tought about this.

Currently rebaking my scene, this is quite long

EDIT: Baking finished.
@FuzzyQuills Here's a screenshot of the problem I have when I'm using "mixed" or "baked" mode on my street spot lights. This appear on a lot of voltage line posts but not all of them.


Can it be wrong lightmap uv for this object ?

For the other problem concerning strange shadows when my directional light is set to mixed mode, I'll first do a test with my speedtrees prefabs set to static as it may actually be the problem.

 

I had the time to rebake my scene as I wish to have it.
The performance and quality of light are very good compared to realtime so I wish to fix several problems I have with shadows.

I've modified my speedtree trees prefab to static and re-assigned them to the terrain trees before to bake.

Sum up of my lighting rig:
- 1 directional light, mixed mode, soft shadows
- several point lights, baked only, no shadows
- many spot lights, mixed mode, soft shadows
- baked GI, resolution at 20 padding at 2, skybox as ambient and reflection source
- precompuded realtime, resolution at 1
- directional mode as general GI

What I notice:
- spot lights shadows seems to be just fine, very good quality, but they does not cast on terrain.
- directional light shadows are very hard despite the fact it is to on soft shadow.
- directional light shadows are quite strange in many places
- my player and more globally dynamic object seem to only cast shadows on dynamic objects and terrain
- I have lighting artifact on my voltage line posts

Notice how directional light shadow does not touch the grass (it's a speedtree tree, not detail) and slab:


Shadow oddities:

Notice how spot light shadow does not cast on terrain:

Lighting artifact on some of my voltage line posts:



Please help me to fix these problems.

 

With light probes there, the dynamic lighting calculations of objects are reduced, as all an objet affected by light probes has to do is sample the probes closest to it, rather than doing an expensive per-pixel light calculation.

And it's fairly easy to fake a spot light with a projector; that's only one method, Nintendo games use alpha-blended cones drawn downwards, with a small spot on the bottom. And that's also a good method! I used an alpha-blended cone for sunshafts in one map I made.

Let me ask; which rendering path are you using? If it's deferred, there are some issues with shadows in mixed mode when using the new deferred renderer. If it's forward rendering... I would not have a clue what's going on.

The artifact on the posts I don't think is caused by lightmap UVs, it looks like some light from somewhere is bleeding in. Try doing a rebake with the streetlamps using light probes instead.

 

I understand now. Thank you very much for claryfing that.

I appreciate the explanation, but it's maybe a bit too much technical to me to catch it. I see there's a BlobLightProjector in the standard assets but don't know how to use it... When you say with a small spot at the bottom, you meant a spot light with a small radius ? I don't want to abuse, but any way to get a sample project containing an example ?

Exactly, I'm using deferred rendering path, linear color space. I'm trying to rebake with forward rendering.

I placed a few light probes near one post that was getting artifacts and check use light probes for this object, I'll see if it's fixed after rebake.

I really appreciate all your help @FuzzyQuills. Thank you very much !

 

Although this one's a bit obvious, check also that the lightposts don't have static ticked.

Not really, but yes, that bloblightprojector's what you want. Drag that into your scene, set the position of the projector to where the light's coming from, and make sure it's pointing downwards.

And yea, by "spot at the bottom" I mean the illuminated bit from the spotlight.

 

Well all these tests are quite long to rebake each time... I'll start a new scene and only add a few objects and lights until I get the expected result.

 

After many tests on a small scene I can say the Baked GI is really buggy... This is really sad as it's sounds promising concerning performances.

I managed to come to what I desired as a look and feel in deferred rendering path with a lot of tricks.
I was forced to use pretty high resolution:
- Precomputed realtime GI resolution at 2
- Baked GI resolution at 60

I used following tricks:
- No trees placed with unity terrain brushes, all placed manually, have them set to static. Grasses kept outside lightmap static.
- Shadows disabled from spotlights.

The quality and performances are very good with these settings and the shadows problems almost all fixed, however I'm pretty sure my big scene will fail to build with out of memory message with such settings... I'm disappointed.

I guess I'll have to stick to realtime lights and have many un-necessary drawcalls for now...
Unity 5 - How to light large scenes.

How much RAM you guys have on your machines to build big scenes ?

 

heh... my machine has 4GB... being a laptop...

 

I didn't seem to receive any artifacts on my bakes and... Hang on, I forgot to say one more thing!

Before you go down your path... have you tried turning off compression?

 

Ah no, will try that, thanks.
The only solution so I pray for it to work as I tried to bake my whole scene with a baked GI resolution at 60, but it failed to bake...

 

Another question:
- Does a scene containing a terrain that is 1000x1000 is considered that big ?
It's only 4 times the size of unity terrain...

I hesitate to split my scene into 4, but I guess I'll have problems with GI seams and will say goodbye to Umbra Occlusion... Unless I use the multi scene editing feature in editor and bake Umbra once for all, but what about GI seams if I bake scenes seperately ?

 

Just tried it, lightmap weight increased but artifacts still there.

Increasing lightmap scale to 4-6 depending on impacted objects seems to fix it tought. However it's a bit like raising baked GI resolution, no ?

 

This is a really interesting thread. I am nowhere near an expert with this.

But I think that they resolved some of the issues with deferred + point + shadow + terrain. I believe this works correctly with a fully updated version.

When I first switched to unity 5, literally no point light shadows would be cast on terrain in deferred and I had to make my own hacked custom terrain shaders.

At some point not too long ago, it seems like the standard terrain shader was corrected. If you're still not getting shadows from point lights, are you using an older version of u5?

 

Yeah It turned up into very technical, hence it's no longer in the good forum category

I use point lights, but I set them to cast no shadows as I don't need them.
I'm currently using Unity 5.0.2-f1.

 

Wait, that part sounds really interesting, it could help me to fix deferred + spotlight + shadow + terrain

Mind to tell me which modification you made to which shader ?

 

Honestly, I've kind of lost track of some of this (I spent like a couple hours on it a month or two ago). I really think they resolved the issues.

That said there's a page somewhere where you can download various builtin shaders (you can search for it, i don't remember the title). Then there's a flag like FULL_SHADOWS_IN_DEFERRED or something. It's pretty simple to hack in - but again - I don't think it should be needed anymore (?).

 

@frosted
I can confirm that spotlight in mixed mode + deferred rendering path doesn't cast shadows on the terrain, no realtime shadow, no baked shadow. At least in Unity 5.0.2-f1 which is the latest if I'm not wrong.

Thank you very much for the insight, will look at this !
If at least I can modify it to cast realtime shadows on terrain, could be cool.

 

Yes, it does increase lightmap coverage, which is sort of like lightmap resolution, except it changes how much space in the lightmap your powerline posts UVs cover, rather than the lightmap res itself.

 

Well, after many test, I fixed all my problems concerning lighting/shadows.
My draw calls count goes up to 1000-1500 depending on areas so I'm quite happy with the current settings.
I can even gain more drawcalls drop with layer culling and LODs if necessary but the current design is what I was looking for.

I have to give you many thanks @FuzzyQuills and the others too.
Thank you soooo much!

 

What all did you end up having to do?

 

I've done the following:
- disabled Precomputed realtime GI
- disabled Baked GI
- set my directional light to realtime
- set all my point lights to realtime
- set all my spotlights to realtime
- set deffered rendering path on camera and player settings
- bake occlusion culling with proper settings

With this I'm realtime almost everywhere, but performances are much better and shadows are casting correctly. I don't understand but it's fine and since I'm baking only reflection probes the bake time is blazingly fast.

As soon as I bake something else than reflection probes I end up doubling the drawcalls and get problems with shadows.
It's true that baked lights are better quality but there's actually a lot of bugs in it so I'll wait and test it later.

 

Looks like you had to sacrifice the GI for better lighting...
UT, we have a case to solve...

 

I'm developing for pc and have found that draw calls affect my performance more than anything else. I try to consolidate as much as possible onto large texture sheets and use few materials, then use a batch combiner to combine everything I can. Combining increases memory use (no mesh instancing) and will usually mean you draw more because larger meshes are more likely to be caught in the frustum, but for me its worth it. I often have over 4 million triangles on screen but under 1000 draw calls. I should note that my game is mostly big exteriors. If I was inside more often, then occlusion culling/trip line activation may become more advantageous and I wouldn't need to combine so much.

 

This is all very interesting! Concerning the mesh combining you are doing, are you using massive mesh colliders too ?
Are you combining it at runtime or in your scene ?