blender/blender
150
477
Fork 704
Code Issues 6.7k Pull Requests 901 Projects 18 Wiki Activity

Modifiers: Add custom attribute weight support to bevel modifier #117366

Merged
Hans Goudey merged 18 commits from Mike93/blender:bevel-edge-attributes into main 2024-09-05 17:15:52 +02:00
Conversation 31 Commits 18 Files Changed 9 +137 -12
Mike93 commented 2024-01-20 18:35:55 +01:00
Contributor
Copy Link

As of 4.0, bevel edge weight data is stored as an "attribute" of type float, domain edge. The bevel modifier is currently hard-coded to use the bevel_weight_edge attribute as the data source for the edge weights. This small change provides a string textbox where the user can specify alternate attributes for the bevel's edge weights.

image

I tried to implement a search dropdown box that would filter on attributes of type float and domain edge but 1) could not figure it out, and 2) was advised that it was more complexity than was worth it. This might be a temporary upgrade to the bevel modifier until bevel geometry nodes take over.

One more note: this code change requires adding a parameter to the bmesh bevel operator - so there's a chance this could break addons that don't use that last argument. Maybe there is a way to do default arguments or something to get around this.

As of 4.0, bevel edge weight data is stored as an "attribute" of type `float`, domain `edge`. The bevel modifier is currently hard-coded to use the `bevel_weight_edge` attribute as the data source for the edge weights. This small change provides a string textbox where the user can specify alternate attributes for the bevel's edge weights. ![image](/attachments/8ea283dd-6b2f-43f7-9abc-18238dbd9431) I tried to implement a search dropdown box that would filter on attributes of type `float` and domain `edge` but 1) could not figure it out, and 2) was advised that it was more complexity than was worth it. This might be a temporary upgrade to the bevel modifier until bevel geometry nodes take over. One more note: this code change requires adding a parameter to the bmesh bevel operator - so there's a chance this could break addons that don't use that last argument. Maybe there is a way to do default arguments or something to get around this.
image.png
16 KiB
👍 9 ❤️ 17 🎉 6 🚀 7
Mike93 changed title from Add custom attribute edge groups for bevel modifier to UI: Add custom attribute edge groups for bevel modifier 2024-01-20 18:39:56 +01:00
Iliya Katushenock added this to the Modeling project 2024-01-20 18:44:32 +01:00
Howard Trickey requested changes 2024-01-21 23:09:32 +01:00
Howard Trickey left a comment
Member
Copy Link

This generally looks fine to me, and makes a lot of sense given how it basically just allows changing a hard-coded property string.

It would indeed by nice if you could do something like the UI for vertex groups that shows up in the bevel modifier to choose a vertex group name. I looked a bit at the code that does that and couldn't figure out where the actual guts of the panel drawing happened. I wouldn't regard the lack of this as a show-stopper for putting this in.

Normally I would insist on trying to have parity of features with the edit mode bevel. But when you are doing destructive bevels, it doesn't seem that much of a hardship to just use the default bevel edge weight property. And anyway, I'm hoping to make bigger changes to bevel next year and so getting the current version just right seems less than crucial to me.

