Attribute identification and semantics #97452

New Issue

Jacques Lucke · 2022-04-19T16:10:08+02:00

Jacques Lucke commented

2022-04-19 16:10:08 +02:00

We are in the process of unifying the geometry attribute system in Blender. To continue with that, we have to make a decision on how to deal with different kinds of attributes and their relations.

Attribute Kinds

Below is a list of the different kinds of attributes we know of. It's unknown whether there are more.

Custom named user defined attributes.
- Can have any type and domain.
- Example: my_mask a float attribute on the point domain.
Built-in attributes.
- Fixed domain, type and name.
- Example: position on meshes.
Anonymous attributes.
- Has no user defined name.
- Example: Selection output sockets in geometry nodes.
UI attributes.
- Are used for working with the geometry in the ui.
- Should not affect procedural operations or be exported.
  - That wouldn't match user expectations and make some optimizations harder (e.g. meshes generally would have to be reevaluated after a selection change).
- Should still be accessible from Python.
- Example: Mesh vertex selection.

Attribute Relations

Some higher level concepts have to store more than one piece of data for each element.
For example, each uv layer has to store the actual uv coordinate and a selection/pin state for each face corner.
Currently, this data is packed together into a single struct (MLoopUV).
This is not ideal because:

It needs a special attribute data type, just for this purpose.
Having a non-standard data type also means that it is harder to integrate with generic algorithm which expect to work on spans with raw data.
Generally, a SoA format should be preferred over AoS for attributes for performance reasons.

For these reasons, we want to split MLoopUV and similar types into separate attributes. There still has to be some relation between these attributes.

Proposal

How these design problems are solved mostly depends on how we want to identify attributes.

Traditionally, attributes in Blender were identified by Domain + CustomDataType + Name (whereby the name could be empty for some CustomDataTypes).
In the past year, we were working towards identifying attributes just by their Name.
- This simplifies using attributes quite a bit, because one does not have to specify domain + type all the time when an attribute is used.
- It's also a more common standard in other software and file formats.

There seem to be two main ways to move forward:

(A) Introduce a new AttributeKind enum
- This enum would be a bit like CustomDataType but it would only encode the semantics of an attribute (CustomDataType mixes the concepts of semantic and data type).
- Possible enum items would be ATTR_KIND_UI, ATTR_KIND_ANONYMOUS, ATTR_KIND_GENERIC, ATTR_KIND_UV_LAYER_PIN, ...
- With this enum, attributes would be identified by AttributeKind + Name.
- This is fairly non-standard and would complicate using attributes in code and maybe in the ui, because the name is not enough to identify an attribute (which was our goal previously).
(B) Encode Attribute Semantics in the Name
- In this case, attributes are still uniquely identified on a geometry just by their Name.
- The different attribute kinds are encoded in the name.
- We could introduce a reserved attribute name prefix for Blender (e.g. .).
  - Generally, Blender has full control over attributes in this namespace.
    - Attributes may be changed/removed/added however Blender wants.
    - Blender may choose to "stabilize" certain names/sub-prefixes so that external code can depend on them.
  - Blender can restrict access to these attributes depending on the context. For example, ui attributes cannot be used in procedural contexts.
  - Nodes that access attributes by name should show a warning or error when trying to use attributes in this namespace.
- Different sub-prefixes can be used for different semantics.
  - .a_ for anonymous attributes (e.g. .a_23425234).
  - .uv_pinned_ for uv layer pinning (e.g. .uv_pinned_UVMap, that corresponds to the UVMap layer).
  - .select_vertex for vertex selection
  - .sculpt_mask_vertex for masking in sculpt mode.
