Right now shadows are still computed even when disabled, that's why there's no performance difference. And they are being re-rendered more than once per frame (which shouldn't be the case for the…
If that's what you decided, fine then.
But that sounds way more complex than just updating flush_engine_data_update.
I'd like to understand the advantages of this approach.
The "topology vs.…
There are few things going here, the main performance hit comes from shadow rendering. This is in part because shadows in EEVEE Next are slower/higher-quality, and still missing some optimizations…
Is it something that can be implemented via the ED_render_id_flush_update and ED_render_scene_update? Would be nice if the depsgrapgh did not need to worry about draw-manager specific design.
…
I guess we wrote the same thing at the same time. 😅 Yes, I think that would work.
Maybe we could just store a different last_update property for each relevant flag (I think we only would need ID_RECALC_TRANSFORM, ID_RECALC_GEOMETRY and ID_RECALC_SHADING). We use…
That would be enough to know the the ID has been updated, but not to be sure of what has been updated:
From the main post:
If instance.last_update + 1 == id.last_update, then recalc is…
Counter of a dependency graph level is not easier to maintain and check. It will break the assumption that there is only single update between two redraws.
We could increment the counter only…
I've actually just edited my answer (probably while you were writing yours, sorry) to remove the part about storing it on the Depsgraph since the counter itself is not enough, it would also need…