This patch adds domain and data type information to each row of the
attribute search menu. The data type is displayed on the right, just
like how the list is exposed for the existing point cloud and hair
attribute panels. The domain is exposed on the left like the menu
hierarchy from menu search.
Details
Diff Detail
- Repository
- rB Blender
- Branch
- geometry-nodes-attribute-search-data (branched from master)
- Build Status
Buildable 14045 Build 14045: arc lint + arc unit
Event Timeline
@Hans Goudey (HooglyBoogly) What about (socket color)[category] -> name [Domain]? Did you get to try that?
We talked about this and agreed on:
- Wait until spreadsheet implements access to the categories to be able to easily use it here.
- Expose more built-in attributes that work in different domains other than point.
- Then have both options for the team to test
- The original design
- The variation where the domain is presented in the left side.
Since there's also some uncertainty / disagreement about design for exposing the "Category", I think it also makes some time to let that sit before moving forward here.
Anyway, there are bugs with the current patch, so planning changes here anyway.
- Merge branch 'master' into geometry-nodes-attribute-search-data
- Remove commented code
- Enable the exec function (search won't work at the moment)
I have the necessary changes to make this work right here: P2060 I'll try to get feedback from other UI developers before going further with that though
- Remove unecessary butstore stuff
- Use solution to search button problem from Julian
- Small comment cleanup
I don't know why, but somehow this breaks the normal node search. It always inserts an Attribute Clamp node for me now.
| source/blender/editors/space_node/node_geometry_attribute_search.cc | ||
|---|---|---|
| 67 | nullptr, same below. | |
| source/blender/editors/interface/interface_templates.c | ||
|---|---|---|
| 314 | bool and pointer seem mixed up here? | |
| source/blender/editors/space_node/node_geometry_attribute_search.cc | ||
| 149 | Just use MAX_NAME. | |
| 176–178 | When UI code frees this later it will use regular MEM_freeN(), so this won't call the destructor. I'd suggest either also calling MEM_mallocN() here directly, or clearly documenting that AttributeSearchData must not have a destructor! The third possibility is bringing back the MEM_dupallocN(). | |
| source/blender/editors/interface/interface_templates.c | ||
|---|---|---|
| 314 | Good catch. | |
| source/blender/editors/space_node/node_geometry_attribute_search.cc | ||
| 176–178 | Good points. I think I'll go with the documentation option, since that way:
| |
- Add dummy available attribute info to store temporary button string
This isn't the prettiest thing, but it solves a significant problem, since the exec callback
needs information for when you type in a name of a new attribute or an attribute that the
search doesn't know about. I tried approaching this another way, by giving a callback to
the exec function with the current string from the button, but I think that's far more hacky.
For the records, that attempt is here:
| source/blender/blenkernel/BKE_node_ui_storage.hh | ||
|---|---|---|
| 88 | Use the blender::get_default_hash function. | |
| 99 | Right now this does not handle the case when the same attribute exists on multiple domains (that is possible when there are instances). One simple solution for now would be to always display the domain with the most information, because that is the attribute that would remain after making it real. Note that this does not always work once we have curves, but it's good enough for now. | |
| source/blender/editors/space_node/node_geometry_attribute_search.cc | ||
| 50 | You could make this more explicit with a static assert that checks for std::is_trivially_destructible_v. | |
@Hans Goudey (HooglyBoogly) I find it quite hard to read the datatype of the selected attribute:
Maybe use the same color as the domain so it shows white when highlighted?
(note to patch, remember once the patch is in to add an image of it in the release notes)
| source/blender/blenkernel/BKE_node_ui_storage.hh | ||
|---|---|---|
| 99 | Thanks. IIRC the reason to use a set here was to make sure each item could be discrete. (mostly writing that as a reminder to myself) Another option would be to just add multiple items to the set for different attributes. I think that's probably nicer if we ever use the attribute hint information to automatically set data type and domain enums. I know Dalai mentioned that for the attribute processor. I'd like to deal with that as a separate change, I hope that's okay with you. | |
| source/blender/editors/space_node/node_geometry_attribute_search.cc | ||
| 50 | Good idea! | |
I tried icons with an earlier version of this patch:
There are a few issues with it:
- We refer to domains by name in other places, so it's not as clear what the meaning is with only icons
- We don't have a cohesive set of good looking icons for attribute domains, so it looks wonky
- I'm not sure about the consistency argument, we have plenty of search items without icons
- We have plenty of space in the search box for the name of the domain instead, it also mirrors the data type text design
I do sort of like the icons, but not enough to overcome those issues IMO.





