Page MenuHome

Refactor CDData masks, to have one mask per mesh elem type.
ClosedPublic

Authored by Bastien Montagne (mont29) on Feb 25 2019, 5:40 PM.

Details

Summary

We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.

Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!

Some notes:

  • This is probably better for after Spring render crunch (while nothing especially risky here, the size of the patch makes it quiet sensible to typos/copy/paste mistakes and the like :/ ).
  • Naming is open to discussion, this is merely 'placeholder' names I used for CustomData_Masks struct especially.
  • DEG area does not seems to be keen to re-use C structs, so for now just put all five masks as raw uint64_t values, guess this is not the way to go here, just not sure how to do it?
  • Use case triggering that patch: T59338, for datatransfer modifier I need to be able to request CD_NORMAL on loops for 'target' (aka source) object.

Diff Detail

Repository
rB Blender

Event Timeline

Campbell Barton (campbellbarton) requested changes to this revision.EditedFeb 26 2019, 3:02 AM

Generally seems straightforward reasonable changes, only minor comments.

  • CustomData_Masks is mesh spesific since it deals with vert/edge/face.. etc, we may want to use custom-data for curves in the future, think it would be best to include Mesh in the name.
  • The struct is passed by value in a few places, since it's 40 bytes, better to pass as a pointer, mesh_create_derived_render, mesh_create_derived_view for eg.
  • const isn't used consistently editbmesh_build_data, CustomData_Masks_are_matching, mesh_get_derived_final for eg.
This revision now requires changes to proceed.Feb 26 2019, 3:02 AM

Thanks for the quick review. :)

Generally seems straightforward reasonable changes, only minor comments.

  • CustomData_Masks is mesh spesific since it deals with vert/edge/face.. etc, we may want to use custom-data for curves in the future, think it would be best to include Mesh in the name.

Hrmmmm… yes and no? Good point, but if we use cddata for other datatypes in the future, do we really want to add another struct to handle them? Or instead, use unions inside of a single struct? Not sure, just asking. ;)

  • The struct is passed by value in a few places, since it's 40 bytes, better to pass as a pointer, mesh_create_derived_render, mesh_create_derived_view for eg.
  • const isn't used consistently editbmesh_build_data, CustomData_Masks_are_matching, mesh_get_derived_final for eg.

Well, idea here was to pass by value in public functions when internal code could alter the mask for its own usage… But agree it's probably simpler to always pass by (const) pointer, and make copy inside functions when needed. Should be done by now.

  • Move all CustomData_Masks parameters to pointers.

Thanks for the quick review. :)

Generally seems straightforward reasonable changes, only minor comments.

  • CustomData_Masks is mesh spesific since it deals with vert/edge/face.. etc, we may want to use custom-data for curves in the future, think it would be best to include Mesh in the name.

Hrmmmm… yes and no? Good point, but if we use cddata for other datatypes in the future, do we really want to add another struct to handle them? Or instead, use unions inside of a single struct? Not sure, just asking. ;)

Custom data API only has two small functions that take CustomData_Masks and think it's reasonable they be identified as mesh functions (could even be moved out of customdata.c). It just means later on if curves support customdata we don't have odd naming or more large struct member renaming.

OK, so something like CustomData_MeshMasks (for the struct and the two functions)?

@Sergey Sharybin (sergey) would love to hear from you re best way to store those bitflags in DEG data structs? WOuld not consider current solution a really nice one… ;)

Sergey Sharybin (sergey) requested changes to this revision.Feb 26 2019, 6:24 PM
Sergey Sharybin (sergey) added inline comments.
source/blender/depsgraph/DEG_depsgraph_build.h
165

Think you're missing forward declaration of CustomData_Masks.

source/blender/depsgraph/intern/builder/deg_builder.cc
206–207

Have those wrapped into a single structure, with an overloaded comparison operator.

source/blender/depsgraph/intern/builder/deg_builder_nodes.cc
157–158

Why all this complexity? In the entire file of this change?

source/blender/depsgraph/intern/builder/deg_builder_nodes.h
233–234

Not sure why you chose that. There is nothing what is really preventing you from using CustomData_MeshMasks here.

source/blender/depsgraph/intern/builder/deg_builder_relations.cc
1140–1142

You can easily think of a cleaner way of calling this.

Idea one:

add_customdata_mask(ct->tar, LayerSource::VERTEX, CD_MASK_NORMAL);
add_customdata_mask(ct->tar, LayerSource::LOOP, CD_MASK_CUSTOMLOOPNORMAL);

Idea two:

add_customdata_mask(ct->tar, CDMaskVertex(CD_MASK_NORMAL));
add_customdata_mask(ct->tar, CDMaskLoop(CD_MASK_CUSTOMLOOPNORMAL));

Idea three:

add_customdata_mask(ct->tar, CDMaskVertex(CD_MASK_NORMAL) | CDMaskLoop(CD_MASK_CUSTOMLOOPNORMAL));
source/blender/depsgraph/intern/builder/deg_builder_relations.h
209–213

This is error prone, the calls are not readable, and is also confusing because object is not necessary a mesh.

There is already a mistake of calling vmasksimply mask here.

I also don't want those one letter stuff in my code. It is vertex_mask not vmask.

source/blender/depsgraph/intern/depsgraph_query.cc
126

