Hi all,
While playing in the editor, with profiler on, after the GI has initially found a solution, you can turn off the precalculated GI to get an easy 30 fps ( in my case) boost. I am finding that the GI is taking a lot of processing while no lights are changing.
Can I turn it off via script the same way I can manually turn it off after it has come up with a solution?
I have found that DynamicGI.updateThreshold doesnt seem to do much of anything.
Cheers,
Ryan
Solution:
Turning the “Bounce” setting on all low-importance lights to 0 removes them from the enlighten update solution.
Doing this in conjunction with the 5.0.1.P3 update immediately yields lower cpu loads and effectively doubles your FPS.
Huge thanks to KEngelstoft for spearheading this fix.
The update you are seeing in the Editor is checking if materials changed and this is only happing in the editor. In the player you change materials using the scripting API so this much faster and we donøt have to scan all the materials etc.
If you see high CPU usage from GI in the standalone player even though nothing changed, please let us know.
Realtime GI CPU usage for the player can be set in the Lighting window.
Thanks for that, I dont think I am explaining it correctly:
In my scenes, I use no baked lighting, only realtime GI. While playing the game, and no lights are changing, the framerate is very low. If while playing, I disable realtime GI in the Lighting->Scene pane, I immediately get a 30 FPS bonus, and the lighting solution does not go away. Thats great, but I cant do this via scripting. I want the scene to process the realtime GI once at start, then disable any and all calculations after that via script; the same thing as turning it off in the editor.
Before anyone jumps on me for wanting to run realtime GI once then turn it off… I have a time of day change at the start, and the scene has to change the lighting based on that dynamic value, so perm baking isnt an option.
I see that you have the CPU usage dropdown, Oddly, my game gets smoother the higher that value is. I have to set it permanently to Unlimited to get any decent framerate. Setting on default really brings the system down. I hope others have had this issue and can offer a reason why.
Thanks!
edit: Ive just tested it by running 2 builds, one with Unlimited ticked for realtime GI, and the other with Low, and the game absolutely runs slower by about 15-20 fps on Low.
additionally, could you please give me a decent value for DynamicGI.updateThreshold that might solve this issue? I have it at 1000, but theres no documentation as to what it should reasonably be.
So after doing some testing:
Linking UpdateThreshold to a spinner in Update() doesnt seem to change anything or any response difference in the GI.
DynamicGI.synchronousMode does seem to affect FPS, but there is no visual difference.
this is all we get.
I would have to assume that the realtime GI is smart enough to update when it senses important change in the scene, but I cannot for the life of me figure out what is changing in the scene that would trigger a constant update. All lights have their bounces turned to 0. No materials are changing that are static light objects.
I would have to assume I am doing something wrong in my scene for the constant CPU drain of the realtime GI if it is optimized to change only when the scene does. What triggers the realtime GI update?
1.Lights
2.Texture changes
3. Other static lightmapped objects being setactive?
4. Emissive values
4.??
Additionally, This thread should probably be moved to GI subforum. Sorry to be obnoxious, but the FPS change is drastic with one checkbox click in the editor. If you guys could release that checkbox into the API for script control that would be beeeeaaaaauuutiful.
updateThreshold describes how much input lighting can change, before the realtime lightmap is updated.
A value of 0 means that the lightmap will update regardless of the amount of change in input lighting. A positive value causes the GI to only update when the threshold is exceeded. This is useful for saving CPU cycles and updating those parts of the scene where the lighting is being changed more frequently than other areas where the lighting is mostly static. The default value is 1.0. Any positive value is fine but we recommend smaller values, as otherwise you might see popping artefacts (and wrong radiosity).
The update threshold is the threshold against which the sum of all radiance differences in the system is compared.
Any negative value will turn off temporal coherence, so the system will be solved every frame.
If you are seeing high CPU usage then you are likely changing the sky or some lights or material parameters so GI is updated each frame.
The FPS change you are seeing is only applicable in the editor - we hash everything every frame to check what changed. In the player you use the API to tell it what changed, so you get maximum performance.
Now when I turn off precompute Realtime GI while the game is running, I get black artifacts everywhere and general uglies. What hope I had left for a liquidy smooth gameplay is now gone so… case closed. :<
I have scoured the scene trying to find the culprit, but the sky isnt doing anything, the sunlight isnt moving, but its also not a static light, so maybe thats it?
I wish there was a way for Enlighten to tell the user what is changing in the scene so they can find it and optimize. Should I email them?
Ah interesting, secret GISceneManager in my profiler. Its looking like (on average) the reflection probes are taking more time to process then the GI, but the GI is consistently on the top.
Please see attached profile for worst case GI scenerio.
84 Calls to UpdateLights… is that every light in the scene thats analyzed? Does it take more than setting the bounce to “0” to remove it from GI calcs? Because all of the lights in my scene are realtime but 0 bounce.
The 84 calls are just calls to a sorting function inside UpdateLights, when hashes are added and removed. That is not the slow part of UpdateLights. I have added some more profiler tags inside UpdateLights, will be available in an upcoming patch release, so it will be easier to see what is going on.
Do you happen to have a lot of completely identical lights or are you animating any of the light properties (light type, position, color, intensity etc.)?
Yes, I have around 40 point lights in the scene that are identical and independently changing:
position
rotation
intensity
range
every single frame. Bounce is set to 0. I have always assumed that if the bounce was set to 0, it shouldnt affect the GI update. If this thinking is wrong, then that would be the problem.
That’s such awesome news! I can’t wait to try it. Anybody with moving lights in their game should see huge fps leaps. Monuments will be built of your likeness.
It run nice on my standalone and iPhone 6(Maybe all device with A8 but iPhone 6 is the only one that I have), but it just become lower to about 20 FPS on my iPad mini…
In fact I only got one directional light and my lighting setting is here (Unity 5.1):
And I got all objects baked except those balls (they have to be moving, otherwise my game will looks as a nice static picture), but I just can’t understand why I got a really low FPS in iPad mini 2 (It isn’t the last one but it is higher than current standard).
I got one light and set the bounce of it to zero, but I don’t think this is working cause 20 FPS is the only thing that I got…
Of course my scripts should not be the problem and physic shouldn’t too.
Just trying to figure it out… Could anyone help me?
I want it to runs at last 45 FPS on A7 devices like iPad mini 2, I mean, how can I optimize it?
