I don't have sub-meshes. My use case is that I have a large and complex mesh, but only a small part need MagicaCloth. Since the paint vertex texture is only 128x128, it's impossible to properly paint that small part with it. The resolution is just not enough. So I'd like to make a second UV set (TEXTCOORD1) where the small part takes the whole uv space and other vertices at (0, 0). I actually made it work by modifying the source code. I added a uv1 field to VirtualMesh, collected uv data like you did, and an option to toggle between uv and uv1. But of course it's hacky and I will have to merge the code myself when you release a newer version of MagicaCloth... Another potential solution to this is to allow a big paint vertex texture, not limiting it to 128x128. Since you've already planned to make the bake feature, a large texture won't be an issue once the user can just sample it in editor and bake the attributes onto vertices, without affecting runtime performance. I don't think it's a problem that users need to use a modeling tool. The bigger potential problem is that vertex color is a "scarce resource", cause one vertex can have only one color. The end user might already been using vertex color for a completely unrelated purpose (e.g. red channel as outline width for a GGST-like anime shader), and there will be a conflict. I'm not so sure if it's a good idea to "spend" this resource on painting vertex attributes. Maybe it should use only 1 channel. Instead of red means fixed and green means movable, make it like red channel = 0 means fixed and red channel = 1/256 means movable, to mitigate the impact. But to be honest, what I really wish to have is the ability to control mesh reduction with texutre and/or vertex color. e.g. higher red channel value is, the less likely a vertex to be reduced, and red = 1 means it's never reduced and always present in the proxy mesh... something like that.