This changes behavior from returning 0 for non-existing node to keep-at-garbage(stack-allocated) value.
It is to be at least documented in the comment of DEG_get_customdata_mask_for_objectabout what happens if object is not found.

source/blender/depsgraph/intern/node/deg_node_id.h
87–89

This should really be one property for current and one property for previous one.

Can either use CustomData_Mask, or some DEG specific variation with all the handy operations overloaded for it.

This revision now requires changes to proceed.Feb 26 2019, 6:24 PM
Bastien Montagne (mont29) marked 6 inline comments as done.
Bastien Montagne (mont29) added inline comments.
source/blender/depsgraph/intern/builder/deg_builder_nodes.h
233–234

As said previously, did not know how that kind of things was supposed to be handled in DEG, so just went for a temp stupid basic solution to get the rest f the code working first...

source/blender/depsgraph/intern/depsgraph_query.cc
126

I don’t mind adding back a return value (a bool?) to mark that object was not found, but not sure how useful that would be?

As for 'keep-as-garbage', that is kind of general new behavior for functions generating some cddata masking, they all now append to given mask, instead of fully setting its values. This allows to only pass around pointers, and cope for the lack of bitwise OR op for the C struct...

Bastien Montagne (mont29) marked an inline comment as done.
Bastien Montagne (mont29) edited the summary of this revision. (Show Details)
  • Move all CustomData_Masks parameters to pointers.
  • Rename to CustomData_MeshMasks, and do suggested changes in DEG area.

Updated against latest master.

@Erick Tukuniata (erickblender) not sure what you mean here? Probably not though, this some rather low-level change that might potentially benefit to many things involving meshes, but that specific patch is intended to be as 'transparent' as possible, not changing anything to existing behaviors.

@Brecht Van Lommel (brecht) @Sergey Sharybin (sergey) you guys are in the Spring turmoil, what’s your feeling about this patch regarding that? I think it should rather wait for after rendering is done? If so, any idea when that might be?

source/blender/depsgraph/intern/builder/deg_builder_relations.cc
316

DEG_CustomData_MeshMasks() ?

source/blender/depsgraph/intern/depsgraph_type.h
75

Probably ok for now. But maybe consider adding depsgraph_customdata.h and depsgraph_customdata_impl.h.

79

Don't mix snake style with camel case.
Types are to start with capital and be camel case.

80–84

Use CustomData_MeshMasks.

85

Add default constructor, which initializes masks to 0.
Also, probably worth adding constructor from CustomData_MeshMasks.

96

a -> other.

98

I would do it as

DEGCustomDataMeshMasks result;
result.vert_mask = this.vert_mask | other.vert_mask;
...

Might be looking more verbose, but is way less fragile.

106

bool operator==(const DEG_CustomData_MeshMasks& other) const with all the equality and then
bool operator!=(const DEG_CustomData_MeshMasks& a) const { return !(*this == other);

117

DEGCustomDataMeshMasks result;
result.vert_mask = vert_mask;
return result;

Sergey Sharybin (sergey) requested changes to this revision.Mar 1 2019, 12:37 PM
This revision now requires changes to proceed.Mar 1 2019, 12:37 PM
Bastien Montagne (mont29) marked 7 inline comments as done.
  • Updates in DEG code from review.
source/blender/depsgraph/intern/depsgraph_type.h
75

Not sure what should go into depsgraph_customdata_impl.h… Wouldn’t we rather need a depsgraph_customdata.cc ?

80–84

Don’t understand that one? That would make something like CustomData_MeshMasks masks;, and then would have to access the masks with customdata_masks.masks.vmask? Also implies that we include DNA_customdata_types.h here...

Or did you mean 'Use CustomDataMask' (from BKE_customdata.h's typedef uint64_t CustomDataMask;)?

Update against latest master.

Some minor feedback.
Otherwise seems good.

source/blender/depsgraph/intern/depsgraph_type.cc
56–61

Technically style is:

DEG::DEGCustomDataMeshMasks::DEGCustomDataMeshMasks(const CustomData_MeshMasks *other)
        : vert_mask(other->vmask),
          edge_mask(other->emask),
          face_mask(other->fmask),
          loop_mask(other->lmask),
          poly_mask(other->pmask)
{
}
source/blender/depsgraph/intern/depsgraph_type.h
92

Mark as explicit.

Also not sure why implementation of this specific constructor is in .cc file.
Feels weird to have this scattered. Is it going from the fear of using includes from a header file?

This revision is now accepted and ready to land.Mar 6 2019, 11:29 AM
Bastien Montagne (mont29) marked 2 inline comments as done.Mar 6 2019, 4:10 PM
Bastien Montagne (mont29) added inline comments.
source/blender/depsgraph/intern/depsgraph_type.h
92

Also not sure why implementation of this specific constructor is in .cc file.
Feels weird to have this scattered. Is it going from the fear of using includes from a header file?

Yes, did not want to have to include DNA_customdata_types.h in that header

Bastien Montagne (mont29) marked an inline comment as done.

Updates in DEG code from review, update against latest master.

Code looks fine now.
Is there any aspects of review/testing you're awaiting?

No am doing it right now, just did not want to commit that late in the evening ;)

This revision was automatically updated to reflect the committed changes.