Arnold & XGen Archives

#1

Hi there, I’ve been having a problem for many weeks now and its driving me crazy.

When I try to export an XGen archive to then be able to instance it and render it with Arnold, the process fails. I get a pop up error message telling that PythonInterpreter has stopped working and noting is outputted to the folder. I have tried on multiple computers and it happens every time. If I unload Arnold then I can create an archive just fine.

I can’t seem to find anyone else this is happening to.
I don’t think this is a common problem as I can’t find to seem anyone else who is having this problem and when following Xgen/Arnold tutorials and guides the author doesn’t seem to have any problem.

The original plan was to use xgen for forest generation and then use Arnold to render it. I attached a picture of an arnold render test if you guys are interested. :stuck_out_tongue:


#2

I have the exact same issue. Have you solved it by now? (I am using Maya 2016)

#3

To be clear, your archive won’t be created if Arnold is loaded? So it’s not simply failing at rendertime, but also failing to generate the Xgen files initially?

#4

I select Arnold Renderer in the XGen Output Settings and then with my mesh selected I click on “Create From Selection”. Maya tries to process but then I get the “PythonInterpreter” stops working message.

I get the following messag in the Script Editor:

  • Arnold 4.2.6.1 windows icc-14.0.2 oiio-1.5.13 rlm-11.2.2 2015/04/28 09:32:47
  • CRASHED in QUrl::isEmpty
  • signal caught: error C0000005 – access violation
  • backtrace:
  • 0 0x00000076dd3b198e [ai ] AiCreateAtStringData_private
  • 1 0x00000076dd3b0b21 [ai ] AiCreateAtStringData_private
  • 2 0x00007ff9c9c11c72 [KERNELBASE ] UnhandledExceptionFilter
  • 3 0x00007ff9cc76fb33 [ntdll ] memset
  • 4 0x00007ff9cc752896 [ntdll ] _C_specific_handler
  • 5 0x00007ff9cc763f0d [ntdll ] _chkstk
  • 6 0x00007ff9cc724887 [ntdll ] RtlRaiseException
  • 7 0x00007ff9cc76309a [ntdll ] KiUserExceptionDispatcher
    >> 8 0x0000000072b9d231 [QtCore4 ] QUrl::isEmpty
  • 9 0x00007ff9a946746f [Shared ] TresolveFileObject::isSet
  • 10 0x00007ff9a94674de [Shared ] TresolveFileObject::isSetURI
  • 11 0x00007ff9a94676ae [Shared ] TresolveFileObject::rawFullName
  • 12 0x00007ff9a91f2ef5 [Shared ] TsceneFile::fullName
  • 13 0x00007ff9a94ca88f [Shared ] TfileTranslator::read
  • 14 0x00007ff9a94c6a90 [Shared ] TglobalTranslator::doReadFile
  • 15 0x00007ff9a94a8e9a [Shared ] TfileUtil::readFile
  • 16 0x00007ff9a94980b9 [Shared ] TsceneOperator::openFile
  • 17 0x00007ff9a948d667 [Shared ] TfileCmd::handleFileOpenFlag
  • 18 0x00007ff9a9490bba [Shared ] TfileCmd::handleFlags
  • 19 0x00007ff9a949067a [Shared ] TfileCmd::handleFlags
  • 20 0x00007ff9a9489a12 [Shared ] TfileCmd::doCommand
  • 21 0x00007ff9b66ad1c7 [CommandEngine] TpythonInterpreter::dispatchMayaCommand
  • 22 0x000000001e0bd406 [python27 ] PyCFunction_Call
  • 23 0x000000001e10e069 [python27 ] Py_CheckRecursiveCall
  • 24 0x000000001e10dbb9 [python27 ] Py_CheckRecursiveCall
  • 25 0x000000001e10bf60 [python27 ] PyEval_EvalFrameEx
  • 26 0x000000001e10eb58 [python27 ] Py_CheckRecursiveCall
  • 27 0x000000001e10dbac [python27 ] Py_CheckRecursiveCall
  • 28 0x000000001e10bf60 [python27 ] PyEval_EvalFrameEx
  • 29 0x000000001e10eb58 [python27 ] Py_CheckRecursiveCall
  • 30 0x000000001e10dbac [python27 ] Py_CheckRecursiveCall
  • 31 0x000000001e10bf60 [python27 ] PyEval_EvalFrameEx
  • 32 0x000000001e10eb58 [python27 ] Py_CheckRecursiveCall
  • 33 0x000000001e10dbac [python27 ] Py_CheckRecursiveCall
  • 34 0x000000001e10bf60 [python27 ] PyEval_EvalFrameEx
  • 35 0x000000001e10eb58 [python27 ] Py_CheckRecursiveCall
  • 36 0x000000001e10dbac [python27 ] Py_CheckRecursiveCall
  • 37 0x000000001e10bf60 [python27 ] PyEval_EvalFrameEx
  • 38 0x000000001e10eb58 [python27 ] Py_CheckRecursiveCall
  • 39 0x000000001e10dbac [python27 ] Py_CheckRecursiveCall
  • 40 0x000000001e10bf60 [python27 ] PyEval_EvalFrameEx
  • 41 0x000000001e109abb [python27 ] PyEval_EvalCodeEx
  • 42 0x000000001e109329 [python27 ] PyEval_EvalCode
  • 43 0x000000001e13c0aa [python27 ] Py_SymtableString
  • 44 0x000000001e13a11a [python27 ] PyRun_FileExFlags
  • 45 0x000000001e13a686 [python27 ] PyRun_SimpleFileExFlags
  • 46 0x000000001e139fe3 [python27 ] PyRun_AnyFileExFlags
  • 47 0x000000001e0425b0 [python27 ] Py_Main
  • 48 0x00007ff7111d12ad [may
#5

I have the exact same problem.

Has anyone found a solution for this?

Thanks!

#6

i would post this issue on the arnold mailing list…

#7

It seems to be a bug of the arnold-xgen exporter to archives (Maya 2016). For whatever reason it can’t export a thing if arnold is involved in any way in the process, meaning you can’t export nodes with arnold shaders or being arnold itself the current renderer. Even the geometry can’t have any of the arnold attributes or it’ll fail. The workaround would be export the geometry with ant renderer but arnold as current renderer with placeholder materials. Once done, you’ll have the usual file structure able to be renderer in MR. Create a folder called “ass” inside the “archives” folder beside the “mi”, “material” and “abc” folders. Select your geometry and export to ASS to this “ass” folder making sure you activate the “export bounding box” and “use gzip compression (.ass.gz) options. Add the required lines to the .xarc file pointing to your newly created arnold .ass.gz file (take the existing lines as template changing the “mi” part to “ass”. You may have an error saying maya is unable to find the route. I don’t know why, but the arnold parser which reads this file seems to have a hardcoded “/” after the “{$PROJECT}” part, so you can safely delete it leaving it as this “”{$PROJECT}your/path/to/archives”. Import the archives into your description an save the file. Cry of joy.