- Attribute relations are handled outside of the core attributes container (aka CustomData currently).
  - For example, adding a uv layer should also add the corresponding .uv_pinned_ layer (or it is only created when it's first used).
    - A rename uv-layer operator would have to rename all the related attributes.
    - Utility functions should make it easy to find all corresponding attributes based on their "base name".

Personally, I prefer option (B).

It's conceptually much simpler on the data level.
- Makes it easier to understand, debug and interface with for technical users.
- Non technical users are not expected to see these "weird" . attributes anyway.
Also it allows addons/node groups to use the same mechanism for "related attributes" that Blender uses itself.
It's much closer to what we have already, so the transition would be relatively straight forward.

We are in the process of unifying the geometry attribute system in Blender. To continue with that, we have to make a decision on how to deal with different kinds of attributes and their relations. ## Attribute Kinds Below is a list of the different kinds of attributes we know of. It's unknown whether there are more. * Custom named user defined attributes. * Can have any type and domain. * Example: `my_mask` a float attribute on the point domain. * Built-in attributes. * Fixed domain, type and name. * Example: `position` on meshes. * Anonymous attributes. * Has no user defined name. * Example: Selection output sockets in geometry nodes. * UI attributes. * Are used for working with the geometry in the ui. * Should not affect procedural operations or be exported. * That wouldn't match user expectations and make some optimizations harder (e.g. meshes generally would have to be reevaluated after a selection change). * Should still be accessible from Python. * Example: Mesh vertex selection. ## Attribute Relations Some higher level concepts have to store more than one piece of data for each element. For example, each uv layer has to store the actual uv coordinate and a selection/pin state for each face corner. Currently, this data is packed together into a single struct (`MLoopUV`). This is not ideal because: * It needs a special attribute data type, just for this purpose. * Having a non-standard data type also means that it is harder to integrate with generic algorithm which expect to work on spans with raw data. * Generally, a SoA format should be preferred over AoS for attributes for performance reasons. For these reasons, we want to split `MLoopUV` and similar types into separate attributes. There still has to be some relation between these attributes. ## Proposal How these design problems are solved mostly depends on how we want to identify attributes. * Traditionally, attributes in Blender were identified by `Domain + CustomDataType + Name` (whereby the name could be empty for some `CustomDataTypes`). * In the past year, we were working towards identifying attributes just by their `Name`. * This simplifies using attributes quite a bit, because one does not have to specify domain + type all the time when an attribute is used. * It's also a more common standard in other software and file formats. There seem to be two main ways to move forward: * (A) Introduce a new `AttributeKind` enum * This enum would be a bit like `CustomDataType` but it would only encode the semantics of an attribute (`CustomDataType` mixes the concepts of semantic and data type). * Possible enum items would be `ATTR_KIND_UI`, `ATTR_KIND_ANONYMOUS`, `ATTR_KIND_GENERIC`, `ATTR_KIND_UV_LAYER_PIN`, ... * With this enum, attributes would be identified by `AttributeKind + Name`. * This is fairly non-standard and would complicate using attributes in code and maybe in the ui, because the name is not enough to identify an attribute (which was our goal previously). * (B) Encode Attribute Semantics in the Name * In this case, attributes are still uniquely identified on a geometry just by their `Name`. * The different attribute kinds are encoded in the name. * We could introduce a reserved attribute name prefix for Blender (e.g. `.`). * Generally, Blender has full control over attributes in this namespace. * Attributes may be changed/removed/added however Blender wants. * Blender may choose to "stabilize" certain names/sub-prefixes so that external code can depend on them. * Blender can restrict access to these attributes depending on the context. For example, ui attributes cannot be used in procedural contexts. * Nodes that access attributes by name should show a warning or error when trying to use attributes in this namespace. * Different sub-prefixes can be used for different semantics. * `.a_` for anonymous attributes (e.g. `.a_23425234`). * `.uv_pinned_` for uv layer pinning (e.g. `.uv_pinned_UVMap`, that corresponds to the `UVMap` layer). * `.select_vertex` for vertex selection * `.sculpt_mask_vertex` for masking in sculpt mode. * Attribute relations are handled outside of the core attributes container (aka `CustomData` currently). * For example, adding a uv layer should also add the corresponding `.uv_pinned_` layer (or it is only created when it's first used). * A rename uv-layer operator would have to rename all the related attributes. * Utility functions should make it easy to find all corresponding attributes based on their "base name". Personally, I prefer option (B). * It's conceptually much simpler on the data level. * Makes it easier to understand, debug and interface with for technical users. * Non technical users are not expected to see these "weird" `.` attributes anyway. * Also it allows addons/node groups to use the same mechanism for "related attributes" that Blender uses itself. * It's much closer to what we have already, so the transition would be relatively straight forward.

Jacques Lucke commented

2022-04-19 16:10:08 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Jacques Lucke commented

2022-04-19 16:10:08 +02:00

Added subscriber: @JacquesLucke

Hans Goudey commented

2022-04-19 16:10:35 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2022-04-20 05:54:06 +02:00

Added subscriber: @Baardaap

Martijn Versteegh commented

2022-04-20 10:31:19 +02:00

Just to clarify: In option A) the linked layers would share the same name? Do I read that correctly?

