Using legacy deferred renderer with legacy shaders giving inverted lighting!

Hi,

We recently upgraded to Unity 5 for our project and have found that our old shaders in the Legacy Deferred render path causes some rather extreme lighting problems in our scenes. I cannot work out why this is happening. Any ideas?

If we move to the new deferred render path it works because it falls back to forward lit rendering. But we must have deferred rendering for our project to have any performance at all.

Do you have your own deferred lighting shader? (i.e. Internal-PrePassLighting.shader in your project)

If so, it might need an update to work in 5.0. IIRC we renamed one of shader keywords that was doing lighting encoding in non-HDR case.

(but hey, this lighting looks kinda cool :))

Thanks for the reply @Aras . No we don’t have that shader, however your comment about HDR caused me to check something out: If I disable HDR on the Main Camera everything is fixed!
Any suggestion as to why enabling HDR in this scenario causes our game to go into the twilight zone (And you’re right is it kinda cool hah)?

That should not happen. The only way I could imagine this happening is if you do have a custom deferred lighting shader; and/or your actual shaders are all custom and are using wrong shader keyword in 5.0.

I can’t see how we could have a custom lighting shader - We don’t have any “Internal*” shaders. Here is one of our shaders as an example - It is a pretty basic Shader Forge generated shader.

That’s what I partially said above: “or your actual shaders are all custom and are using wrong shader keyword in 5.0.” – looks like shaderforge is (on 5.0) wrongly using HDR_LIGHT_PREPASS_ON keyword; it should be using UNITY_HDR_ON one.

I’ll poke ShaderForge guy, and will see if we can do anything on our side. Meanwhile, replacing HDR_LIGHT_PREPASS_ON with UNITY_HDR_ON in your shaders should make it work.

Ah thanks Aras. I checked out the Shader Forge bug feedback site and indeed there is one there outstanding. I’ve added a comment to this thread in there so hopefully @Acegikmo will get on to it soon.

I’ll work around that on our side; fix should hopefully be in 5.0 RC3.