Support import/export of custom attributes Maya.

[bhouston]

Requested by a number of users on the Exocortex-Alembic mailing list.

[takita]

Go Ben! :)

-T

On Thu, Dec 11, 2014 at 3:26 PM, Ben Houston notifications@github.com wrote:

Requested by a number of users on the Exocortex-Alembic mailing list.

— Reply to this email directly or view it on GitHub https://github.com/Exocortex/ExocortexCrate/issues/2.

[holypraal]

This is indeed a needed feature. At work we are starting to switch from our robust but aging format to Exocortex Alembic and this feature will be needed down the road. However I have good hopes I'll be able to sell this feature to management in a few month. Maybe not all (you said around $8K CAD in the mailing list) but I post now to test the water and see if anyone would be interested in co-producing this feature. Thanks for your hard work !

[AWhetter]

I'm looking at implementing this but there's going to be a lot of shared functionality between Crate and AbcExport because it's almost the same process for both. We can almost just use the AttributesWriter from AbcExport, other than the fact that Alembic does it's visibility exporting here where Crate does it elsewhere and that JobArgs is passed into AttributesWriter in AbcExport whereas Crate has it's arguments in an AlembicWriteJob.

If we don't use AttributesWriter there's still a lot of shared functionality in the methods provided by MayaUtility.cpp and some of the other methods in AttributesWriter.cpp.

So my question is how best can we go about sharing this code?

[bhouston]

I would totally bring in AttributesWriter in this project and modify it as need be if that is possible -- it doesn't change much, if at all, so I think that modifying it to fit into the context of this project is a good idea.

[AWhetter]

I'm still working on this and it's coming along well. One point that's come up though is that AttributesWriter uses the MFnFloatArrayData.h header which was only available in Maya versions >= 2013.5. So using it as-is means that Maya versions below that would no longer be supported. I think though, that I could wrap attribute writing in ifdefs and make it configurable (I'd need to do a little fudging in the CMakeLists as well but that's easy enough). If that doesn't sound like a good solution or if that doesn't work, then it's not a priority for us because we don't use Maya versions that old so I probably won't be able to put in more time to get older versions working.

[bhouston]

I am find leaving functionality out of Maya 2013.5 and later -- remember that was released in 2012, four years ago.

[AWhetter]

So attribute importing is turning out to be slightly more fiddly than exporting. The problem is that when the alembic file path or the identifier on an ExocortexCrate node is updated, the list of attributes may change, and therefore the attributes on the node must change and the connections also.

Because we can't edit a node's attributes and connections from within the node, we can't just use the if (fileName != mFileName || identifier != mIdentifier) currently in compute and update the attributes on the node. Instead the changes must happen outside the node.

Our current plan is to add a static "ExocortexAlembic Attribute List" attribute for each variable type to Exocortex nodes (We could also just have a single list that specifies the type and name of each attribute). The attributes depend on the "file name" and "identity" attributes so that it gets reevaulated in compute when they change.

In the Python code attachTimeAndFile will first look at the attribute lists and remove all listed attributes from the node. The filename and time then get updated. The Python code then gets the attribute list again (causing the node to reevaluate it's attribute lists) so that the code knows what custom attributes to add. It then does that, and connects up the attributes (checking that they match and are of the same type and printing warnings as necessary).

The next reevaluation of the custom attributes will then cause the node to update the values.

[AWhetter]

Actually I've just looked at the list of possible attribute types that we could import and I'll with a single "ExocortexAlembic Attribute List" attribute, rather than one for each type.

[holypraal]

This is an excellent news !

I don't the knowledge to help with the C++ plugin update (nor the time to learn it :/) but I'm very familiar with python scripting and maya node graph recreation/update. So if you need a hand I could help on this side.

One down side of the "delete all attrs and recreate them" way is that you lose all connections made on it. For example (a lame one I admit) if you had a light controlled by some attribute the animator animated, you would have to reconnect it after each update. Unless you add another layer in the reload script that backs up the connections and recreates them, but it seems simpler to only recreate the missing attributes and delete the outdated ones.

[AWhetter]

The script will reconnect the attributes. That's what it is doing at the moment anyway for the static attributes so doing it for the dynamic attributes will be trivial. We did think about only creating new attributes and deleting old attributes instead of "just deleting everything and recreating it all", but we'd have to keep track of the attributes we did have and the attributes now needed and do comparisons between the two lists using either sets or "visited" dictionaries, etc etc. It seemed like there wouldn't be any gains (in performance or simplicity) to doing it that way, which is why we opted to just remove all custom attributes and re-add them all.

[holypraal]

Being only TD/dev in my company, I rarely have the occasion to reflect with someone on technical decisions, thanks for the details. Good luck !

[AWhetter]

@bhouston Fixed in #46!