Need help: Light-probes appear way too bright

Maybe we can get better results out of these probes by ignoring the Enlighten output and creating our own probes from direct lights only, with maybe a bit of raycasting for basic visibility checks?

The probe coefficients can be modified in script (they're the only thing that can be modified in scripts)
http://docs.unity3d.com/ScriptReference/LightProbes.html

And this class lets you add lights to a set of SH coefficients: http://docs.unity3d.com/ScriptReference/Rendering.SphericalHarmonicsL2.html

So in theory, we can bake them ourselves. Or create lightprobe tweaking tools to at least scale the brightness, or maybe 'lightprobe tweak volumes' to scale brightness or add ambient light in specific areas of a scene?

There's already this: github.com/keijiro/ProbePolisher - haven't tried it, it's quite old, but it might still work with Unity 5?

 

@bluescrn: Afaik, you don't have access to the enlighten solution when using those functions. Meaning you can do your own lightprobes, but won't get Indirect Illumination and shadows on them. I'm not sure which post it was, but I think devs mentioned this was a reason that Bake Only Lightprobes isn't an option anymore.

I thought maybe it was actual "actual" light objects causing this problem, so did a test with using an emissive sphere. Both emissive and pointlight seems to give the same artifacts; overexposed light on the bright side, black shadows on the dark side. Both pointlight and emissive sphere are baked in these animations. The only dynamic object is the lightprobe lit, moving sphere. There is clearly something wrong when being exposed to a light from one side, the other side manages to drop _below_ the ambient light level of the scene.

 

yes

 

C'mon fix all the lightmaps issues once for all. I don't know for how long this has been broken...¿Since 5.0?

 

The bug report has been reproduced by unity and is now on the issue tracker. I was asked to supply the samples I've provided here as well, so even though the reproduction steps seem simple, that means that the dark spot in opposite direction of the light source is also included in the testcase for the bug.

https://issuetracker.unity3d.com/is...-match-lighting-on-static-lightmapped-objects

 

I saw that this morning. Thanks.
I voted for it, looking forward to a fix.

 

Hey everyone,

In a different thread we are discussing a similar (if not the same) issue and apparently that particular issue is fixed as of 5.3.2. After upgrading to 5.3.2p1 and testing the fix I was dissapointed to find out that this did not solve the issue. This is the thread I mean: http://forum.unity3d.com/threads/5-3-1-yellow-ambient.379007/#post-2492686 from which I quote:

My question here is. Is this a similar issue or the same? Considering that the issuetracker entry that Futurerobot mentioned is still open/active and my problem did not seem resolved in 5.3.2 I am starting to wonder whether I might be confusing two different problems.

Thanks in advance!

 

@Tinovdk The problem I saw in your images looks similar to the one I've reported in this bug.
Not sure about the "yellow ambient in skylight" thread topic, might be a side effect of it? I haven't encountered that specifically.

However, I can see your lightprobes being burnt to a dark color in the opposite direction of where a sufficiently strong lightsource hits them. Your lightprobes that are not directly affected by the light seem to have a fine neutral value, the more the light hits them, the more it darkens on the opposite side.

My bug description was a bit generic when I submitted the issue, but I've since supplied them with more tests, including the animated ones you see above with the "Dark spots opposite light direction."

I also tested this with the latest patches and even the beta. Same results.

 

Futurerobot Thanks for clarifying. Judging from the replies (also in the thread I linked before) it does seem that I was confusing the issues. I guess that this is the thread to watch until this issue gets fixed.

 

@Tinovdk Np, the images in the start of the thread look similar. He mentions he's not using lightprobes, so it's odd that his spheres also darken on the shadowside when he increases the exposure of the light. More light should never make anything darker, (unless when using dynamic exposure). It could be that some light calculations in the engine affect more than probes, but that's just guesswork.

Just tested this on 5.3.2f1, bug is still the same.

 

There are Two ways to fix too much light issue. for real i was finding the same thing and fixed it own my own just now.
So 1) Turn off Global illuminations in Lighting Setting.
2) You can increase Bounces under sky box setting in Lighting.

1) first one will only be helpful if everything is over lit.
2)Second one will help if nothing help might increase CPU load or GPU (Depends)

 

Hi all,
Just running into the issue with Lightprobes being too light.

The two spheres have the same material, one lit by global illumination and the other by light probes. Shouldn't they be closer in brightness?

This is in Unity 2021.3.0f1 Remove Ringing is turned on. The project is set to linear. It seems to happen with any light mapper. The shader is a simple ShaderGraph Lit preset set to specular.



No too sure what else to check, I've been through a lot of posts.
Any ideas? Maybe that's as close as it gets? Hopefully it's just me doing something stupid.

Thanks,
Pete

 

Nevermind I figured out how to do the thing I was ranting about and am now embarassed about my post lol

 

They were very useful for mobile games ~10 years ago, when you could afford very little real-time lighting.

When this sort of thing was high-end mobile: https://blog.unity.com/community/shadowgun-optimizing-for-mobile-sample-level

(Those techniques may still be useful for low-end Android these days...)

 

I gave up on them because they were just flakey, but I still thought they could be really helpful for real time lighting even these days. I opted for a very simple lighting approach, but maybe I should see what options are out there now.