This generally looks fine to me, and makes a lot of sense given how it basically just allows changing a hard-coded property string. It would indeed by nice if you could do something like the UI for vertex groups that shows up in the bevel modifier to choose a vertex group name. I looked a bit at the code that does that and couldn't figure out where the actual guts of the panel drawing happened. I wouldn't regard the lack of this as a show-stopper for putting this in. Normally I would insist on trying to have parity of features with the edit mode bevel. But when you are doing destructive bevels, it doesn't seem that much of a hardship to just use the default bevel edge weight property. And anyway, I'm hoping to make bigger changes to bevel next year and so getting the current version just right seems less than crucial to me.
source/blender/makesrna/intern/rna_modifier.cc Outdated
@ -954,1 +954,4 @@
static void rna_BevelModifier_custom_weight_name_set(PointerRNA *ptr, const char *value)
{
Object *owner = (Object *)ptr->owner_id;
Howard Trickey commented 2024-01-21 22:30:32 +01:00
Member
Copy Link

Remove this line; you never used this result.

Remove this line; you never used this result.
Mike93 marked this conversation as resolved
Mike93 force-pushed bevel-edge-attributes from 0f9c53e677 to 176dde6caf 2024-01-22 00:01:56 +01:00 Compare
Mike93 commented 2024-01-22 00:03:52 +01:00
Author
Contributor
Copy Link

Removed the unused reference to owner

Removed the unused reference to `owner`
Mike93 closed this pull request 2024-01-22 00:03:54 +01:00
Mike93 commented 2024-01-22 00:04:28 +01:00
Author
Contributor
Copy Link

Not sure what happened... did not mean to close, just meant to comment. Trying to re-open now.

Not sure what happened... did not mean to close, just meant to comment. Trying to re-open now.
Mike93 reopened this pull request 2024-01-22 00:04:30 +01:00
Mike93 requested review from Howard Trickey 2024-01-22 00:05:44 +01:00
Howard Trickey commented 2024-01-25 20:27:28 +01:00
Member
Copy Link

How hard would it be to do the same thing for vertex bevel weights? Hans stated that for consistency, we should probably do that too. I'm not sure how often people use vertex bevel weights -- I guess that's the main question as to whether the consistency is worth the bother.

How hard would it be to do the same thing for vertex bevel weights? Hans stated that for consistency, we should probably do that too. I'm not sure how often people use vertex bevel weights -- I guess that's the main question as to whether the consistency is worth the bother.
Mike93 commented 2024-01-25 21:05:13 +01:00
Author
Contributor
Copy Link

How hard would it be to do the same thing for vertex bevel weights? Hans stated that for consistency, we should probably do that too. I'm not sure how often people use vertex bevel weights -- I guess that's the main question as to whether the consistency is worth the bother.

Took a quick stab at it, seems to work fine (I tested the default attribute which is bevel_weight_vert as well):

image

image

Had to refactor some of the RNA/DNA names and descriptions so they are more clear. I like this more anyways, actually, since it is clear that the limit method of weight clearly points to an attribute now.

As per whether people use vertex beveling... I personally have never used it. Nor have I ever seen a tutorial or video of someone else using it. I also don't know if there's a standard way of creating vertex weights, like there is with bevel edge weights (Ctrl + E > Bevel Edge Weight).

Let me know if you want me to bring in these changes.

> How hard would it be to do the same thing for vertex bevel weights? Hans stated that for consistency, we should probably do that too. I'm not sure how often people use vertex bevel weights -- I guess that's the main question as to whether the consistency is worth the bother. Took a quick stab at it, seems to work fine (I tested the default attribute which is `bevel_weight_vert` as well): ![image](/attachments/ea801534-9bfb-4480-8f7a-68e3b85e11a9) ![image](/attachments/835c7de7-8d4a-41ce-92a1-bf7d16c34a10) Had to refactor some of the RNA/DNA names and descriptions so they are more clear. I like this more anyways, actually, since it is clear that the `limit method` of `weight` clearly points to an attribute now. As per whether people use vertex beveling... I personally have never used it. Nor have I ever seen a tutorial or video of someone else using it. I also don't know if there's a standard way of creating vertex weights, like there is with bevel edge weights (`Ctrl + E > Bevel Edge Weight`). Let me know if you want me to bring in these changes.
image.png
123 KiB
image.png
109 KiB
❤️ 3
Howard Trickey commented 2024-01-25 21:08:05 +01:00
Member
Copy Link

Yes, please bring in these changes. Thanks for doing it!
I'm waiting for Campbell to review this too, as he said he had some comments., but to me this is looking good to include in 4.1.

Yes, please bring in these changes. Thanks for doing it! I'm waiting for Campbell to review this too, as he said he had some comments., but to me this is looking good to include in 4.1.
👍 1
Howard Trickey requested review from Campbell Barton 2024-01-25 21:08:47 +01:00
Mike93 force-pushed bevel-edge-attributes from 176dde6caf to 9e4942ce0a 2024-01-25 21:15:01 +01:00 Compare
Howard Trickey commented 2024-01-26 13:47:50 +01:00
Member
Copy Link

While you are waiting for the other review, one thing to think about and perhaps work on is what should go in the release notes for this change. We like to put documentation in the release notes about the same time as we commit things that change visible behavior. The note would likely go here: https://developer.blender.org/docs/release_notes/4.1/modeling/ . Also, make sure that the automated tests are not broken by your changes. See https://developer.blender.org/docs/handbook/testing/

While you are waiting for the other review, one thing to think about and perhaps work on is what should go in the release notes for this change. We like to put documentation in the release notes about the same time as we commit things that change visible behavior. The note would likely go here: https://developer.blender.org/docs/release_notes/4.1/modeling/ . Also, make sure that the automated tests are not broken by your changes. See https://developer.blender.org/docs/handbook/testing/
Mike93 commented 2024-01-27 00:11:12 +01:00
Author
Contributor
Copy Link

Okay thanks for the links. I will probably have some time this weekend or early next week to take a look at it.

Okay thanks for the links. I will probably have some time this weekend or early next week to take a look at it.
Mike93 commented 2024-01-30 01:46:51 +01:00
Author
Contributor
Copy Link

blender/blender-developer-docs#14

Will look into the testing later this week

https://projects.blender.org/blender/blender-developer-docs/pulls/14 Will look into the testing later this week
Campbell Barton commented 2024-02-06 13:17:19 +01:00
Owner
Copy Link

As far as I know we don't have conventions for attributes in modifiers, created #117893 to address this.

From reading over this patch there looks to be some issues:

  • Renaming an attribute doesn't update the attribute name in the modifier, wouldn't users expect this?
  • Existing files will have empty attribute names, since there doesn't look to be any versioning code, in #117893 I suggest to use empty names which fall back to the default attribute - in that case versioning isn't needed. Whatever the case, loading existing files shouldn't loose references to vertex/edge weights.
As far as I know we don't have conventions for attributes in modifiers, created #117893 to address this. From reading over this patch there looks to be some issues: - Renaming an attribute doesn't update the attribute name in the modifier, wouldn't users expect this? - Existing files will have empty attribute names, since there doesn't look to be any versioning code, in #117893 I suggest to use empty names which fall back to the default attribute - in that case versioning isn't needed. Whatever the case, loading existing files shouldn't loose references to vertex/edge weights.
Mike93 commented 2024-02-06 17:38:44 +01:00
Author
Contributor
Copy Link

I read through your other issue, it all makes sense to me. I attempted to fix the empty attribute name issue by putting this in modify_mesh:

  if (bmd->vertex_weight_name == "") {
    STRNCPY(bmd->vertex_weight_name, "bevel_weight_vert");
  }
  if (bmd->edge_weight_name == "") {
    STRNCPY(bmd->edge_weight_name, "bevel_weight_edge");
  }

But I'm probably missing something larger about the DNA/RNA philosophy. This is the logic that's used in the RNA string function which actually sets the attribute value, but it seems I can't do it this way outside of the UI.

I read through your other issue, it all makes sense to me. I attempted to fix the empty attribute name issue by putting this in `modify_mesh`: ``` if (bmd->vertex_weight_name == "") { STRNCPY(bmd->vertex_weight_name, "bevel_weight_vert"); } if (bmd->edge_weight_name == "") { STRNCPY(bmd->edge_weight_name, "bevel_weight_edge"); } ``` But I'm probably missing something larger about the DNA/RNA philosophy. This is the logic that's used in the RNA string function which actually sets the attribute value, but it seems I can't do it this way outside of the UI.
Campbell Barton requested changes 2024-02-07 09:47:15 +01:00
Campbell Barton left a comment
Owner
Copy Link

Based on Hans reply to #117893 it seems like the names are expected to be set (no fallback for empty names). This means existing files will need to be updated.

Check source/blender/blenloader/intern/versioning_400.cc (for reference version_vertex_weight_edit_preserve_threshold_exclusivity does something similar).

Based on Hans reply to #117893 it seems like the names are expected to be set (no fallback for empty names). This means existing files will need to be updated. Check `source/blender/blenloader/intern/versioning_400.cc` (for reference `version_vertex_weight_edit_preserve_threshold_exclusivity` does something similar).
Mike93 commented 2024-02-08 01:33:24 +01:00
Author
Contributor
Copy Link

Thanks for the references. Sorry, this is going to seem unrelated, but are we technically not accepting new features for 4.1 now? I was reading this. I'm under a mountain of work right now and I'd like to know how long I have to tinker with this.

I'd really like to see this feature get implemented, and I'd be worried that it would get lost in the shuffle.

Thanks for the references. Sorry, this is going to seem unrelated, but are we technically not accepting new features for 4.1 now? I was reading [this](https://projects.blender.org/blender/blender/milestone/18). I'm under a mountain of work right now and I'd like to know how long I have to tinker with this. I'd really like to see this feature get implemented, and I'd be worried that it would get lost in the shuffle.
❤️ 4
Daniel Gryningstjerna commented 2024-03-12 17:40:51 +01:00
First-time contributor
Copy Link

Any news? Seems really useful! and Bevel v2 is still very far away.

Any news? Seems really useful! and Bevel v2 is still very far away.
Mike93 commented 2024-03-12 17:44:35 +01:00
Author
Contributor
Copy Link

I'm still keeping an eye on the proposal regarding attribute references, but unfortunately my work load has pretty much doubled in the past month or so and I have a deadline to hit at beginning of April.

If another dev wants to pick this up I would be more than happy to walk through what I've done so far. The difficult piece will be "Clicking on the name shows a drop-down list of names (as with vertex groups), this includes the default name.". I spent nearly a day trying to figure this out, and it's beyond me. I did use the attribute dropdown in geo-nodes as a reference, but still couldn't hack it.

I'm still keeping an eye on the [proposal](https://projects.blender.org/blender/blender/issues/117893) regarding attribute references, but unfortunately my work load has pretty much doubled in the past month or so and I have a deadline to hit at beginning of April. If another dev wants to pick this up I would be more than happy to walk through what I've done so far. The difficult piece will be "Clicking on the name shows a drop-down list of names (as with vertex groups), this includes the default name.". I spent nearly a day trying to figure this out, and it's beyond me. I did use the attribute dropdown in geo-nodes as a reference, but still couldn't hack it.
❤️ 1
Daniel Gryningstjerna commented 2024-03-12 18:00:53 +01:00
First-time contributor
Copy Link

I'm still keeping an eye on the proposal regarding attribute references, but unfortunately my work load has pretty much doubled in the past month or so and I have a deadline to hit at beginning of April.

If another dev wants to pick this up I would be more than happy to walk through what I've done so far. The difficult piece will be "Clicking on the name shows a drop-down list of names (as with vertex groups), this includes the default name.". I spent nearly a day trying to figure this out, and it's beyond me. I did use the attribute dropdown in geo-nodes as a reference, but still couldn't hack it.

Understandable, and thanks for taking the patch so far! Hope it eventually lands some day, but dont stress about it :)

> I'm still keeping an eye on the [proposal](https://projects.blender.org/blender/blender/issues/117893) regarding attribute references, but unfortunately my work load has pretty much doubled in the past month or so and I have a deadline to hit at beginning of April. > > If another dev wants to pick this up I would be more than happy to walk through what I've done so far. The difficult piece will be "Clicking on the name shows a drop-down list of names (as with vertex groups), this includes the default name.". I spent nearly a day trying to figure this out, and it's beyond me. I did use the attribute dropdown in geo-nodes as a reference, but still couldn't hack it. Understandable, and thanks for taking the patch so far! Hope it eventually lands some day, but dont stress about it :)
Mike93 commented 2024-05-18 20:20:32 +02:00
Author
Contributor
Copy Link

