Hi Marcus, I don't use ATOM as it's always had pipeline issues that were not addressed, and like many I guess we rolled our version, before ATOM and stuck with it, its old now so I've had this Github library on my list of things to look at. It's written by a team with a decent track record. https://github.com/Toolchefs/kiko
Hopefully, it's useful to your research. -Dave On Sunday, 2 August 2020 17:24:54 UTC+1, Marcus Ottosson wrote: > > Hi all, > > I’m about to embark on what is effectively a rewrite of the Maya-native > animation import/export format “ATOM” based on a few facts that I’m hoping > you can disprove. > > 1. ATOM import cannot be undone (as it relies on cmds.file(i=True)) > 2. ATOM cannot import animation to HumanIK controls > 3. ATOM cannot export animation from HumanIK controls reliably > 4. ATOM does not have a Python API, but relies on cmds.file for > passing options to a MEL command > > No Undo > > (1) is rather self-explanatory. Is there any other way to import ATOM > without using cmds.file? Or any way of preserving undo? I think not. > Cannot Import > > (2), this seems to only be an issue with the HumanIK Maya integration. > > Try it for yourself. > > 1. Load a HumanIK example, e.g. C:\Program > > Files\Autodesk\Maya2018\Examples\Animation\Rigs\rp_antonia_rigged_HIK_arnold.ma > > 2. Key any control, e.g. rp_antonia_rigged_Ctrl_HipsEffector > 3. Export with ATOM, using any settings you’d like > 4. Delete All By Type -> Channels > 5. Import the ATOM using any settings you’d like > 6. Fail > > Autodesk would like for you to go here > <http://www.autodesk.com/maya-creativemarket-samples> and download the > HIK examples, but I’ve attached the above rig to this email, unmodified, > for your convenience. But the same holds true for *any* HIK rig, even the > ones you generate using the HIK tools in Maya. > > The exported file will contain your animation (but not accurately, more on > that below), but the import will not succeed. > > What I’ve found is that there is a special node associated with HumanIK > node, called keyingGroup > <http://help.autodesk.com/cloudhelp/2018/ENU/Maya-Tech-Docs/CommandsPython/keyingGroup.html> > > which blocks the import of animation, for both ATOM and old-school .anim > formats. I assume there is a callback on any file import operation to > remove/undo anything done to nodes connected to the “.affectors” array > attribute on this node. > > Something you can try for yourself with this. > > 1. Import, and fail > 2. Run the below, then import, and succeed > > cmds.delete(cmds.ls(type="keyingGroup") > > Cannot Export > > (3) ATOM cannot export HumanIK reliably. What does that mean? > > Using the same setup you have up there, set a key on the forearm. Then > export the whole Ctrl_Reference group, with the full hierarchy. > > Now look in that ATOM file, and you’ll find that not only is the forearm > included. But the upper arm too! When you try and import this (using the > above “hack”), you’ll find that both your forearm and upperarm now contain > the same keys (and that the poor guy looks broken). > > What does this mean? That ATOM cannot reliably export the right animation > from the right nodes. I cannot fathom how, but there it is, in the flesh. > > For completeness, here’s the full command I used. > > file -import -type "atomImport" -ra true -namespace "test" -options > ";;targetTime=3;option=scaleReplace;match=string;;selected=childrenToo;search=;replace=;prefix=;suffix=;mapFile=C:/Users/marcus/maya/data/;" > "C:/Users/marcus/maya/data/test.atom"; > > No Python API > > (4), a Python API isn’t necessary, but would be convenient. Here’s how I > currently export using ATOM. > > from maya import cmds > > fname = "/some/file.atom" > cmds.file( > fname, > type="atomExport", > > force=True, # Overwrite > exportSelected=True, > > options=( > "precision=8;" > "statics=1;" > "baked=True;" > "sdk=0;" > "constraint=0;" > "animLayers=0;" > "selected=childrenToo;" > "whichRange=2;" > "range=1:100;" > "hierarchy=none;" > "controlPoints=0;" > "useChannelBox=1;" > "options=keys;" > "copyKeyCmd=" > "-animation objects" > "-option keys" > "-hierarchy none" > "-controlPoints 0" > ), > ) > > And similarly for import. > > cmds.file( > fname, > i=True, # import > type="atomImport", > options=( > "targetTime=2", > "option=scaleReplace", > "match=string", > "selected=childrenToo", > "mapFile=;", > ) > ) > > ..but would really like to avoid it. Partly because of poor syntax from > passing strings to MEL, but mostly because using cmds.file kindly and > automatically clears Maya’s undo buffer, which means you *cannot undo* > the animation you’ve imported. > Feedback > > So let’s start there. Ideally you’d tell me these things are simply not > true, and that I’m using it wrong. Alternatively you’d tell me about this > other project which solves exactly this. Worst and likely case is you’ll > tell me you’ve also had issues with ATOM and ventured down the road of > rewriting it well. > > Last but not least, here are my requirements. > > 1. Export/import of animation of any Maya data type, e.g. > translate/rotate/scale/custom attributes > 2. Export/import of a selection of nodes, with/without descendents > 3. Export/import of a user-specified range > 4. Export/import of static (unkeyed) channels > 5. Export/import of animation between different hierarchies (prefixes) > 6. Control over whether existing keys are overwritten or ignored > 7. Awareness (but not necessarily support for) animation layers > 8. Support for namespaces (e.g. referenced rigs) > 9. Compatibility with HumanIK, which I thought was a given > 10. No MEL, please > > More or less what ATOM promises, apart from the last two. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/1c1bd1ae-7f3e-46fc-8067-31517d1155d9o%40googlegroups.com.
