Unity 5 = unstable Omni point lights <solved>

Unity Engine
1

I didn’t realize after some time using Unity 5.1.2 Personal. That lights are extremely unstable. They flicker
and turns on off depends on other lights. projectors or cookie spots… This was never a issue in 4.6.

I been trying to tune down the issue to see where the problem where coming from:

  • Turning of baking and global light = no fix.
  • Turning off projectors or cookie spots. = no fix
  • Turning of bouncing for all lights = no fix
  • Make sure all lights doesn’t cast shadows = no fix
  • Make sure all lights doesn’t bake = no fix

Even when i strip things down to bare minimum and with different settings, the issue is clearly there from the engine.

I tough when you use a new and better version it would be a better product, considering reversing unless this will get addressed.

I also notis that you can see the render layers when i move my camera (like a small bleeding border), looks very unprofessional.

System:
windows 7 64bit , Nvidia GTX 760
Unity 5.1.2

2
3

In your QualitySettings, are you using deferred or forward rendering? Also, what is your maximum light count?

4

Deffered or forward also emulation mode = no impact. No shadow, no bounching.

5

Deferred won’t have this issue but forward would sort lights by importance. If you have the problem in deferred, then please report a bug.

6

I actually had the same issue, upgraded to 5.1.1p4 and the issue was fixed. Maybe try upgrading to the latest patch.

7

Eventually i figured the problem. Funny why i haven’t found this on the forum before. Pixel Light count is set to very low by default. I guess this is marked as solved. Thought there is a issue with performance with higher Pixel Light Count but Unity 5 performance better than 4.6 so not really a reason to get back to 4.6

Also if any one have a issue with Projector with additive shader , use cookie with spot light. works ok, tough I miss my own shader code for projector that is no longer working

8

That’s why I asked what your light count was set to. Great news.

1 Like
9

Great news indeed. Still 4 is low for default settings.
thx for inputs

1 Like
10

In a custom shader of mine, I use 8 shaded simultaneously, of which works fine for my game.

11

Lets get this strait. A light without a pixelLightCount is not a light

When you place a light in your scene, the core of a light is the pixel light count, so why not automatic add this count when you place a light? This is what I don’t get. If you don’t have enough pixel count you should not be allowed to place the light in the first place. Or get some type of error or warning.

I made a code for this, so I don’t have a issue with this ever again. This is a one time run script, I share it:

public Light[] lights;
void SetPixelLightCount()
{
   lights = FindObjectsOfType(typeof(Light)) as Light[];
   QualitySettings.pixelLightCount = lights.Length;
}

Problem solved, you even see the names of all your lights in the scene and can keep track on what’s going on for performance, no cutting of lights no unstable flicker.

You can run this script when ever you want to measure the correct pixel amount. Just don’t put this in update.

1 Like
12

Higher pixel light count = higher rendering times.
Normally it should be enough to have one mesh lit by 4 lights. Maybe 8, 16… but not all. If you have a big scene, you won’t have all lights on one place.
You could move to deferred lighting, all lights will be treated equal and are not affected by pixel light count

13

Unless we talking about mobile device, returning back to legacy rending pass technique is not really an option. If you try the code I made you see the problem is fixed, you can also make some frustum logic where pixelLightCount only counts what you see in view, if that is what you meant.

Performance should not be a talk about pixelLightCount, but how many lights you have. No point having a light if it flickers and looks unprofessional.

14

Pixel lights set to 0 = unlimited lights on deferred still. The pixel light thing is for forward only, which means every mesh that light affects will get drawn again, hitting your fill rate, triangles, etc. You should consider deferred as being faster the moment you start using more than a couple of lights in forward to be honest.

With deferred you can have hundreds for the cost of a few forward lights. Really, consider it.

1 Like
15

Ahh dam you right, i am for sure not using forward on purpose!.. it looks like Forward render is set by default even if i override!, that is strange. Playsettings = Forward:
Why is forward render set by default in Unity 5 ? its Deferred Render by Default in Unity 4. Yeah I know light count is not a issue with deferred, its render in to a quad that mixes all the 3 passes, where light count is no longer a issue. (Light Pre-Pass))

16

And there goes the fog function :slight_smile: I hope global fog is better than the old one

17

Yep… deferred rendering kills fog rendering off the board! :smile:

Point being, global fog will definitely work, both as the obvious height-based stuff, and the normal stuff. (Just untick height fog for normal fog in deferred. :))

There’s also a thread around here with people improving the global fog, will have to find the thread on that one. On top of that… you will need to change the fog color for global fog from the lighting panel, not the global fog panel… a bit unusual, I know! :slight_smile:

18

I am actually very happy with how the new Global fog shader works, the last shader in 4.6 did not work at all for me (due to additive blend issue, I had to rewrite the whole shader. Now it works great. No conflict with additive blending.

I go check out the thread. thx

19

I am still in shock that i was running Forward render for that long time, that explaine some shader issue i ran in to as well in the transcendent process.