Hello,
We are experiencing an issue rendering a Maya scene with a geometry named ArenaShape in the ass file. This is a relevant log part of one of the Deadline slaves:
2019-07-05 11:13:24: 0: STDOUT: 00:00:01 79MB WARNING | [polymesh] Arena_ExtrasShape: discarded 1 duplicate deformation keys 2019-07-05 11:13:24: 0: STDOUT: 00:00:01 79MB ERROR | [polymesh] Arena_ExtrasShape: out-of-range vertex index 2019-07-05 11:13:24: 0: STDOUT: 00:00:01 79MB ERROR | [polymesh] Arena_ExtrasShape: out-of-range UV index 2019-07-05 11:13:24: 0: STDOUT: 00:00:01 79MB WARNING | [kick] render aborted due to earlier errors
We can provide logs as well as alternate ones, or the files you require.
It is important to note that the scene renders fine under Windows 10 and the same version of the Deadline farm, but it does not do so under CentOS.
Some sw versions:
maya-2018
mtoa-3.1.1.op.3
arnold-5.2.1.0
render node OS: CentOS Linux release 7.6.1810 (Core)
Can you assist?
Thanks in advance,
J.
Solved! Go to Solution.
Solved by Stephen.Blair. Go to Solution.
We are experiencing an issue rendering a Maya scene with a geometry named ArenaShape in the ass file.
So the Maya scene includes an aiStandin that loads the ArenaShape geometry?
Or are you kicking ass files?
If you're kicking ass files, where are the ass files generated? On Windows and then rendered on Linux?
Can you post at least the headers from the Arnold logs, so we can see all the version and system information for the different systems?
If you disable binary encoding in the ASS export options, do you still get the same errors?
What is mtoa-3.1.1.op.3 ? The MtoA 3.1.x series includes only these:
3.1.0
3.1.1
3.1.2
3.1.2.1
Hi Stephen,
Thanks for your prompt reply. Yes, the ass files are generated on windows and kicked on Linux render nodes.
I will manage to try with the binary encoding setting and get the Arnold logs.
Cheers,
J.
Hi Stephen,
This is the Windows first log line for Arnold
Arnold 5.2.1.0 [7c7c9701] windows icc-17.0.2 oiio-1.7.17 osl-1.9.9 vdb-4.0.0 clm-1.0.3.513 rlm-12.4.2 2018/10/19 21:35:58
Actually, we use the same in CentOS
Arnold 5.2.1.0 [7c7c9701] linux clang-5.0.0 oiio-1.7.17 osl-1.9.9 vdb-4.0.0 clm-1.0.3.513 rlm-12.4.2 2018/10/19 22:25:43
In Linux, one of the differeces that grab my attention is this
2019-07-08 12:34:10: 0: STDOUT: 00:00:00 64MB WARNING | unable to load dynamic library ./libai_renderview.so: 2019-07-08 12:34:10: 0: STDOUT: 00:00:00 64MB WARNING | unable to load dynamic library ./libmtoa_api.so:
Is it possible that mtoa uses some resources from the Maya installation and due to the fact that both 2018 and 2019 versons are installed on the Linux render machines this may cause a strange behaviour?
Cheers,
J.
Hi
@Anonymous wrote:
Hi Stephen,
This is the Windows first log line for Arnold
Arnold 5.2.1.0 [7c7c9701] windows icc-17.0.2 oiio-1.7.17 osl-1.9.9 vdb-4.0.0 clm-1.0.3.513 rlm-12.4.2 2018/10/19 21:35:58Actually, we use the same in CentOS
Arnold 5.2.1.0 [7c7c9701] linux clang-5.0.0 oiio-1.7.17 osl-1.9.9 vdb-4.0.0 clm-1.0.3.513 rlm-12.4.2 2018/10/19 22:25:43In Linux, one of the differeces that grab my attention is this
2019-07-08 12:34:10: 0: STDOUT: 00:00:00 64MB WARNING | unable to load dynamic library ./libai_renderview.so: 2019-07-08 12:34:10: 0: STDOUT: 00:00:00 64MB WARNING | unable to load dynamic library ./libmtoa_api.so:Is it possible that mtoa uses some resources from the Maya installation and due to the fact that both 2018 and 2019 versons are installed on the Linux render machines this may cause a strange behaviour?
Cheers,
J.
Hi
Since you're using kick, those warnings about libai_renderview and libmtoa_api don't matter. kick doesn't need to load those two libraries. Those two libraries have dependencies that are found when you run under Maya, but not when you just run kick in a terminal (libmtoa_api, for example, depends on some Maya libraries).
Usually I avoid running kick in the MtoA bin folder. eg I don't cd to the MtoA bin folder and run kick
It's fine to have multiple versions of Maya and MtoA installed on a render node, as long as you don't put any version-specific paths into the environment.
Hello Steven,
It was solved regenerating the ASS files I think. Thanks for all the help!
Jordi
Can't find what you're looking for? Ask the community or share your knowledge.