I also prefer option B, with the added remark that we would need to male sure the maximum name length of 64 chars is dropped. Encoding subtypes in the name would make it easier for code to add subtypes for a specific task without needing to edit a global enum in a headerfile. Considering changing such an ENUM would probably cause a full recompile I would rather avoid that.

Just to clarify: In option A) the linked layers would share the same name? Do I read that correctly? I also prefer option B, with the added remark that we would need to male sure the maximum name length of 64 chars is dropped. Encoding subtypes in the name would make it easier for code to add subtypes for a specific task without needing to edit a global enum in a headerfile. Considering changing such an ENUM would probably cause a full recompile I would rather avoid that.

Jacques Lucke commented

2022-04-20 10:38:50 +02:00

In option A) the linked layers would share the same name? Do I read that correctly?

Yes correct.

with the added remark that we would need to make sure the maximum name length of 64 chars is dropped

That's right. At least for some of the use cases that is necessary. Just changing char[64] to char* sounds like a good option to me, We could keep the char[64] around for forward compatibility in theory, but actually maintaining forward compatibility with the proposed changes may prove to be tricky.

Encoding subtypes in the name would make it easier for code to add subtypes for a specific task without needing to edit a global enum in a headerfile. Considering changing such an ENUM would probably cause a full recompile I would rather avoid that.

I'm not too much concerned about a full recompile (vs. a partial recompile) since I don't expect that to happen very often. I do think it's good to avoid having a global enum for this though.

> In option A) the linked layers would share the same name? Do I read that correctly? Yes correct. > with the added remark that we would need to make sure the maximum name length of 64 chars is dropped That's right. At least for some of the use cases that is necessary. Just changing `char[64]` to `char*` sounds like a good option to me, We could keep the `char[64]` around for forward compatibility in theory, but actually maintaining forward compatibility with the proposed changes may prove to be tricky. > Encoding subtypes in the name would make it easier for code to add subtypes for a specific task without needing to edit a global enum in a headerfile. Considering changing such an ENUM would probably cause a full recompile I would rather avoid that. I'm not too much concerned about a full recompile (vs. a partial recompile) since I don't expect that to happen very often. I do think it's good to avoid having a global enum for this though.

Falk David commented

2022-04-20 10:59:49 +02:00

Added subscriber: @filedescriptor

Falk David commented

2022-04-20 10:59:49 +02:00

Maybe instead of the prefix, which feels a bit arbitrary, we could use the CustomDataLayer.flag and something like CD_FLAG_ATTR_BUILTIN or CD_FLAG_RESERVED?

Maybe instead of the prefix, which feels a bit arbitrary, we could use the `CustomDataLayer.flag` and something like `CD_FLAG_ATTR_BUILTIN` or `CD_FLAG_RESERVED`?

Jacques Lucke commented

2022-04-20 11:03:41 +02:00

Well, that is what option (A) is, with the described pros and const.

Falk David commented

2022-04-20 11:39:39 +02:00

But I don't think an enum to encode the semantics is the right choice. Using the name there feels a lot more logical. So I would still use e.g. select_ as the prefix, just unsure about the > (or whatever it might be in the end). But maybe that's not an issue.

But I don't think an enum to encode the semantics is the right choice. Using the name there feels a lot more logical. So I would still use e.g. `select_` as the prefix, just unsure about the `>` (or whatever it might be in the end). But maybe that's not an issue.

