I know this has been asked a thousand times but everything i’m seeing in threads doesnt work or has now changed in method from previous advice.
Im trying to get Realtime GI working for my emissive objects, I notice “Realtime GI” checkbox has disappeared from my lighting panel as well as the “Realtime Lightmaps” tab and I can’t see any option to activate it in settings, plus when I change a light to Mixed it tells me that realtime light modes are overriding so did they just enable realtime by default?
Either way, my emissive objects arent casting light, all my objects are set with the “Contribute GI” flag, light probes have been placed and emission is set to Realtime, I can’t figure out why it isnt working
I read they were planning to replace the Realtime GI system in an upcoming release but can’t see if they have simply disabled it, removed it or replaced it as of now…
The UI work to remove it happens before the actual removal to stop people with new projects working on something that will be removed. If you have an existing project you upgrade it should still show it. It might not though. In any case the functionality should still be there for a while.
If I were you I’d dump it since it’s never going to get any fixes really or anything. Baked GI is pretty great still (via PLM or bakery asset) and you can inject the same dynamic flavour with a few soft point lights or a shader tweak.
But yeah it should still work if you script around it.
Again: GI bounce etc will always be working but only if you’re baking via the progressive lightmapper or a similar asset.
Ah just as I thought they removed it, ok so I should set all my emission to bake and use baked Emission for static stuff (I can’t set the actual model as static because im using GPU instancing, I take it thats what the Contribute GI flag is for? because that doesnt interfere with my shaders), what about moving objects with emission? If I set them to Realtime because they move Im going to have the same problem, unless thats what your suggesting soft point lights for…would be a shame though, would rather just let the material emit itself…
Setting to static and being lazy should still work fine though, from memory, even if instancing. Simply untick static batching support in unity settings (player).
Enlighten is best removed because right up to it’s removal announcement it was doing daft stuff like 20ms stalls every so often with HDRP whenever I changed something that touched it. It was just IMHO a mess and I’ve since then just rolled my own GI-looking scenes using the occasional soft fill light / bit of shader graph.
It’s 10 times faster and 10 times more controllable and looks better so there’s no going back for me. Manually setting up a few bouncers is better IMHO cos you know where the player will be and can art direct it. For example you might have a curve for the bounce light and feed in the current time of day, stuff like that, or just link to other lights. It’s not really the scary thing people assume, and for me, less work than fighting the quasi-random-half-auto-obfuscated results I got from enlighten.
Unity just tried too hard to be too auto for too many different needs, and having enlighten a closed source component really made that impossible, removing it is the best thing they could’ve done, licensing or no as it was senseless without proper source and proper control for the dev.
And as you dig a bit, you’ll see AAA tend to use approximations / baked GI and do simple stuff like blend between baked GI lightmaps.
I guess this will change over time to being hw raytraced or other grand scheme, but for me I’ll stick with my little tools and approximations!
Well you can tell im a newbie because until 5 minutes before I posted the problem I found out the lighting system didn’t even belong to Unity and i’ve been developing for around 2 months, i’ve assumed from day 1 it was their own solution lol!
Im guessing they are going to try and set up an all-in-one system where you can hopefully see the effects of illumination in the editor without having to bake, so you can tweak it as you like then do a final bake for production, adding some sort of “do raytracing” thing would be cool too, so if people want to use raytracing they can just enable it and unity will take care of the rest, i’m sure their goal is to make things as automatic as possible, because learning the hundreds of settings in Unity can be a bit overwhelming for a bit, the more I do the more I get used to remembering to do things as I go, and being able to see the effects of my emissive objects in the editor screen without baking would be a big plus!
I read somewhere they are going to try adding an auto-lightprobe thing that just populates the world with lightprobes (probably intended for massive open worlds), I thought logically and considered, perhaps they will just spam the world with them, have them emit rays in all directions to a certain distance, if the ray hits something the probe stays, the rest get deleted, so it would create a surface layer of probes over your entire world.
Lightprobes are only used by dynamic meshes to receive bounce lighting from from baked GI now. They also suffer if you have thin walls or anything like that going on.
I got my bake time down to 20 minutes and now im seeing light emission near baked emission objects, awesome thanks!
Just to clarify, let’s say I have emission on some neon signs, at the moment they emit light on baked but I may disable/enable the emission at runtime to create a blinking effect, I take it I need to change to Realtime to make sure the light from the emission disables also when I disable the emission or will Unity remove the illumination if the emission is disabled even though it’s baked?
Or would you recommend disabling the emission entirely and only using soft point lights?
For things like that soft point lights are better in every way. HDRP has a design for this too, they have a feature where you can remove the hot spot of the point light for this purpose, it’s best for perf and you can use a cookie if you want.
I’d given a different answer for when enlighten was actively supported but it’s not and I won’t give advice for it really.
I’m doing the point light thing myself (in URP at the moment, using lights I made up within the shader).
20 min bake time seems like all meshes have a lot of texture resolution or maybe not using GPU baker?
I currently have each texture map file set to it’s native resolution then using crunch compression at 50% (im planning to try and hire someone eventually to combine all my textures properly after purchasing 4k versions of each so they dont vary all over the place in quality), I would use GPU baker but currently im getting the “Fallback to CPU” error message, ill edit this post with the exact error shortly, but its got something to do with the amount of memory being requested…
EDIT:
OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_WRITE_BUFFER on GeForce GTX 960 (Device 0).
960 is more than good enough for HDRP surprisingly. It’s a fantastic engine but depends on a minimum spec, within it absolutely performs great. I think it was because the design was for midrange at end of 2014 bandwidth wise, so providing you’re controlling bandwidth, HDRP can’t fail.
[quote=“DoomPriestK, post:9, topic: 778803, username:DoomPriestK”]
OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_WRITE_BUFFER on GeForce GTX 960 (Device 0).
[/quote]That’s usually because your lightmap size is too big per object and it’s run out of GPU memory. For a 960 you can’t really go above 512 or 1024 lightmap size per object, and it’s rare you’d need to IMHO (as it’s per object).
I don’t really like how Unity’s doing PLM, it’s been sketchy since forever. Bakery does a good job but that’s third party and you put yourself in the hands of an asset author so YMMV.
Anyway moan at Unity/update/rain dance/etc… or for testing, restrict your lightmap max size to 512, for this GPU.
Finally, once Unity fails to bake you have to restart the editor as it seems to stick on CPU forever from that point until you do.