A couple of updates here. I haven't squashed/updated my commit for this PR yet because I want to wait and see if I can fix the remaining issues.

@ideasman42 as per your second bullet point about fallback, that's working now, I was just missing an #include "BLI_string.h" at the top for STRNCPY to work. So when you create a new .blend file, the default values are vertex_weight_edge and bevel_weight_edge (depending on if Vertices/Edge are selected at the top) when you select Weight as the Limit Method. In my opinion this functions nicely as it maintains existing behaviour by default.

As per your first point - whether the modifier should get an updated attribute name if the name is updated. I would say no, because when you use Vertex Groups, and you change the vertex group name after assigning it to the modifier, it does not update. It does, however, give you a red indication that the "link" to the vertex group is broken:
image

In this case I assigned a group called Group and then renamed it in the vertex group panel.

I am still investigating implementing the dropdown. One hang up I am having, is that it seems that vertex group data is a part of the Object structure whereas attributes are assigned to the Mesh. This is odd, in my opinion, as I don't know what the conceptual difference would be - vertex groups are assigned to "groups" of vertices from a mesh, and attributes are just more general vertex groups in a sense (Vertex, Edge, Face, Face Center).

If anyone knows of an "easier" example to pick on for the dropdown functionality, that would be a great help. I've been searching through the code for another couple hours here and still getting nowhere. There's a function called modifier_vgroup_ui in MOD_bevel.cc that seems to be where the "magic" happens for the dropdown, but I am struggling to see how it could be implemented with effectively a "filter" for the right type of attribute group (vertex or edge as appropriate).

I do believe it makes sense for this "weight" group attribute to function the same as the vertex groups - i.e., show the appropriate attributes in the dropdown so they can be easily selected, and highlight them red if the link is broken due to a rename.