Jacques Lucke commented

2022-04-20 11:50:27 +02:00

How is having a flag vs having the enum different for you? In both cases attributes would have to be identified by Some Number + Name instead of just Name.
Obviously using something like a > prefix (for attributes the name of which users don't usually see) is not entirely pretty. So far I still think it's the best solution. But I could still change my mind in light of better arguments. When Hans and I discussed we were also on the fence about this exact topic.

[edit] In theory the prefix could just be skipped of course. The reason it's there is to make it less likely that there are name collisions with user generated attributes, especially when we add more of these "private attributes" over time.

How is having a flag vs having the enum different for you? In both cases attributes would have to be identified by `Some Number + Name` instead of just `Name`. Obviously using something like a `>` prefix (for attributes the name of which users don't usually see) is not entirely pretty. So far I still think it's the best solution. But I could still change my mind in light of better arguments. When Hans and I discussed we were also on the fence about this exact topic. [edit] In theory the prefix could just be skipped of course. The reason it's there is to make it less likely that there are name collisions with user generated attributes, especially when we add more of these "private attributes" over time.

Martijn Versteegh commented

2022-04-20 15:34:40 +02:00

The > prefix might not be ideal. But some other less common character (dare I say an 'escape code', i.e. char 27? Though for exporting it might be a bad idea to use unprintables ) would never clash with user typed names. I think it's a very nice property that a single key (the name) uniquely identiefies a layer. makes it easier to keep things in sync.

But it does need some extra string-scanning on layer rename to find dependant layers. So all in all it's not a great difference with the global enum.

On the one hand I agree that adding sublayers will probably not happen often. On the other hand when you are in the process of adding new layers and the code is still in a state of flux you can end up renaming stuff quite often. Speaking from experience here ;-).

The > prefix might not be ideal. But some other less common character (dare I say an 'escape code', i.e. char 27? Though for exporting it might be a bad idea to use unprintables ) would never clash with user typed names. I think it's a very nice property that a single key (the name) uniquely identiefies a layer. makes it easier to keep things in sync. But it does need some extra string-scanning on layer rename to find dependant layers. So all in all it's not a great difference with the global enum. On the one hand I agree that adding sublayers will probably not happen often. On the other hand when you *are* in the process of adding new layers and the code is still in a state of flux you can end up renaming stuff quite often. Speaking from experience here ;-).

Philipp Oeser commented

2022-04-21 16:48:08 +02:00

Added subscriber: @lichtwerk

Brecht Van Lommel commented

2022-04-25 17:36:06 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2022-04-25 17:36:06 +02:00

