Page MenuHome

Depsgraph API: Allow preserving custom data layers
ClosedPublic

Authored by Sergey Sharybin (sergey) on May 24 2019, 2:52 PM.

Details

Summary

This commit extends dependency graph API with an argument which
denotes that all custom data layers are to be preserved. This
forces modifier stack re-evaluation with more inclusive mask.

Far from ideal, since this might fail in certain configurations
with indirectly used objects which might be missing layers needed
for the current object evaluation. But this is how it worked for
a long time, so should be good enough for until more sophisticated
solution is found.

One thing which is still not covered is the shape keys. Not sure
what is the correct way for them and this is something where
input from Bastien is appreciated. Maybe share shape key datablock,
or duplicate it as well?

In order to use this new behavior two things are to be passed:

  • Pass keep_all_data_layers=True
  • Pass valid dependency graph.

The dependency graph is only needed if keep_all_data_layers=True
and is NOT to be passed if keep_all_data_layers=False.

If keep_all_data_layers=True the dependency graph MUST be passed.

Ref T64794
Ref T64994

Diff Detail

Repository
rB Blender

Event Timeline

source/blender/makesrna/intern/rna_object_api.c
904–909

I would put this parameter after keep_all_data_layers.

911

Maybe rename this to preserve_data_layers, seems slight better to me but I don't have a good reason.

914–915

This description should explain the performance implications of using the option, and what "current state of object" means.

Perhaps something like:

Preserve all data layers in the mesh, like UV maps and vertex groups. By default Blender only computes the subset of data layers needed for viewport display and rendering, for better performance.

Address feedback from Brecht.

For the shape keys i am not sure we can do anything really meaningful here. We can not preserve shape key ID pointer, since it defines shape for a different topology.

So probably those are to be accessed via object.original instead?

Agree that shapekeys cannot be handled that way, iirc they were already 'lost' when exporting objects with modifiers (before all the changes to get modified geometry I mean)… Anyway, that needs specific handling from scripts.

Otherwise did not check code in detail, but solution LGTM.

This revision is now accepted and ready to land.May 24 2019, 4:13 PM
This revision was automatically updated to reflect the committed changes.