AbcExport fails when >1 nucleus node is present.
97 views
Skip to first unread message
Eddie Offermann
May 22, 2012, 11:07:03 PM5/22/12
to alembic-d...@googlegroups.com
With AbcExport 1.0 using Alembic 1.0.5, Maya 2011.5 and Maya2012 both present this issue:
In a scene with more than one Nucleus node, I've been unable to get AbcExport to work. It fails immediately - no error is presented in MEL, but mel.eval() of the AbcExport command string will give:
In a scene with more than one Nucleus node, I've been unable to get AbcExport to work. It fails immediately - no error is presented in MEL, but mel.eval() of the AbcExport command string will give:
# RuntimeError: Error occurred during execution of MEL script
No file is written.
Creating an nCache and unclicking "Enable" on the nucleus nodes, as well as unclicking "Enable" on all associated nClothShapes/nRigidShapes also has no effect.
Creating an nCache and unclicking "Enable" on the nucleus nodes, as well as unclicking "Enable" on all associated nClothShapes/nRigidShapes also has no effect.
Scenes with only one Nucleus node work fine - but in scenes with multiple characters with their own Nucleus setup, export fails.
Eddie Offermann
May 23, 2012, 1:06:13 PM5/23/12
to alembic-d...@googlegroups.com
Sorry, couldn't share an immediate example because I couldn't share the rigs we encountered the problem with - built a simple example scene this morning which serves as a good test case.
Load the scene and run:
Load the scene and run:
if not cmds.pluginInfo("AbcImport", q=True, l=True):cmds.loadPlugin("AbcImport")if not cmds.pluginInfo("AbcExport", q=True, l=True):cmds.loadPlugin("AbcExport")cmds.select(['object_A:assy','object_A:peg','object_A:pegShape','object_A:drape','object_A:drape','object_A:outputCloth1'])mel.eval('AbcExport -j "-fr 1 160 -sn -uv -ws -wv -sl -file ~/Desktop/abcTest.abc"')
The mel.eval will terminate with the runtime error mentioned above. If run directly as a MEL command, nothing is output to the script editor at all and it behaves as if it worked except no file is written and the usual calculating and playthrough never happens.
Lucas Miller
May 24, 2012, 1:39:25 PM5/24/12
to alembic-d...@googlegroups.com
I'm not yet sure where the bug is, but one workaround for this specific example is to specify a root.
mel.eval('AbcExport -j "-root object_A:assy -fr 1 160 -sn -uv -ws -wv -sl -file ~/Desktop/abcTest.abc"')
This works for your specific example because you are only translating things under object_A:assy.
Lucas
--
You received this message because you are subscribed to the Google
Groups "alembic-discussion" group.
To post to this group, send email to alembic-d...@googlegroups.com
To unsubscribe from this group, send email to
alembic-discuss...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/alembic-discussion?hl=en
For RSS or Atom feeds related to Alembic, see:
http://groups.google.com/group/alembic-dev/feeds
http://groups.google.com/group/alembic-discussion/feeds
Eddie Offermann
May 24, 2012, 5:47:02 PM5/24/12
to alembic-d...@googlegroups.com
In the real assets where we encounter this, there's too much clutter underneath the root to define our scope so broadly. My workaround at the moment is to list the Nucleus nodes in the scene and to identify which ones aren't part of the particular asset we are publishing - since the assets are referenced into the scene, I can unload the references to the unneeded ones, write Alembic, then load them back.
Down the road I'm sure we'll attempt this with an asset that itself contains multiple nucleus sims and both workarounds fail on that unless we functionally split the asset heirarchies by nucleus assignment.
To post to this group, send email to alembic-discussion@googlegroups.com
To unsubscribe from this group, send email to
Lucas Miller
May 24, 2012, 9:01:21 PM5/24/12
to alembic-d...@googlegroups.com
Try this change on your real scene and let me know if you encounter any problems:
If you would have selected something under object_B:assy and tried to export it with the same options, an exception would be thrown since you specified -sn (-stripNamespace) and that would cause object_B:assy and object_A:assy to have the same name. (siblings can't have the same name)
In this most recent commit, I've tried to be clearer with the error messages, and fixed a bug in the case where -sl was specified but no -root was specified.
In this most recent commit, I've tried to be clearer with the error messages, and fixed a bug in the case where -sl was specified but no -root was specified.
Lucas
To post to this group, send email to alembic-d...@googlegroups.com
To unsubscribe from this group, send email to
Eddie Offermann
May 24, 2012, 9:26:07 PM5/24/12
to alembic-d...@googlegroups.com
Cool - will do.
In my current system, we would not be publishing assets across namespaces, but that's good to take note of. Our assets are namespaced by their UID and prefixed by an additional unique instance identifier to prevent namespace stripping to cause collisions even among instances of the same asset.
In my current system, we would not be publishing assets across namespaces, but that's good to take note of. Our assets are namespaced by their UID and prefixed by an additional unique instance identifier to prevent namespace stripping to cause collisions even among instances of the same asset.
We'll incorporate this change and give it a try.
For more options, visit this group at
http://groups.google.com/group/alembic-discussion?hl=en
For RSS or Atom feeds related to Alembic, see:
http://groups.google.com/group/alembic-dev/feeds
http://groups.google.com/group/alembic-discussion/feeds
Reply all
Reply to author
Forward
0 new messages