Eevee: Smart GI bake updating
The Global Illumination baking in Eevee is pretty great, but the problem is it doesn't update if things in the scene move.
My proposal is right next to the option for "Visibility Collection," selector, we have a second selector called "Motion Trigger," collection. That way, when something in this collection moves / changes color / etc. that specific light probe re-bakes itself. This would allow you to set up different zones independently of each-other. IE: Smaller dynamic zones that would be affected by moving objects, and larger static zones in areas that wouldn't be too affected.
9 Comments
Realtime GI yes is a must and eventually somehow should be implemented - be it by voxelization updates of somekind. This is where game engines like Unreal Engine still excel over Eevee.
I fully understood what u mean, its a great idea, I also want that functionality
Also, I think there is need to save baked indirect light as a file or packed to blender and changing the baked lighting to an old one without loosing the old baked info like a presets dropdown, it can have old baked light information on that panel similar.
Moreover, I also think there is need an automation to disable light probes that are inside objects or close to objects that can cause artifacts, it can be controlled by minimum distance threshold between probe and object for example, UE has that feature as I noticed even thought I am not pro at UE , it disable the light probes if they intersect with meshes (and probes hard colors red or green and red ones mean its intersecting and disabled ) and u dont need to keep trying to match the grid to a room with varying unregular objects or meshes.
What you're asking for is just regular global illumination. Baking, by definition, applies the lighting result as a static texture. If you're not doing that, then you're just recalculating global illumination.
* @Jason van Gumster * It would still be baking in this case, because it would only re-bake when an object changed. Therefore if an object moved and then stopped, it wouldn't need to recalculate.
* @Zach Hixson * That's not baking. How would the color data be stored? If it were baking, then you'd be storing an image texture for every frame of animation. The way renderers work in Blender (AFAIK), they recalculate on every frame, so when baking, you're still recalculating per frame. Sure, you only do it once, but the moment you change anything in your animated scene, you'd have to rebake.
I'd prefer if the renderers themselves were smart enough to not have to recalculate on every frame... kind of like partially static BVHs.
* @Jason van Gumster * That's pretty much what I'm saying. I think we are agreeing here. I used the term baking because that is the term blender uses in "bake indirect lighting,' button. Just like you said, my idea was that it has the ability to recalculate if something is changed, but doesn't recalculate on frames where everything is static.
Also with the added ability to limit the "sensing," of changes to specific collections IE: I have a "living room," collection with it's own irradience volume, and a "kitchen," collection with it's own irradience volume. If I change something in the kitchen, then it only triggers the kitchen irradience volume to recalculate, and not the living room and vice versa.
* @Zach Hixson * Then it's a terminology thing. If it's at all dynamic, you're not baking. Full stop. You may be caching results, but you're certainly not baking.
* @Jason van Gumster * Then would Blender's implementation of "bake indirect lighting," technically not baking either? Not trying to argue, just genuinely curious because as far as I know Blender doesn't save those irradience probe maps anywhere.
* @Zach Hixson * You're probably right and I'm probably being overly pedantic. :)