SOLVED Check vertex changes on a VertexMapTag


I'm watching a VertexMapTag, and want to know when the user updated the vertices weights.
GetDirty( DIRTYFLAGS_DATA ) does not change
GetHDirty( HDIRTYFLAGS_TAG ) does not change
Do I actually need to compare vertex by vertex?

btw, when I paint a VertexColorTag, I can rely on either DIRTYFLAGS_DATA and HDIRTYFLAGS_TAG, I was expecting the same on the VertexMapTag.


Hi Roger, thanks for reaching us.

With regard to your issue, we have to operate a distinction on how VertexMap can be created:

  1. via the Live Selection tool and switching mode to Vertex Painting;
  2. via the Paint Tool and switching the Paint Mode to Vertex Map.

Aside from this difference, it should also be noted that beside both inherits from VariableTag, the VertexMapTag has a more primitive implementation with raw getter/setter methods directly accessing to the data owned by the tag whilst the VertexColorTag provides a better implementation with regard to how data is accessed and data changes managed.

Using the Live Selection tool to paint VertexMap doesn't, as you already confirmed, bring any change to the tag dirtiness and hence changes to data are "invisible" to you that's because the tool is directly using the VertexMapTag. Using instead the Paint Tool, the VertexMapTag is created upon painting the VertexColorTag and the changes brought to the map properly notified via the changed dirty counter.

So far I would not consider it as a bug but more as a limitation of the initial vertex map creation implementation.

Best, Riccardo

@r_gigante thanks for explaining this workflow, and how the vertex tag is implemented.

For my case, I discovered it's easier and safer to listen to the tag's object (when I update the tag it will invalidate a dependency list it's in), then sum all the values to detect changes, for either vertex map and color. This works well for undos too, because if I make several paintings in a row and start undoing one by one, the DIRTYFLAGS_DATA and HDIRTYFLAGS_TAG are not very reliable. They come down on the first undo, but stay with the same value on subsequent undos.