A couple of updates here. I haven't squashed/updated my commit for this PR yet because I want to wait and see if I can fix the remaining issues. @ideasman42 as per your second bullet point about fallback, that's working now, I was just missing an `#include "BLI_string.h"` at the top for `STRNCPY` to work. So when you create a new .blend file, the default values are `vertex_weight_edge` and `bevel_weight_edge` (depending on if Vertices/Edge are selected at the top) when you select `Weight` as the Limit Method. In my opinion this functions nicely as it maintains existing behaviour by default. As per your first point - whether the modifier should get an updated attribute name if the name is updated. I would say no, because when you use Vertex Groups, and you change the vertex group name after assigning it to the modifier, it does not update. It does, however, give you a red indication that the "link" to the vertex group is broken: ![image](/attachments/a7654888-c0f5-492f-9d97-5aed79995d61) In this case I assigned a group called `Group` and then renamed it in the vertex group panel. I am still investigating implementing the dropdown. One hang up I am having, is that it seems that vertex group data is a part of the `Object` structure whereas attributes are assigned to the `Mesh`. This is odd, in my opinion, as I don't know what the conceptual difference would be - vertex groups are assigned to "groups" of vertices from a mesh, and attributes are just more general vertex groups in a sense (Vertex, Edge, Face, Face Center). If anyone knows of an "easier" example to pick on for the dropdown functionality, that would be a great help. I've been searching through the code for another couple hours here and still getting nowhere. There's a function called `modifier_vgroup_ui` in `MOD_bevel.cc` that seems to be where the "magic" happens for the dropdown, but I am struggling to see how it could be implemented with effectively a "filter" for the right type of attribute group (vertex or edge as appropriate). I do believe it makes sense for this "weight" group attribute to function the same as the vertex groups - i.e., show the appropriate attributes in the dropdown so they can be easily selected, and highlight them red if the link is broken due to a rename.
image.png
18 KiB
🎉 1
Mike93 commented 2024-05-18 23:14:52 +02:00
Author
Contributor
Copy Link

I think it's done. To get the drop down to function properly, filtering on Vertex or Edge attributes, we need quite a bit of extra scaffolding for the custom search function. Here's the dropdown for Edge bevels by weight:

image

And for Vertex bevels:
image

You'll notice the "position" attribute is in the list - that seems to be a default vertex attribute that gets added to any mesh data. I also filtered out any attributes that started with a period, because it seemed that those were internal attributes.

After renaming the new edge group, "test_edge_weights" to "test_edge_weights2", we see the same behaviour as the vertex group dropdown:
image

So all in all - this will work, but I don't think it's coded in the prettiest way.

Here are the functions I had to add:

  • uiItemPointerR_att_prop same as uiItemPointerR_prop, but with an additional int domain_filter argument
  • ui_but_add_search_att same as ui_but_add_search but with an additional int domain_filter argument
  • Inside this function, I set the search button update callback to a new custom function that allows filtering on attribute domain:
    uiButSearchUpdateFn update_fn = nullptr;
    if (domain_filter == 0) {
      update_fn = ui_rna_collection_search_att_point_update_fn;
    } else if (domain_filter == 1) {
      update_fn = ui_rna_collection_search_att_edge_update_fn;
    }
    UI_but_func_search_set(but,
                           ui_searchbox_create_generic,
                           update_fn,
                           coll_search,
                           false,
                           ui_rna_collection_search_arg_free_fn,
                           nullptr,
                           nullptr);

-ui_rna_collection_search_att_point/edge_update_fn, exactly same as ui_rna_collection_search_update_fn, except has an if statement which checks the domain type and filters out the attributes starting with "."


        PropertyRNA *domain_prop = RNA_struct_find_property(&itemptr, "domain");
        int domain = RNA_property_int_get(&itemptr, domain_prop);

        int domain_filter = 1;
        if (domain == domain_filter && name[0] != '.') {
          if (!skip_filter) {
            search.add(name, cis);
          }
          BLI_addtail(items_list, cis);
        }

This is a real architectural issue that I don't know how to get around and will need input on. Obviously copy/pasting this entire function for each attribute domain type is inefficient.

We can't add "domain_filter" as an integer parameter to this function, as the search button update callback depends on having a particular method signature, and presumably is used in many other places throughout Blender. So arbitrarily adding an argument to this new search_update_fn would likely break the search button update functions elsewhere.

I will try to update my PR soon, but in the mean time, any feedback on these issues would be helpful.

I think it's done. To get the drop down to function properly, filtering on Vertex or Edge attributes, we need quite a bit of extra scaffolding for the custom search function. Here's the dropdown for Edge bevels by weight: ![image](/attachments/8d8c2b87-2849-4447-a459-1dfd1d6289bc) And for Vertex bevels: ![image](/attachments/3a28550c-9bfc-46db-81c0-63e862c62c0e) You'll notice the "position" attribute is in the list - that seems to be a default vertex attribute that gets added to any mesh data. I also filtered out any attributes that started with a period, because it seemed that those were internal attributes. After renaming the new edge group, "test_edge_weights" to "test_edge_weights2", we see the same behaviour as the vertex group dropdown: ![image](/attachments/a33802b5-f320-437c-a7c0-be7f1ed1f1ff) So all in all - this will _work_, but I don't think it's coded in the prettiest way. Here are the functions I had to add: - `uiItemPointerR_att_prop` same as `uiItemPointerR_prop`, but with an additional `int domain_filter` argument - `ui_but_add_search_att` same as `ui_but_add_search` but with an additional `int domain_filter` argument - Inside this function, I set the search button update callback to a new custom function that allows filtering on attribute domain: ``` uiButSearchUpdateFn update_fn = nullptr; if (domain_filter == 0) { update_fn = ui_rna_collection_search_att_point_update_fn; } else if (domain_filter == 1) { update_fn = ui_rna_collection_search_att_edge_update_fn; } UI_but_func_search_set(but, ui_searchbox_create_generic, update_fn, coll_search, false, ui_rna_collection_search_arg_free_fn, nullptr, nullptr); ``` -`ui_rna_collection_search_att_point/edge_update_fn`, exactly same as `ui_rna_collection_search_update_fn`, except has an if statement which checks the domain type and filters out the attributes starting with "." ``` PropertyRNA *domain_prop = RNA_struct_find_property(&itemptr, "domain"); int domain = RNA_property_int_get(&itemptr, domain_prop); int domain_filter = 1; if (domain == domain_filter && name[0] != '.') { if (!skip_filter) { search.add(name, cis); } BLI_addtail(items_list, cis); } ``` This is a real architectural issue that I don't know how to get around and will need input on. Obviously copy/pasting this entire function for each attribute domain type is inefficient. We can't add "domain_filter" as an integer parameter to this function, as the search button update callback depends on having a particular method signature, and presumably is used in many other places throughout Blender. So arbitrarily adding an argument to this new `search_update_fn` would likely break the search button update functions elsewhere. I will try to update my PR soon, but in the mean time, any feedback on these issues would be helpful.
image.png
39 KiB
image.png
31 KiB
image.png
35 KiB
❤️ 2
Mike93 force-pushed bevel-edge-attributes from 9e4942ce0a to b5e84a9c75 2024-05-18 23:35:12 +02:00 Compare
Mike93 commented 2024-05-18 23:35:54 +02:00
Author
Contributor
Copy Link

