I am writing a custom modifier that allocates and uses some runtime data, so I provided a function pointer in the freeRuntimeData field of the ModifierTypeInfo struct (defined in my MOD_foo.c file) to free it eventually.
The callback is indeed called when the Modifier is removed from an object, but when the object is deleted without removing the modifier first, it never gets called.
Is this a bug, or does this means that I did not correctly get the way modifier data is managed? I based my work on the current release of Blender 2.80.
I allow myself to bump this thread up a bit – hope it does not circonvent any convention – because I fear it might be a memory leak that affects existing modifiers too.
(@mont29 Following up the discussion after the bug report, since it’s more appropriate here.)
Thanks for the explaination, re-allocation makes sense, I think I was more concerned by the many allocation, or more precisely the many “modifier freed” triggered before “modifier cooked”. I’m not sure I get how this is due to the CoW System, because maybe I’m not sure exactly of what it is. Could you point me to some documentation or detailed enough comment block about this?
CoW (from Copy-on-Write, although it is not really that currently) is just a copy of data-blocks managed by each depsgraph, on which all dynamic editings (like modifiers, constraints, animations, etc.) are applied.
Not sure we have much doc on current system, besides code itself, but @sergey should know better here.