Am I understanding correctly that this proposal does not add any distinction between builtin and custom attributes (that's not already there)? I'm fine with that if so, it seems convenient if users don't have to worry about attributes kinds in geometry nodes, even if there can be occasional naming conflicts.
I'm wondering if it's worth following some existing convention for familiarity. Leading . is common for hiding things. USD has a concept of namespaces with names like namespace:attr. Starting with > seems a bit weird to me, but also I guess is unlikely to clash with existing names from .blend or other files. FWIW I think primvar (=attribute) names in USD are restricted like this:.

An identifier is valid if it follows the C/Python identifier convention; that is, it must be at least one character long, must start with a letter or underscore, and must contain only letters, underscores, and numerals

In the Python API, would users even be expected to be aware of these special names? Or would we provide convenient access like mesh.positions or mesh.vertex_selection? And then looping over the full attributes you could still discover them, but it would not be recommended to use e.g. mesh.attributes['>select_vertex'].
Pinned UVs effectively exist for only one UV map right now, since they go along with a set of seams and there is only one seam attribute. Supporting having both per UV map is nice but I think not important at all. I'm not sure if there are other current or planned features that would need such associations between attributes, if not it may not be worth the code complexity to try to solve this.
Pinned UVs could potentially not be UI data if a UV unwrap node takes them into account.

* Am I understanding correctly that this proposal does not add any distinction between builtin and custom attributes (that's not already there)? I'm fine with that if so, it seems convenient if users don't have to worry about attributes kinds in geometry nodes, even if there can be occasional naming conflicts. * I'm wondering if it's worth following some existing convention for familiarity. Leading `.` is common for hiding things. USD has a concept of namespaces with names like `namespace:attr`. Starting with `>` seems a bit weird to me, but also I guess is unlikely to clash with existing names from .blend or other files. FWIW I think primvar (=attribute) names in USD are restricted like this:. > An identifier is valid if it follows the C/Python identifier convention; that is, it must be at least one character long, must start with a letter or underscore, and must contain only letters, underscores, and numerals * In the Python API, would users even be expected to be aware of these special names? Or would we provide convenient access like `mesh.positions` or `mesh.vertex_selection`? And then looping over the full attributes you could still discover them, but it would not be recommended to use e.g. `mesh.attributes['>select_vertex']`. * Pinned UVs effectively exist for only one UV map right now, since they go along with a set of seams and there is only one seam attribute. Supporting having both per UV map is nice but I think not important at all. I'm not sure if there are other current or planned features that would need such associations between attributes, if not it may not be worth the code complexity to try to solve this. * Pinned UVs could potentially not be UI data if a UV unwrap node takes them into account.

Martijn Versteegh commented

2022-04-25 19:18:47 +02:00

In reply to Brechts 3d+4th point.

The current (protoype) patch for splitting MLoopUV currently translates stuff back the way it was in the python interface. I.E. from the python side it looks like the MLoopUV struct still exists. But the attributes are also available in the normal attribute api, so both ways of accessing would currently work.
If we have this working it would be trivial I think to add the seam attribute to the list of dependent layers for UV so you would have a seam attribute per UV layer, exactly like the 3 bool layers are now.

In reply to Brechts 3d+4th point. - The current (protoype) patch for splitting MLoopUV currently translates stuff back the way it was in the python interface. I.E. from the python side it looks like the MLoopUV struct still exists. But the attributes are also available in the normal attribute api, so both ways of accessing would currently work. - If we have this working it would be trivial I think to add the seam attribute to the list of dependent layers for UV so you would have a seam attribute per UV layer, exactly like the 3 bool layers are now.

Brecht Van Lommel commented

2022-04-25 19:52:51 +02:00

In #97452#1346325, @Baardaap wrote:

The current (protoype) patch for splitting MLoopUV currently translates stuff back the way it was in the python interface. I.E. from the python side it looks like the MLoopUV struct still exists. But the attributes are also available in the normal attribute api, so both ways of accessing would currently work.

Yes, we would keep API compatibility. But what I'm wondering is what would recommend for API users. For UI attributes, just keep using the existing API as the most convenient method?

If we have this working it would be trivial I think to add the seam attribute to the list of dependent layers for UV so you would have a seam attribute per UV layer, exactly like the 3 bool layers are now.

I can see how it would work, it's just not clear to me that the code complexity and risks for things going out of sync is worth it.

> In #97452#1346325, @Baardaap wrote: > - The current (protoype) patch for splitting MLoopUV currently translates stuff back the way it was in the python interface. I.E. from the python side it looks like the MLoopUV struct still exists. But the attributes are also available in the normal attribute api, so both ways of accessing would currently work. Yes, we would keep API compatibility. But what I'm wondering is what would recommend for API users. For UI attributes, just keep using the existing API as the most convenient method? > - If we have this working it would be trivial I think to add the seam attribute to the list of dependent layers for UV so you would have a seam attribute per UV layer, exactly like the 3 bool layers are now. I can see how it would work, it's just not clear to me that the code complexity and risks for things going out of sync is worth it.

Martijn Versteegh commented

2022-04-25 21:35:44 +02:00

I can see how it would work, it's just not clear to me that the code complexity and risks for things going out of sync is worth it.

Oh, the seam layer is edge-data probably? That would mean a dependency across a domain. I can see that being more of a hassle indeed. Though the 'keeping stuff in sync' would only mean to handle layer renames/deletes, so not too complicated I'd think.

> I can see how it would work, it's just not clear to me that the code complexity and risks for things going out of sync is worth it. Oh, the seam layer is edge-data probably? That would mean a dependency across a domain. I can see that being more of a hassle indeed. Though the 'keeping stuff in sync' would only mean to handle layer renames/deletes, so not *too* complicated I'd think.

Jacques Lucke commented

2022-04-26 10:43:49 +02:00

Am I understanding correctly that this proposal does not add any distinction between builtin and custom attributes (that's not already there)?

That's correct.

I'm wondering if it's worth following some existing convention for familiarity. Leading . is common for hiding things.

I'm not particularly attached to using >. Using . is fine as well, there just might be a larger risk that people are using that prefix for other purposes as well, because it is a more common convention.

In the Python API, would users even be expected to be aware of these special names?

I think we'd generally recommend using properties we provide for convinience as you suggest.

Pinned UVs effectively exist for only one UV map right now, since they go along with a set of seams and there is only one seam attribute. Supporting having both per UV map is nice but I think not important at all. I'm not sure if there are other current or planned features that would need such associations between attributes, if not it may not be worth the code complexity to try to solve this.

I'm also not aware of other cases where associated attributes are needed, but I wouldn't rule it out. Either way, I think in cases where we do want to support it, just matching them by name seems reasonably straight forward to me. Given that all attributes are identified by name, it would also be fairly easy to debug issues when stuff goes out of sync for some reason.

Pinned UVs could potentially not be UI data if a UV unwrap node takes them into account.

Didn't think too much about how that would be used. Do you mean that a UV unwrap nodes just updates the uvs for unpinned face corners? Seems reasonable, but I'd expect that to be a normal selection in geometry nodes, and not a special built-in or associated attribute.

> Am I understanding correctly that this proposal does not add any distinction between builtin and custom attributes (that's not already there)? That's correct. > I'm wondering if it's worth following some existing convention for familiarity. Leading `.` is common for hiding things. I'm not particularly attached to using `>`. Using `.` is fine as well, there just might be a larger risk that people are using that prefix for other purposes as well, because it is a more common convention. > In the Python API, would users even be expected to be aware of these special names? I think we'd generally recommend using properties we provide for convinience as you suggest. > Pinned UVs effectively exist for only one UV map right now, since they go along with a set of seams and there is only one seam attribute. Supporting having both per UV map is nice but I think not important at all. I'm not sure if there are other current or planned features that would need such associations between attributes, if not it may not be worth the code complexity to try to solve this. I'm also not aware of other cases where associated attributes are needed, but I wouldn't rule it out. Either way, I think in cases where we do want to support it, just matching them by name seems reasonably straight forward to me. Given that all attributes are identified by name, it would also be fairly easy to debug issues when stuff goes out of sync for some reason. > Pinned UVs could potentially not be UI data if a UV unwrap node takes them into account. Didn't think too much about how that would be used. Do you mean that a UV unwrap nodes just updates the uvs for unpinned face corners? Seems reasonable, but I'd expect that to be a normal selection in geometry nodes, and not a special built-in or associated attribute.

Erindale commented

2022-04-26 12:22:10 +02:00

Added subscriber: @Erindale

Bastien Montagne commented

2022-04-26 12:23:04 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2022-04-26 12:23:04 +02:00

Regarding the original main question, I am fine with encoding the semantic in names, as suggested in option (B).

I would also favor following some already reasonable standard (like the one from USD as suggested by @brecht) when it comes to what we consider valid names, and syntax for things like namespace/'hidden' values. I do not see much added value to having our own here, besides potential extra hassle when converting to other formats (like USD).

Regarding the original main question, I am fine with encoding the semantic in names, as suggested in option (B). I would also favor following some already reasonable standard (like the one from USD as suggested by @brecht) when it comes to what we consider valid names, and syntax for things like namespace/'hidden' values. I do not see much added value to having our own here, besides potential extra hassle when converting to other formats (like USD).

Trung Phạm commented

2022-04-26 12:23:21 +02:00

Added subscriber: @zNight

Brecht Van Lommel commented

2022-04-26 19:56:41 +02:00

In #97452#1346719, @JacquesLucke wrote:
I'm also not aware of other cases where associated attributes are needed, but I wouldn't rule it out. Either way, I think in cases where we do want to support it, just matching them by name seems reasonably straight forward to me. Given that all attributes are identified by name, it would also be fairly easy to debug issues when stuff goes out of sync for some reason.

The implementation is probably not so bad. For this to be actually useful it would also need per UV map seams which I guess is the more complex part to implement. It just seems unnecessary to me, but I might be missing practical use cases.

Didn't think too much about how that would be used. Do you mean that a UV unwrap nodes just updates the uvs for unpinned face corners? Seems reasonable, but I'd expect that to be a normal selection in geometry nodes, and not a special built-in or associated attribute.

Yes, UV unwrap would only updated unpinned UVs, and the pinned ones influence the position and shape of the rest of the UV island. This is more theoretical as procedural workflows and are not as likely to use pinning. The attribute is no more special than seams.

> In #97452#1346719, @JacquesLucke wrote: > I'm also not aware of other cases where associated attributes are needed, but I wouldn't rule it out. Either way, I think in cases where we do want to support it, just matching them by name seems reasonably straight forward to me. Given that all attributes are identified by name, it would also be fairly easy to debug issues when stuff goes out of sync for some reason. The implementation is probably not so bad. For this to be actually useful it would also need per UV map seams which I guess is the more complex part to implement. It just seems unnecessary to me, but I might be missing practical use cases. > Didn't think too much about how that would be used. Do you mean that a UV unwrap nodes just updates the uvs for unpinned face corners? Seems reasonable, but I'd expect that to be a normal selection in geometry nodes, and not a special built-in or associated attribute. Yes, UV unwrap would only updated unpinned UVs, and the pinned ones influence the position and shape of the rest of the UV island. This is more theoretical as procedural workflows and are not as likely to use pinning. The attribute is no more special than seams.

Jacques Lucke commented

2022-04-26 21:59:03 +02:00

I changed the proposal to use . instead of >. I left the "pinned uv" part in, just as a demonstration for how associated attributes could work, in case we decide to use them in the future.

I changed the proposal to use `.` instead of `>`. I left the "pinned uv" part in, just as a demonstration for how associated attributes could work, in case we decide to use them in the future.

Hans Goudey commented

2022-05-04 10:21:09 +02:00

Here are some UI attributes that we'll need in the near future (this week?) for curves:

.selection_float_point
.selection_bool_point
.selection_bool_curve

Edit: "Mask" is now just called selection too, to unify the concepts between modes.

Here are some UI attributes that we'll need in the near future (this week?) for curves: - `.selection_float_point` - `.selection_bool_point` - `.selection_bool_curve` Edit: "Mask" is now just called selection too, to unify the concepts between modes.

Martijn Versteegh commented

2022-05-07 22:39:07 +02:00

I left the "pinned uv" part in, just as a demonstration for how associated attributes could work, in case we decide to use them in the future.

Maybe better to use vertex_selection and edge_selection as example. As those are clear-cut examples of a case of associated attributes. We need vertex_selection and edge_selection with each uv map. At least if we want to keep the selection behaviour the same as it is in current blender versions where all three bools are packed in with the MLoopUV struct and the selection status is preserved when switching uv maps.

> I left the "pinned uv" part in, just as a demonstration for how associated attributes could work, in case we decide to use them in the future. Maybe better to use vertex_selection and edge_selection as example. As those are clear-cut examples of a case of associated attributes. We need vertex_selection and edge_selection with each uv map. At least if we want to keep the selection behaviour the same as it is in current blender versions where all three bools are packed in with the MLoopUV struct and the selection status is preserved when switching uv maps.

blender-admin commented

2022-05-09 11:58:53 +02:00

This issue was referenced by 9913196470

This issue was referenced by 9913196470e614ab65785fcf3bb18723906e468d

Jacques Lucke commented

2022-10-20 15:17:07 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2022-10-20 15:17:07 +02:00

Jacques Lucke self-assigned this 2022-10-20 15:17:07 +02:00

Hans Goudey referenced this issue

2023-02-28 19:41:41 +01:00