Squashed everything into the latest commit. So now you can see all the functions I added. I would gladly take any comments on how to make this code prettier/more efficient.

Edit: maybe a macro might be nice in place of duplicating the function each time? Not sure Blender's coding standards on macros. We could preserve the signature of the function and still keep the code compact ish:

Something like:

#define DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(name, domain_filter_value) \
void ui_rna_collection_search_##name(                      \
     const bContext *C, void *arg, const char *str, uiSearchItems *items, const bool is_first) \
{ \
}
...
int domain_filter = domain_filter_value; \
if ((domain == domain_filter && name[0] != '.') || domain_filter == -1) { \
...

And then usage:

DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(update_fn, -1);
DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(att_point_update_fn, 0);
DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(att_edge_update_fn, 1);
Squashed everything into the latest commit. So now you can see all the functions I added. I would gladly take any comments on how to make this code prettier/more efficient. Edit: maybe a macro might be nice in place of duplicating the function each time? Not sure Blender's coding standards on macros. We could preserve the signature of the function and still keep the code compact ish: Something like: ``` #define DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(name, domain_filter_value) \ void ui_rna_collection_search_##name( \ const bContext *C, void *arg, const char *str, uiSearchItems *items, const bool is_first) \ { \ } ... int domain_filter = domain_filter_value; \ if ((domain == domain_filter && name[0] != '.') || domain_filter == -1) { \ ... ``` And then usage: ``` DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(update_fn, -1); DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(att_point_update_fn, 0); DEFINE_UI_RNA_COLLECTION_SEARCH_UPDATE_FN(att_edge_update_fn, 1); ```
Mike93 requested review from Campbell Barton 2024-05-19 03:23:35 +02:00
Santiago-Slavutsky commented 2024-06-10 23:36:38 +02:00
First-time contributor
Copy Link

Definitely, it would be an amazing addition to Blender. For some complex models, the Bevel Modifier with the Weights option could be a big limitation when making the final bevels of a model or some specific ones. Using the Bevel tool is a destructive way in native Blender, and in the case of using addons, you'll need to select all the loops to modify, something that becomes much simpler with the ability to select and modify "Edge Groups" in one or two clicks. It would be much better than Vertex Groups for beveling, because in many cases they bevel edges you don't want to.

So, to summarize, a new system of Edge Groups implemented in the Bevel Modifier would: create a much more efficient workflow, allow for complete non-destructive management of bevels, and provide an easier way for 3ds Max users to adapt to Blender.

I'm sure there would be many more benefits to implementing this feature in Blender than the ones I mentioned. That's why I hope the Blender Team implements this great feature. Cheers!

Definitely, it would be an amazing addition to Blender. For some complex models, the Bevel Modifier with the Weights option could be a big limitation when making the final bevels of a model or some specific ones. Using the Bevel tool is a destructive way in native Blender, and in the case of using addons, you'll need to select all the loops to modify, something that becomes much simpler with the ability to select and modify "Edge Groups" in one or two clicks. It would be much better than Vertex Groups for beveling, because in many cases they bevel edges you don't want to. So, to summarize, a new system of Edge Groups implemented in the Bevel Modifier would: create a much more efficient workflow, allow for complete non-destructive management of bevels, and provide an easier way for 3ds Max users to adapt to Blender. I'm sure there would be many more benefits to implementing this feature in Blender than the ones I mentioned. That's why I hope the Blender Team implements this great feature. Cheers!
Howard Trickey commented 2024-09-03 15:41:19 +02:00
Member
Copy Link

Hi Mike93,

The patch is now unbuildable because of the change in where libraries are. I can fix this if you like, but might be better if you merged a current main into your branch and made it build again.

Hi Mike93, The patch is now unbuildable because of the change in where libraries are. I can fix this if you like, but might be better if you merged a current main into your branch and made it build again.
Mike93 commented 2024-09-03 21:22:46 +02:00
Author
Contributor
Copy Link

Hi Howard,

I've merged the main as of today into my bevel-edge-attributes branch locally, but the changes are quite a bit bigger than I imagined. I think this PR needs to be rethought.

My comment here summarizes my original changes well, but they are not compatible with Blender's move to using stdlib/smart pointers/move semantics.

To boil this problem down to the simplest statement, on this line we need the ability to filter on an item's domain (edge, point, etc.). Then we will be able to filter the attributes dropdown list properly in the bevel modifier.

Hi Howard, I've merged the main as of today into my `bevel-edge-attributes` branch locally, but the changes are quite a bit bigger than I imagined. I think this PR needs to be rethought. My [comment here]([url](https://projects.blender.org/blender/blender/pulls/117366#issuecomment-1191230)) summarizes my original changes well, but they are not compatible with Blender's move to using stdlib/smart pointers/move semantics. To boil this problem down to the simplest statement, on [this line]([url](https://projects.blender.org/blender/blender/src/commit/324e1441a22e841d6bd674b27e0efd9bd2aeceee/source/blender/editors/interface/interface_utils.cc#L538)) we need the ability to filter on an item's domain (edge, point, etc.). Then we will be able to filter the attributes dropdown list properly in the bevel modifier.
Hans Goudey requested review from Hans Goudey 2024-09-03 21:34:24 +02:00
Howard Trickey commented 2024-09-03 21:35:57 +02:00
Member
Copy Link

Thanks Mike93. I am just checking that this means that I am waiting for an update from you before looking at this further. You only need reply if that's an incorrect assumption.

Thanks Mike93. I am just checking that this means that I am waiting for an update from you before looking at this further. You only need reply if that's an incorrect assumption.
Hans Goudey commented 2024-09-03 21:43:58 +02:00
Member
Copy Link

Hi, summarizing discussion in chat: This PR should not filter attributes based on domain or type. There are a few reasons for this:

  • Attribute inputs for geometry nodes don't filter attributes either. Attributes are meant to be referenced by name. Domains and data type are designed to be flexible and interpolated automatically.
  • Filtering attributes is currently complicated. Since this change is meant as a somewhat temporary solution until bevel can be ported to geometry nodes, we should aim to make the change as small as possible. Potential solutions to filtering generic attributes should be added in a general way (i.e. implemented by geometry nodes).

Implementing should be simple. All of the current UI code changes can be removed from the PR. Before the mesh is converted to a BMesh, the attribute API bke::AttributeAccessor can be used to read the attribute with the name stored in the modifier data with the float type and the vertex/edge domains. The attribute API will automatically interpolate the domain and convert the data type if necessary. In order to access the data with the bevel BMesh implementation, this data can be added as a new attribute on the input mesh before conversion to BMesh. This approach avoids the need to implement domain and type conversion for BMesh which would make the PR more complex.

Hi, summarizing discussion in chat: This PR should not filter attributes based on domain or type. There are a few reasons for this: - Attribute inputs for geometry nodes don't filter attributes either. Attributes are meant to be referenced by name. Domains and data type are designed to be flexible and interpolated automatically. - Filtering attributes is currently complicated. Since this change is meant as a somewhat temporary solution until bevel can be ported to geometry nodes, we should aim to make the change as small as possible. Potential solutions to filtering generic attributes should be added in a general way (i.e. implemented by geometry nodes). Implementing should be simple. All of the current UI code changes can be removed from the PR. Before the mesh is converted to a BMesh, the attribute API `bke::AttributeAccessor` can be used to read the attribute with the name stored in the modifier data with the float type and the vertex/edge domains. The attribute API will automatically interpolate the domain and convert the data type if necessary. In order to access the data with the bevel BMesh implementation, this data can be added as a new attribute on the input mesh before conversion to BMesh. This approach avoids the need to implement domain and type conversion for BMesh which would make the PR more complex.
Mike93 added 2 commits 2024-09-03 22:27:31 +02:00 
Updating branch to latest main. Dev on this branch
was ~8 months ago
All UI changes have been removed
We are sacrificing not having filtering on the dropdown because it is too complicated to add and does not align with the way that attribute dropdowns are intended to work with geonodes
Mike93 commented 2024-09-03 22:39:27 +02:00
Author
Contributor
Copy Link

Thanks for the discussion, Hans. This PR is considerably simpler now. See the last commit message.

A couple things that might be tuned up:

  1. The default bevel weight edge attribute is either bevel_weight_edge or bevel_weight_vert. These initially appear as red, since the attribute does not exist until you add some bevel weights to the model (the traditional way)
    image
  2. If you try to type in an attribute name that does not exist, the dropdown reverts to the last good value

I am still parsing this:

Implementing should be simple. All of the current UI code changes can be removed from the PR. Before the mesh is converted to a BMesh, the attribute API bke::AttributeAccessor can be used to read the attribute with the name stored in the modifier data with the float type and the vertex/edge domains. The attribute API will automatically interpolate the domain and convert the data type if necessary. In order to access the data with the bevel BMesh implementation, this data can be added as a new attribute on the input mesh before conversion to BMesh. This approach avoids the need to implement domain and type conversion for BMesh which would make the PR more complex.

If I understand correctly, you are suggested we add the attribute to the input mesh? I assume this does not modify the original mesh, only at the point of applying it would the edge attribute come into existence.

I'm not sure how this would play out with actually setting the edge attribute data in Edit mode - since that requires selecting the attribute from the mesh first.

Thanks for the discussion, Hans. This PR is considerably simpler now. See the last commit message. A couple things that might be tuned up: 1. The default bevel weight edge attribute is either `bevel_weight_edge` or `bevel_weight_vert`. These initially appear as red, since the attribute does not exist until you add some bevel weights to the model (the traditional way) <img width="371" alt="image" src="attachments/5dab1385-9015-4859-b076-6e14200f8f9c"> 2. If you try to type in an attribute name that does not exist, the dropdown reverts to the last good value I am still parsing this: > Implementing should be simple. All of the current UI code changes can be removed from the PR. Before the mesh is converted to a BMesh, the attribute API `bke::AttributeAccessor` can be used to read the attribute with the name stored in the modifier data with the float type and the vertex/edge domains. The attribute API will automatically interpolate the domain and convert the data type if necessary. In order to access the data with the bevel BMesh implementation, this data can be added as a new attribute on the input mesh before conversion to BMesh. This approach avoids the need to implement domain and type conversion for BMesh which would make the PR more complex. If I understand correctly, you are suggested we add the attribute to the input mesh? I assume this does not modify the original mesh, only at the point of applying it would the edge attribute come into existence. I'm not sure how this would play out with actually setting the edge attribute data in Edit mode - since that requires selecting the attribute from the mesh first.
image.png
27 KiB
Hans Goudey requested changes 2024-09-03 22:51:46 +02:00
Dismissed
Hans Goudey left a comment
Member
Copy Link

For the resetting of "invalid" attribute names after search, I would look into using the PROP_STRING_SEARCH_SUGGESTION option to disable this. As mentioned in chat, the red "invalid" error generally isn't correct because attributes can be added procedurally by previous modifiers. It could be that adding search to the UI button has to be done in a different way as well. If so, I'd look to the attribute search in the geometry nodes modifier for inspiration. Hopefully not though.

If I understand correctly, you are suggested we add the attribute to the input mesh?

Yes, the input mesh has already been copied though, that should be fine.

I'm not sure how this would play out with actually setting the edge attribute data in Edit mode - since that requires selecting the attribute from the mesh first.

Not sure what you mean, that's sort of orthogonal. This is just a method to make sure the BMesh implementation has access to an attribute with the "correct" domain and type, even if those are different on the input mesh.

For the resetting of "invalid" attribute names after search, I would look into using the `PROP_STRING_SEARCH_SUGGESTION` option to disable this. As mentioned in chat, the red "invalid" error generally isn't correct because attributes can be added procedurally by previous modifiers. It could be that adding search to the UI button has to be done in a different way as well. If so, I'd look to the attribute search in the geometry nodes modifier for inspiration. Hopefully not though. >If I understand correctly, you are suggested we add the attribute to the input mesh? Yes, the input mesh has already been copied though, that should be fine. >I'm not sure how this would play out with actually setting the edge attribute data in Edit mode - since that requires selecting the attribute from the mesh first. Not sure what you mean, that's sort of orthogonal. This is just a method to make sure the BMesh implementation has access to an attribute with the "correct" domain and type, even if those are different on the input mesh.
source/blender/editors/interface/interface_intern.hh Outdated
@ -1371,6 +1371,7 @@ uiBut *ui_but_add_search(uiBut *but,
PointerRNA *searchptr,
PropertyRNA *searchprop,
bool results_are_suggestions);
Hans Goudey commented 2024-09-03 22:43:54 +02:00
Member
Copy Link

Unnecessary whitespace changes

Unnecessary whitespace changes
HooglyBoogly marked this conversation as resolved
source/blender/makesrna/intern/rna_modifier.cc Outdated
@ -4832,0 +4847,4 @@
RNA_def_property_string_sdna(prop, nullptr, "edge_weight_name");
RNA_def_property_ui_text(prop, "Edge Attribute", "Edge weight attribute");
RNA_def_property_string_funcs(
prop, nullptr, nullptr, "rna_BevelModifier_edge_weight_name_set");
Hans Goudey commented 2024-09-03 22:47:43 +02:00
Member
Copy Link

Defining these rna_BevelModifier_edge_weight_name_set and rna_BevelModifier_vertex_weight_name_set functions functions shouldn't be necessary. The RNA system should generate them automatically.

Defining these `rna_BevelModifier_edge_weight_name_set` and `rna_BevelModifier_vertex_weight_name_set` functions functions shouldn't be necessary. The RNA system should generate them automatically.
Mike93 marked this conversation as resolved
source/blender/modifiers/intern/MOD_bevel.cc Outdated
@ -87,1 +88,4 @@
BevelModifierData *bmd = (BevelModifierData *)md;
if (bmd->vertex_weight_name == "") {
STRNCPY(bmd->vertex_weight_name, "bevel_weight_vert");
Hans Goudey commented 2024-09-03 22:46:12 +02:00
Member
Copy Link

The bevel modifier data itself shouldn't be modified here. It's constant from the perspective of modifier evaluation. The change in DNA_modifier_defaults.h should cover this.

The bevel modifier data itself shouldn't be modified here. It's constant from the perspective of modifier evaluation. The change in `DNA_modifier_defaults.h` should cover this.
Mike93 marked this conversation as resolved
source/blender/modifiers/intern/MOD_bevel.cc Outdated
@ -274,0 +286,4 @@
sub = uiLayoutColumn(col, false);
uiLayoutSetActive(sub, edge_bevel);
const char *weight_type = "edge_weight";
Hans Goudey commented 2024-09-03 22:46:52 +02:00
Member
Copy Link

const char *weight_type = edge_bevel ? "edge_weight" : "vertex_weight";

`const char *weight_type = edge_bevel ? "edge_weight" : "vertex_weight";`
Mike93 marked this conversation as resolved
Mike93 commented 2024-09-03 23:57:20 +02:00
Author
Contributor
Copy Link

I resolved all your comments - but will wait to push that commit for now.

I tinkered around with adding the attributes to the input Mesh to the bevel modifier, it has some issues.

In MOD_bevel.cc:

static Mesh *modify_mesh(ModifierData *md, const ModifierEvalContext *ctx, Mesh *mesh)
...
  BevelModifierData *bmd = (BevelModifierData *)md;
  blender::bke::MutableAttributeAccessor attributes = mesh->attributes_for_write();
  attributes.add<float>(bmd->vertex_weight_name, blender::bke::AttrDomain::Point, blender::bke::AttributeInitDefaultValue());
  attributes.add<float>(bmd->edge_weight_name, blender::bke::AttrDomain::Edge, blender::bke::AttributeInitDefaultValue());

Right now I am not checking for an existing attribute, but just blindly adding attributes to see what happens.

This does indeed add the attribute to the modifier's Mesh, we can confirm that by applying the modifier:
image
image

But unfortunately we are still getting the red text in the dropdown, because in panel_draw we are still just grabbing the object's data.attributes

static void panel_draw(const bContext * /*C*/, Panel *panel)
...
  PointerRNA ob_ptr;
  PointerRNA *ptr = modifier_panel_get_property_pointers(panel, &ob_ptr);
...
    PointerRNA object_data_ptr = RNA_pointer_get(&ob_ptr, "data");
    uiItemPointerR(col, ptr, weight_type, &object_data_ptr, "attributes", nullptr, ICON_NONE);

So we're checking if the original object has the attribute, and not the modifier's mesh. I'm not sure how to get access to the modifier's mesh (the modifier's object data).

As a secondary issue, this presents a workflow issue, because assuming all of this machinery worked (where the modifier will generate the attribute if it does not exist for the input mesh), the user has no way of setting attribute data on the modifier's mesh (see first screenshot).

They can't select an attribute that exists only for the temporary mesh of the modifier.

I resolved all your comments - but will wait to push that commit for now. I tinkered around with adding the attributes to the input `Mesh` to the bevel modifier, it has some issues. In `MOD_bevel.cc`: ``` static Mesh *modify_mesh(ModifierData *md, const ModifierEvalContext *ctx, Mesh *mesh) ... BevelModifierData *bmd = (BevelModifierData *)md; blender::bke::MutableAttributeAccessor attributes = mesh->attributes_for_write(); attributes.add<float>(bmd->vertex_weight_name, blender::bke::AttrDomain::Point, blender::bke::AttributeInitDefaultValue()); attributes.add<float>(bmd->edge_weight_name, blender::bke::AttrDomain::Edge, blender::bke::AttributeInitDefaultValue()); ``` Right now I am not checking for an existing attribute, but just blindly adding attributes to see what happens. This does indeed add the attribute to the modifier's Mesh, we can confirm that by applying the modifier: <img width="931" alt="image" src="attachments/6515538b-703d-4a4a-9f28-7fa54e054f05"> <img width="932" alt="image" src="attachments/18566d7b-fef4-49d6-93a5-02431ba6171d"> But unfortunately we are still getting the red text in the dropdown, because in `panel_draw` we are still just grabbing the object's `data.attributes` ``` static void panel_draw(const bContext * /*C*/, Panel *panel) ... PointerRNA ob_ptr; PointerRNA *ptr = modifier_panel_get_property_pointers(panel, &ob_ptr); ... PointerRNA object_data_ptr = RNA_pointer_get(&ob_ptr, "data"); uiItemPointerR(col, ptr, weight_type, &object_data_ptr, "attributes", nullptr, ICON_NONE); ``` So we're checking if the original object has the attribute, and not the modifier's mesh. I'm not sure how to get access to the modifier's mesh (the modifier's object data). As a secondary issue, this presents a workflow issue, because assuming all of this machinery worked (where the modifier will generate the attribute if it does not exist for the input mesh), the user has no way of setting attribute data on the modifier's mesh (see first screenshot). They can't select an attribute that exists only for the temporary mesh of the modifier.
image.png
151 KiB
image.png
133 KiB
Mike93 added 1 commit 2024-09-04 00:23:03 +02:00 
- Add the attributes to the modifier's input mesh
- Set search suggestions to true by verbosely calling uiItemPointerR_prop()
Hans Goudey added 13 commits 2024-09-04 04:33:01 +02:00
Hans Goudey added 1 commit 2024-09-04 04:34:12 +02:00
Adjust property names and tooltips
All checks were successful
buildbot/vexp-code-patch-lint Build done.
Details
buildbot/vexp-code-patch-linux-x86_64 Build done.
Details
buildbot/vexp-code-patch-darwin-x86_64 Build done.
Details
buildbot/vexp-code-patch-darwin-arm64 Build done.
Details
buildbot/vexp-code-patch-windows-amd64 Build done.
Details
buildbot/vexp-code-patch-coordinator Build done.
Details
cee352a6c0
Hans Goudey commented 2024-09-04 04:36:41 +02:00
Member
Copy Link

I hope it's okay that I updated the PR directly. It was simpler to do that than continue back and forth. If you have questions about any of my changes I'd be happy to explain. I basically implemented what I wrote above though. One thing I forgot was filtering out internal attributes.

The attribute inputs work the same way as geometry nodes inputs now. Attributes with non-float types are now automatically interpolated, and attributes with mismatched domains are automatically interpolated.

I hope it's okay that I updated the PR directly. It was simpler to do that than continue back and forth. If you have questions about any of my changes I'd be happy to explain. I basically implemented what I wrote above though. One thing I forgot was filtering out internal attributes. The attribute inputs work the same way as geometry nodes inputs now. Attributes with non-float types are now automatically interpolated, and attributes with mismatched domains are automatically interpolated.
❤️ 2
Hans Goudey commented 2024-09-04 04:36:52 +02:00
Member
Copy Link

@blender-bot build

@blender-bot build
Hans Goudey reviewed 2024-09-04 04:37:42 +02:00
Hans Goudey left a comment
Member
Copy Link

Approving this now, pending regression tests passing.

Approving this now, pending regression tests passing.
🚀 4
Hans Goudey requested review from Hans Goudey 2024-09-04 04:38:17 +02:00
Hans Goudey approved these changes 2024-09-04 04:38:24 +02:00
Hans Goudey changed title from UI: Add custom attribute edge groups for bevel modifier to Modifiers: Add custom attribute weight support to bevel modifier 2024-09-05 17:10:36 +02:00
Hans Goudey merged commit cc5ed48cd3 into main 2024-09-05 17:15:52 +02:00
xZaki commented 2024-09-10 17:31:49 +02:00
First-time contributor
Copy Link

Could you also look into adding custom attribute support to the Planar mode of the decimate modifier?

Could you also look into adding custom attribute support to the Planar mode of the decimate modifier?
😕 1 ❤️ 1
Hans Goudey commented 2024-09-10 17:39:01 +02:00
Member
Copy Link

For feature requests, please use https://rightclickselect.com
Thanks.

For feature requests, please use https://rightclickselect.com Thanks.
Christoph Lohr commented 2024-09-12 08:39:20 +02:00
First-time contributor
Copy Link

I'm not super familiar with these new attributes. How can i assign an edge to a specific attribute in the latest build?

I'm not super familiar with these new attributes. How can i assign an edge to a specific attribute in the latest build?
Hans Goudey commented 2024-09-12 14:19:23 +02:00
Member
Copy Link

Hi, for support, please check the links in https://www.blender.org/support/ (https://blender.stackexchange.com/).

Hi, for support, please check the links in https://www.blender.org/support/ (https://blender.stackexchange.com/).
Mike93 commented 2024-09-13 18:49:22 +02:00
Author
Contributor
Copy Link

I'm not super familiar with these new attributes. How can i assign an edge to a specific attribute in the latest build?

I did a short video here explaining how the feature works: https://youtu.be/Jc9kNCIOejU?t=120

Also, if you created a post on blender support I'd be happy to post it there as well.

> I'm not super familiar with these new attributes. How can i assign an edge to a specific attribute in the latest build? I did a short video here explaining how the feature works: https://youtu.be/Jc9kNCIOejU?t=120 Also, if you created a post on blender support I'd be happy to post it there as well.
Sign in to join this conversation.
Reviewers
No reviewers
Howard Trickey
Campbell Barton
Hans Goudey
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset System
Asset datablocks, libraries, browser and shelf

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
Backward and forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Viewport & EEVEE

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Wayland windowing on Unix

  
Interest
Workbench

  
Interest: X11

Xorg/X11 windowing

  
Legacy
Asset Browser Project

Archived

  
Legacy
Blender 2.8 Project

Archived

  
Legacy
Milestone 1: Basic, Local Asset Browser

Archived

  
Legacy
OpenGL Error

Archived

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Related to security, https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Module
Viewport & EEVEE

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Severity
High

  
Severity
Low

  
Severity
Normal

  
Severity
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

Archived

  
Type
Report

Archived

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Modeling
Assignees
Clear assignees
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#117366
No description provided.
Delete Branch "Mike93/blender:bevel-edge-attributes"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?