split by map

[illmillrig]

Hey, we were looking at implementing this but wanted to check if you had already started it. If not, do you have any suggestions or tips for how best to go about it?

thanks

[tbttfox]

The first thing is getting the maps storing in both the maya file, and the .abc file. And getting the file IO between them up and running. You'll have to work with the Maya and Dummy interface layers so that the simplex object hierarchy can parse that map data, and set it to the Falloff objects. The .abc is easy. I'd add a compound property called 'maps' or 'falloffs' or something like that, then all the sub-properties would, of course, be the maps with their given names. In maya, I'd probably use paintable doubleArray attr's on the mesh, but I haven't really dug into how that user workflow would work.

Then, of course, there will have to be UI code that triggers the creation/deletion/renaming of the correct maya objects/attrs/whatevers. When changing Falloff type, it should probably check for non-empty maps, and pop up a warning if you try to change away from a map type.

All that done, once the data is accessible in the Falloff object, there shouldn't be many changes to the actual splitting code. Linear falloffs are already baked down to maps for the code application, so it's already built to handle map splitting, it just never had the data available.

[illmillrig]

So we have a somewhat basic implementation of this. For right now, we're avoiding creating any maps in the dcc when loading simplex. I'm not sure if there is a good way to sync the weights on the mesh's weight map attr and the weights in the falloff object. I think an attr callback might be too slow.

Also, maya is appearing to be somewhat silly in regards to paintable attrs. It seems to be a global list that persists between sessions. see cmds.makePaintable(). So I modified the falloffDialog with some options for generating the map in the dcc, and capturing the map weights. It's not ideal, but I think it will suffice for right now.

I wanted to get your thoughts on the falloff objects itself though. right now, it's one object with two split types. But changing split types using setPlanarData() or setMapData() does some state management to the object. It's a bit destructive right now when we switch the splitType back and forth between planar and map.

So I'm thinking it might be best to have two separate falloff objects, and you pick one when creating a falloff, instead of allowing the user to change splitTypes after creation.

Also, I think I'm gonna need to implement multi-splitting. We're using a map to split mouth shapes top and bottom, but we'll also wanna split those shapes left and right. For right now, we'll just do the top and bottom splits first, then split left and right. But I wonder if there is a good way of doing this all at once.

Thanks

[tbttfox]

It doesn't have to sync the weight with the Falloff object in real time. Since the Falloff is only used during the split process, you only have to capture that data when writing the system to .smpx. And yeah, makePaintable sucks :(

Also, multi-splitting should already be implemented. The right-click falloff selection menu has checkboxes specifically to allow you to check multiple falloffs. You just have to make sure the name of the shapes to split has both _X_ and _V_ in the name (I think ... check the Falloff code for the global variables that indicate the different split directions)

[illmillrig]

ah yeah, that makes sense. I'll look into it a bit further.

that's great about multi splitting. I wondered if you had it in there, but didn't check yet.

Thanks!

[illmillrig]

so I've implemented this with the 'maps' being float array attrs in maya. like the weights attr on a deformer node. But now that I read your suggestions a few times, i'm wondering if you were intending for these to be 'image maps'? lol

[tbttfox]

I was thinking float arrays

[illmillrig]

ok cool. Then that's pretty much what I have right now. Although I think I have the weights being saved into the definition also, which then of course gets saved into the abc on export. but you're saying just add them to the abc and leave them out of the definition. that makes sense. thanks!

[tbttfox]

Yeah, for writing the .abc, I think it's gonna use from alembic.Abc import OFloatArrayProperty to store the data