Why does light add verts and tris?

I have a simple scene with an empty terrain and a few trees on it

With only my directional light, this scene has 5400 tris and 6500 verts.
But when I enable my spotlight, the tris rise to 6400 and the verts to 7100. (+1000 tris)

Why is that so? I have serious performance issues on mobile although I only use 1 dirLight and 2 spotlights in my scene.

If I add my troll model to the scene, the tris go up to 18800 but with 1 spotlight enabled, the tris rise to incredible 30500 (+ 11700 tris, 62% increase) !!

I cannot understand this behavior.

Spotlight prefs:
Type spot, Range 15, Angle 45, Color all white, Intensity 3.67, Cookie yes (doesnt have impact on the rendered tris), no shadows, no halo, no flare, Render move auto, culling mask everything, lightmapping auto.

Additional hints on how to optimize performance (besides an fps counter) on Android are welcome as well

 

From what I understand it's because it has to do another pass for each light.

 

Doesn't really help me
Are the stats even reliable?

This has such a huge performance on mobile that it is really a showstopper

 

That's why in my farming game, I don't have lights on the tractor because of this. Think about it, every light it has to make another pass adding the light to that vertex for example, right?

 

But this cannot increase the vertex or triangle count as in the Unity stats. Ofc it increases the required cpu power

 

Each light causes each object it affects in forward rendering, to be rendered again for that light.

 

So it's accurate to say that if you had a triangle, 3 verts, with a directional light, and 2 spot lights, it would count towards 9 verts, correct?

 

@mbowen89: Yes, you're right!

@deLord: Firstly, one thing you should do is either have no pixel lights on mobile, or use them sparingly. Reason being, your spotlight is obviously rendering twice the number of verts than it should, because of the way forward rendering works.

If you can live with vertex lighting, then setting the light to "Not Important" uses only one rendering pass, and looks ok on meshes with enough polys. But if you're trying to drop the vert count, then that might not work for you...

Also, if you have multiple spotlights, for some reason, Unity can only render four per-vertex lights at a time in forward rendering, meaning that having more than four visible at a time will look pretty strange...

 

Seems like you may have additional optimization issues as well though I cant see with such a light scene. I worked on a mobile game last year and the main character was nearly 18,000 polys. The game ran fine and I'm guessing it had a lot more than 30,000 verts displaying.

Are there any other issues causing fps drops you're aware of?

 

Well, over-complex pixel shaders can cause issues as well.

 

Hmmm, I can't tell right now what other than the vert/tris count could cause the slowness.
What I dont understand @FuzzyQuills is that your post sounded like it was unusual to have several spot lights. If I was to render a hallway with torches, wouldnt I use a lot of spotlights/pointlights there? Is there a big difference between them concerning performance?
Maybe I could use a pointer on general performance, especially on mobile

 

@deLord:

Sorry for not cleaning that up! Point being, I don't use spot lights very much, but the same principles for forward rendering and multiple pixel lights are the same for all of them. And no, it isn't unusual to have several point lights/spot lights for torches!

According to the Unity docs, spot lights are apparently the most expensive to render compared to all other light types, (IMO, directional lights are the cheapest, as it's only really one dot product and color multiply in the shader at the very least)

IMO one should use either Dual Lightmaps, or light probes with a single lightmap to save on performance, especially on mobile devices where too many pixel lights can drop performance greatly. The light probe bit can be hard to consider though, as it isn't really there in Unity free... (Well, the alternative is that it's relatively easy to simulate something in shadow with a trigger collider or a bounding box, and that is the exact approach I took for my racing game on Mobile)

So, bottom line, don't have too many polys there in the first place, especially for a fast-paced game, and keep the number of real-time lights to a minimum wherever you can, as that, along with real-time shadows, double the polys for each pass drawn for each additional light. (As it is, unless you enable it in your own shaders, one can't really have real-time shadows on more than one light anyway)

I will also point out my real-time shadows workaround for helping to reduce polys: just have shadows on your main dynamic objects, and either use no shadows at all, or just use a simple projector, for smaller objects like coins, treasure chests, etc.

 

Prefer static lightmaps whenever possible!
If you need dynamic lights then try to find approaches to fake it somehow, or use vertex lights. If you absolutely need pixel lights then try to reduce their count as much as possible. You should also try to minimize their range so fewer objects get rendered multiple times.
It's also especially bad to have a large complex objects being hit by multiple lights. So for example if your hallway was 16k triangles and was lit by 10 torches (16k tris * 10 lights = 160k tris rendered), you're really hurting the performance. In a case like that it can be beneficial to separate that 16k triangle mesh to smaller pieces. For example you might be able to separate the hallway to 2k triangle pieces that are each lit by 2 lights each instead of one big mesh lit by 10. In that case you end up with 2k tris * 8 pieces * 2 lights = 32k triangles rendered. Thats much less than the big mesh approach.
The downside of making too many small pieces however is that they require more drawcalls. So it's a constant balance that you just have to try to figure out case by case.

EDIT: Note that those example calculations ignore all additional passes (ambient pass, possible shader specific passes, etc.) for sake of simplicity. The actual rendered triangles would be higher depending what kind of shaders you're using.

 

It's the triangles for rendering the shadows created by the light.