Changeset View
Standalone View
source/blender/blenkernel/BKE_customdata.h
| Show All 25 Lines | |||||
| struct BMesh; | struct BMesh; | ||||
| struct BlendDataReader; | struct BlendDataReader; | ||||
| struct BlendWriter; | struct BlendWriter; | ||||
| struct CustomData; | struct CustomData; | ||||
| struct CustomData_MeshMasks; | struct CustomData_MeshMasks; | ||||
| struct ID; | struct ID; | ||||
| typedef uint64_t eCustomDataMask; | typedef uint64_t eCustomDataMask; | ||||
| /* These names are used as prefixes for UV layer names to find the associated boolean | |||||
| * layers. They should never be longer than 2 chars, as MAX_CUSTOMDATA_LAYER_NAME | |||||
| * has 4 extra bytes above what can be used for the base layer name, and these | |||||
campbellbarton: It would be good to have a doc-strings here describing constraints on these names, for e.g. is… | |||||
| * prefixes are placed between 2 '.'s at the start of the layer name. | |||||
| * For example The uv vert selection layer of a layer named 'UVMap.001' | |||||
| * will be called '.vs.UVMap.001' . */ | |||||
| #define UV_VERTSEL_NAME "vs" | |||||
| #define UV_EDGESEL_NAME "es" | |||||
Done Inline Actions"An offset of -1 means ...." chrisbblend: "An offset of -1 means ...." | |||||
| #define UV_PINNED_NAME "pn" | |||||
| /** | |||||
| * UV map related customdata offsets into BMesh attribute blocks. See #BM_uv_map_get_offsets. | |||||
| * Defined in #BKE_customdata.h to avoid including bmesh.h in many unrelated areas. | |||||
| * An offset of -1 means that the corresponding layer does not exist. | |||||
| */ | |||||
| typedef struct BMUVOffsets { | |||||
| int uv; | |||||
| int select_vert; | |||||
| int select_edge; | |||||
| int pin; | |||||
| } BMUVOffsets; | |||||
| /* A data type large enough to hold 1 element from any custom-data layer type. */ | /* A data type large enough to hold 1 element from any custom-data layer type. */ | ||||
| typedef struct { | typedef struct { | ||||
| unsigned char data[64]; | unsigned char data[64]; | ||||
| } CDBlockBytes; | } CDBlockBytes; | ||||
| extern const CustomData_MeshMasks CD_MASK_BAREMESH; | extern const CustomData_MeshMasks CD_MASK_BAREMESH; | ||||
| extern const CustomData_MeshMasks CD_MASK_BAREMESH_ORIGINDEX; | extern const CustomData_MeshMasks CD_MASK_BAREMESH_ORIGINDEX; | ||||
| extern const CustomData_MeshMasks CD_MASK_MESH; | extern const CustomData_MeshMasks CD_MASK_MESH; | ||||
| ▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines | |||||
| * Mixes the "value" (e.g. mloopuv uv or mloopcol colors) from one block into | * Mixes the "value" (e.g. mloopuv uv or mloopcol colors) from one block into | ||||
| * another, while not overwriting anything else (e.g. flags). | * another, while not overwriting anything else (e.g. flags). | ||||
| */ | */ | ||||
| void CustomData_data_mix_value( | void CustomData_data_mix_value( | ||||
| int type, const void *source, void *dest, int mixmode, float mixfactor); | int type, const void *source, void *dest, int mixmode, float mixfactor); | ||||
| /** | /** | ||||
| * Compares if data1 is equal to data2. type is a valid CustomData type | * Compares if data1 is equal to data2. type is a valid CustomData type | ||||
| * enum (e.g. #CD_MLOOPUV). the layer type's equal function is used to compare | * enum (e.g. #CD_PROP_FLOAT). the layer type's equal function is used to compare | ||||
| * the data, if it exists, otherwise #memcmp is used. | * the data, if it exists, otherwise #memcmp is used. | ||||
| */ | */ | ||||
| bool CustomData_data_equals(int type, const void *data1, const void *data2); | bool CustomData_data_equals(int type, const void *data1, const void *data2); | ||||
| void CustomData_data_initminmax(int type, void *min, void *max); | void CustomData_data_initminmax(int type, void *min, void *max); | ||||
| void CustomData_data_dominmax(int type, const void *data, void *min, void *max); | void CustomData_data_dominmax(int type, const void *data, void *min, void *max); | ||||
| void CustomData_data_multiply(int type, void *data, float fac); | void CustomData_data_multiply(int type, void *data, float fac); | ||||
| void CustomData_data_add(int type, void *data1, const void *data2); | void CustomData_data_add(int type, void *data1, const void *data2); | ||||
| ▲ Show 20 Lines • Show All 280 Lines • ▼ Show 20 Lines | |||||
| void *CustomData_get_layer_named(const struct CustomData *data, int type, const char *name); | void *CustomData_get_layer_named(const struct CustomData *data, int type, const char *name); | ||||
| int CustomData_get_offset(const struct CustomData *data, int type); | int CustomData_get_offset(const struct CustomData *data, int type); | ||||
| int CustomData_get_offset_named(const CustomData *data, int type, const char *name); | int CustomData_get_offset_named(const CustomData *data, int type, const char *name); | ||||
| int CustomData_get_n_offset(const struct CustomData *data, int type, int n); | int CustomData_get_n_offset(const struct CustomData *data, int type, int n); | ||||
| int CustomData_get_layer_index(const struct CustomData *data, int type); | int CustomData_get_layer_index(const struct CustomData *data, int type); | ||||
| int CustomData_get_layer_index_n(const struct CustomData *data, int type, int n); | int CustomData_get_layer_index_n(const struct CustomData *data, int type, int n); | ||||
| int CustomData_get_named_layer_index(const struct CustomData *data, int type, const char *name); | int CustomData_get_named_layer_index(const struct CustomData *data, int type, const char *name); | ||||
| int CustomData_get_named_layer_index_notype(const struct CustomData *data, const char *name); | |||||
| int CustomData_get_active_layer_index(const struct CustomData *data, int type); | int CustomData_get_active_layer_index(const struct CustomData *data, int type); | ||||
| int CustomData_get_render_layer_index(const struct CustomData *data, int type); | int CustomData_get_render_layer_index(const struct CustomData *data, int type); | ||||
| int CustomData_get_clone_layer_index(const struct CustomData *data, int type); | int CustomData_get_clone_layer_index(const struct CustomData *data, int type); | ||||
| int CustomData_get_stencil_layer_index(const struct CustomData *data, int type); | int CustomData_get_stencil_layer_index(const struct CustomData *data, int type); | ||||
| int CustomData_get_named_layer(const struct CustomData *data, int type, const char *name); | int CustomData_get_named_layer(const struct CustomData *data, int type, const char *name); | ||||
| int CustomData_get_active_layer(const struct CustomData *data, int type); | int CustomData_get_active_layer(const struct CustomData *data, int type); | ||||
| int CustomData_get_render_layer(const struct CustomData *data, int type); | int CustomData_get_render_layer(const struct CustomData *data, int type); | ||||
| int CustomData_get_clone_layer(const struct CustomData *data, int type); | int CustomData_get_clone_layer(const struct CustomData *data, int type); | ||||
| ▲ Show 20 Lines • Show All 93 Lines • ▼ Show 20 Lines | |||||
| * valid when comparing data from two layers. | * valid when comparing data from two layers. | ||||
| */ | */ | ||||
| bool CustomData_layertype_is_dynamic(int type); | bool CustomData_layertype_is_dynamic(int type); | ||||
| /** | /** | ||||
| * \return Maximum number of layers of given \a type, -1 means 'no limit'. | * \return Maximum number of layers of given \a type, -1 means 'no limit'. | ||||
| */ | */ | ||||
| int CustomData_layertype_layers_max(int type); | int CustomData_layertype_layers_max(int type); | ||||
| #ifdef __cplusplus | |||||
| /** \return The maximum length for a layer name with the given prefix. */ | |||||
| int CustomData_name_max_length_calc(blender::StringRef name); | |||||
| #endif | |||||
| /** | /** | ||||
| * Make sure the name of layer at index is unique. | * Make sure the name of layer at index is unique. | ||||
| */ | */ | ||||
| void CustomData_set_layer_unique_name(struct CustomData *data, int index); | void CustomData_set_layer_unique_name(struct CustomData *data, int index); | ||||
| void CustomData_validate_layer_name(const struct CustomData *data, | void CustomData_validate_layer_name(const struct CustomData *data, | ||||
| int type, | int type, | ||||
| const char *name, | const char *name, | ||||
| ▲ Show 20 Lines • Show All 57 Lines • ▼ Show 20 Lines | enum { | ||||
| CD_FAKE_MDEFORMVERT = CD_FAKE | CD_MDEFORMVERT, /* *sigh* due to how vgroups are stored :(. */ | CD_FAKE_MDEFORMVERT = CD_FAKE | CD_MDEFORMVERT, /* *sigh* due to how vgroups are stored :(. */ | ||||
| CD_FAKE_SHAPEKEY = CD_FAKE | | CD_FAKE_SHAPEKEY = CD_FAKE | | ||||
| CD_SHAPEKEY, /* Not available as real CD layer in non-bmesh context. */ | CD_SHAPEKEY, /* Not available as real CD layer in non-bmesh context. */ | ||||
| /* Edges. */ | /* Edges. */ | ||||
| CD_FAKE_SEAM = CD_FAKE | 100, /* UV seam flag for edges. */ | CD_FAKE_SEAM = CD_FAKE | 100, /* UV seam flag for edges. */ | ||||
| /* Multiple types of mesh elements... */ | /* Multiple types of mesh elements... */ | ||||
| CD_FAKE_UV = CD_FAKE | | CD_FAKE_UV = | ||||
| CD_MLOOPUV, /* UV flag, because we handle both loop's UVs and poly's textures. */ | CD_FAKE | | ||||
| CD_PROP_FLOAT2, /* UV flag, because we handle both loop's UVs and poly's textures. */ | |||||
Done Inline ActionsWhat does the "*sigh*" here reference? Is it possible to describe the problem instead of just emoting? chrisbblend: What does the "*sigh*" here reference? Is it possible to describe the problem instead of just… | |||||
Done Inline ActionsI *think* the *sigh* was from master and has since been removed. Or maybe hans wrote it, I'll ask. I have no idea myself ;-) Actually , I think the whole CD_FAKE_BWEIGHT has been removed from master and has popped back up here because of a merge mistake. Edit: it was the latter. Removed. Baardaap: I *think* the *sigh* was from master and has since been removed. Or maybe hans wrote it, I'll… | |||||
| CD_FAKE_LNOR = CD_FAKE | | CD_FAKE_LNOR = CD_FAKE | | ||||
| CD_CUSTOMLOOPNORMAL, /* Because we play with clnor and temp lnor layers here. */ | CD_CUSTOMLOOPNORMAL, /* Because we play with clnor and temp lnor layers here. */ | ||||
| CD_FAKE_SHARP = CD_FAKE | 200, /* Sharp flag for edges, smooth flag for faces. */ | CD_FAKE_SHARP = CD_FAKE | 200, /* Sharp flag for edges, smooth flag for faces. */ | ||||
| }; | }; | ||||
| enum { | enum { | ||||
| ▲ Show 20 Lines • Show All 84 Lines • ▼ Show 20 Lines | void CustomData_blend_write(BlendWriter *writer, | ||||
| int count, | int count, | ||||
| eCustomDataMask cddata_mask, | eCustomDataMask cddata_mask, | ||||
| ID *id); | ID *id); | ||||
| #endif | #endif | ||||
| void CustomData_blend_read(struct BlendDataReader *reader, struct CustomData *data, int count); | void CustomData_blend_read(struct BlendDataReader *reader, struct CustomData *data, int count); | ||||
| size_t CustomData_get_elem_size(struct CustomDataLayer *layer); | size_t CustomData_get_elem_size(struct CustomDataLayer *layer); | ||||
Done Inline ActionsAdd a comment explaining that these are custom data offset for bmesh. brecht: Add a comment explaining that these are custom data offset for bmesh. | |||||
| #ifndef NDEBUG | #ifndef NDEBUG | ||||
| struct DynStr; | struct DynStr; | ||||
| /** Use to inspect mesh data when debugging. */ | /** Use to inspect mesh data when debugging. */ | ||||
| void CustomData_debug_info_from_layers(const struct CustomData *data, | void CustomData_debug_info_from_layers(const struct CustomData *data, | ||||
| const char *indent, | const char *indent, | ||||
| struct DynStr *dynstr); | struct DynStr *dynstr); | ||||
Done Inline ActionsCould this return pointers to the data directly? It seems that is what's actually needed, and avoids potential confusion about what kind of indices these are. Also add a comment explaining what this struct is. brecht: Could this return pointers to the data directly? It seems that is what's actually needed, and… | |||||
Done Inline ActionsThat's a good idea. I do need the index of the base uv layer (for the on demand creation of the bool layers) so I kept that. Baardaap: That's a good idea. I do need the index of the base uv layer (for the on demand creation of the… | |||||
| #endif /* NDEBUG */ | #endif /* NDEBUG */ | ||||
| #ifdef __cplusplus | #ifdef __cplusplus | ||||
| } | } | ||||
| #endif | #endif | ||||
| #ifdef __cplusplus | #ifdef __cplusplus | ||||
| # include "BLI_cpp_type.hh" | # include "BLI_cpp_type.hh" | ||||
Done Inline ActionsIt might make code simpler and clearer if this returned the struct by value: HooglyBoogly: It might make code simpler and clearer if this returned the struct by value:
`UVMap_Offsets… | |||||
Done Inline ActionsI guess these short names are use to avoid running out of space in CustomDataLayer.name? However since the size of that was not increased, I guess it can still happen? This is also going to be exposed in the Python API, so I'm not really sure such obscure names are a good idea even if they save some memory. And are these names going to be consistent with selection layers in regular mesh edit mode? brecht: I guess these short names are use to avoid running out of space in `CustomDataLayer.name`? | |||||
Done Inline ActionsCorrect. I think there are plans to make the layer names longer, or variable length. But until then I think the names should be as short as possible. Better would be to solve the tiny layer name length of course. The bmesh python api still exposes this as if it's a single MLoopUV struct, by the way. But of course you indeed will see the attribute layer names in python. And yes. A very long layer name needs another renaming scheme... I was hoping the layername length would be made flexible before this patch would land. But if it isn't I guess I'll need to address that edge case. Baardaap: Correct. I think there are plans to make the layer names longer, or variable length. But until… | |||||
| namespace blender::bke { | namespace blender::bke { | ||||
| const CPPType *custom_data_type_to_cpp_type(eCustomDataType type); | const CPPType *custom_data_type_to_cpp_type(eCustomDataType type); | ||||
| eCustomDataType cpp_type_to_custom_data_type(const CPPType &type); | eCustomDataType cpp_type_to_custom_data_type(const CPPType &type); | ||||
| } // namespace blender::bke | } // namespace blender::bke | ||||
| #endif | #endif | ||||
Done Inline ActionsI'm a little skeptical about any function that creates attributes on the CustomData level-- that really should go through the attribute API (the C or C++ one is fine) HooglyBoogly: I'm a little skeptical about any function that creates attributes on the CustomData level… | |||||
Done Inline ActionsI'll have a look at it. But I *think* I need the _get_ and _ensure_ functions on a CustomData level because of where they're used. Seems ugly to put only _create_ in another place? Baardaap: I'll have a look at it. But I *think* I need the _get_ and _ensure_ functions on a CustomData… | |||||
Done Inline ActionsI guess since it's only creating the UI attributes, the chances of an already taken name are quite low. Maybe this is fine for now. HooglyBoogly: I guess since it's only creating the UI attributes, the chances of an already taken name are… | |||||
Done Inline ActionsAh, hm. I now see what you mean. The checking for double names is in the attributes functions... I need to think about that Baardaap: Ah, hm. I now see what you mean. The checking for double names is in the attributes functions... | |||||
Done Inline ActionsThis macro should be a function I think HooglyBoogly: This macro should be a function I think | |||||
Done Inline ActionsBecause this header is also included in C files I used a #define , because creating an actual (inline) function which uses std::str would give trouble in C files. I admit it's a bit hacky ;-) Baardaap: Because this header is also included in C files I used a #define , because creating an actual… | |||||
Done Inline ActionsDoes it really need to be an inline function? I think it's fine to just declare the function in the C header and implement it in C++ HooglyBoogly: Does it really need to be an inline function? I think it's fine to just declare the function in… | |||||
Done Inline ActionsAdd a UV_ prefix to these defines. Also, to make them shorter, "LAYER_" could be removed I think HooglyBoogly: Add a `UV_` prefix to these defines. Also, to make them shorter, "LAYER_" could be removed I… | |||||
Done Inline ActionsIt has only one use case now, but I think this can be CustomData_sublayer_name? Since presumably any future sublayers should use the same convention. I also would just use C strings here, this is used in performance critical code and allocating std::string is unnecessary. Then you also avoid code duplication BM_uv_layer_ensure_sublayer. brecht: It has only one use case now, but I think this can be `CustomData_sublayer_name`? Since… | |||||
Done Inline ActionsI can rename them back to CustomData_* . I originally had set up a generic CustomData sublayer scheme, more or less. But Hans & Jacques thought it better to first keep it in the UV 'theme' and only ever add a generic sublayer scgheme when we actually need it. We can always rename stuff then. I don't mind renaming stuff back, but we'd need to have consensus what it should be first ;-) Baardaap: I can rename them back to CustomData_* . I originally had set up a generic CustomData sublayer… | |||||
Done Inline ActionsLooks like this function is unused HooglyBoogly: Looks like this function is unused | |||||
Done Inline ActionsLooks like DEPENDENT_LAYER_NAME_INDEX is unused HooglyBoogly: Looks like `DEPENDENT_LAYER_NAME_INDEX` is unused | |||||
Done Inline Actionsuint32_t HooglyBoogly: `uint32_t` | |||||
It would be good to have a doc-strings here describing constraints on these names, for e.g. is it essential these never exceed 2 bytes? (MAX_CUSTOMDATA_LAYER_NAME could be referenced too).