Which now leaves me stumped: Why does 1 point light illuminate both objects (with the exact same material) perfectly, but adding another light on 1 side makes it DARKER and creates an ugly line?
Of course, the quick fix here is to remove the other light, but I’m just curious as to why this happens.
I’m going to guess you have your per pixel light count under quality set to 2? You have 3 lights hitting object 1, and only 2 hitting object 2. That means one of the lights on object 1 is not going to be rendered as per pixel, but rather rendered as a per vertex light, and Unity’s per vertex lights don’t quite match the per pixel lights.
That worked! I had to set it to 5 for the line to go away. After a quick fix of making the range of all my point lights shorter I got it to 4. Obviously I’ll need to rethink lighting a bit. Apparently I have the range set on my lights too far as they overlap. Thanks a lot man!
As a warning, since I saw in your other thread you’re targeting mobile, per pixel lights are quite expensive and you generally want to keep that setting at 2, or even 0. If you’re not using normal maps the difference should be easy to compensate for. The alternative is baked lighting, but if you’re spawning these objects dynamically Unity’s baking system doesn’t really handle this scenario well and you might have to generate your own lightmaps externally.
Yes, unfortunately I’m doing this all dynamically, so I can’t bake lights:( After a little more optimization I was able to get stable 40+FPS on my Samsung Galaxy Tab 3 7.0 (not very powerful device). Considering I was at 19 this morning, I’m happy with the result.
I’m not using normal maps, but you said “the difference should be easy to compensate for”. If I set the pixel lights to 0, then all my lighting goes away. So how can I have lighting with 0 pixel lights?
Lighting will fallback to per vertex lighting if you set it to 0, but you’ll need to pre tessellate the geometry some so there are vertices to light instead of being giant quads. Using a few hundred polygons for the background wall shouldn’t hit performance much, even on that device, and should be far faster than using any per pixel lighting. If the lights don’t move you could even bake the lighting into the vertex colors (manually with some custom scripting or in an external program) and go “unlit” so there’s zero real time lighting on “static” geometry, though you’d have to be more careful with where two objects meet. Note that per vertex lighting by default is limited to 4 lights per object, but you could also use the vertex lit rendering path and support 8 lights per object.
