question

V V avatar image
V V asked ·

Arnold aiSetParameter nodes from mtoa 3.2.2 don't seem to be backward compatible with 3.1.2.1

Hi,

We're making heavy use of aiSetParameter nodes in our look dev and lighting pipeline - we basically use them to assign materials, smooth geometries, apply displacement, etc.. etc.

While working on a very big maya scene with many assets and aiSetParameter nodes we noticed that the scene was very very slow to render, even though it was not so complex.. I mean we've done way more than that. :)

We currently use mtoa 3.1.2.1, and we decided to check the release notes of version 3.2.1.1 which, among the other things, say:

Fixed slowdown with many operators

So we downloaded the new version in order to test if the slowdowns were fixed (we tried both 3.2.2 and 3.2.1.1 to be honest).

But we discovered that some aiSetParameter nodes (created with the 3.1.2.1) are not working anymore with 3.2.2 - they give the classic pinkish color at render time, as if they were not evaluating correctly. Of course all of the nodes were working exactly fine in the previous version.

We also noticed that in this version (3.2.2) we have to check Export all shading groups in the arnold render settings in order to make the aiSetParameter work.

Now, if we create new aiSetParameter nodes and use them to assign shaders they work just fine, so it appears that it's just that the old ones for some reason are not compatible with this arnold version.

Can you confirm it? We've got quite a few assets already done with the old version, it seems odd that we should republish them just because of this regression between minor versions.

Thanks!

Maya version is 2018.6, OS is Centos 7.6.

Steps to reproduce the issue

Create an aiSetParameter node in version 3.1.2.1, upgrade mtoa to 3.2.2 and check that it works.

arnoldmtoanodesoperator
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Ashley Handscomb Retallack avatar image
Ashley Handscomb Retallack answered ·

It looks like a bug in the shader detection if you remove the spaces between the parameter '=' and value it should work.

so

"shader = 'myshader'

should be

shader='myshader'

I will make a bug report for the spaces issue

2 comments Share
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Thanks Ashley, without spaces it works. Very very weird regression bug! Did you open an issue? When can I track it?

0 Likes 0 · ·

It's MtoA ticket #3939, should be fixed in the next bugfix update.

0 Likes 0 · ·
Stephen Blair avatar image
Stephen Blair answered ·

Something broke the automatic export of referenced shaders, I can repro in the current MtoA too.

You'll have to use Export All Shading Groups for the moment...

4 comments Share
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Thanks Stephen! But Export All Shading Groups doesn't work for all nodes - some aiSetParameter nodes are not assigning the shader properly even when this checkbox is ticked. Also, by referenced do you mean a Maya reference? Because during our lookdev we don't have any referenced shader (only during lighting).

0 Likes 0 · ·

By referenced, I mean that an assignment statement references a shader node.

For example: *shader = "aiUtility1"*

MtoA is supposed to automatically export the referenced shader.

What kind of set parameter nodes do not work with shaders? Do you have a simple scene that shows the problem?

0 Likes 0 · ·
V V avatar image V V Stephen Blair ♦♦ ·

Got it. So yes we are doing many assignments like that since we basically assign shaders to geos in this way. The ones that don't work are also just simple aiSetParameters like the one you showed. I can try to reproduce the error by creating a scene with 3.1.2.1 and then move to 3.2.2 and see if the issue remains. Otherwise I can send you the maya scenes which are giving us errors. Basically the same scene works under 3.1.2.1 but renders completely pink with 3.2.2 (even w/ the Export all Shading Groups check)

0 Likes 0 · ·
Show more comments
V V avatar image
V V answered ·

Ok I did a test (create operators with 3.1.2.1, test them on 3.2.2) with a very simple scene and it worked. But then I opened of our assets using 3.2.2 and it was completely pink, while in 3.1.2.1 it was rendering just fine. Exported an .ass and while it contains the set_parameter and the merge nodes, it doesn't contain any shader.

2 comments Share
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

If you can send something to support, we can take a look.

0 Likes 0 · ·
V V avatar image V V Stephen Blair ♦♦ ·

Thanks, Stephen! I'll send the Maya scene to the support email.

0 Likes 0 · ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Welcome to the Arnold Answers community.

This is the place for Arnold renderer users everywhere to ask and answer rendering questions, and share knowledge about using Arnold, Arnold plugins, workflows and developing tools with Arnold.

If you are a new user to Arnold Answers, please first check out our FAQ and User Guide for more information.

When posting questions, please be sure to select the appropriate Space for your Arnold plugin and include the plugin version you are using.

Please include images, scene and log files whenever possible as this helps the community answer your questions.

Instructions for generating full verbosity log files are available for MtoA, MaxtoA, C4DtoA, HtoA, KtoA, and Kick.

If you are looking for Arnold Documentation and Support please visit the Arnold Support site.

To try Arnold please visit the Arnold Trial page.

Bottom No panel present for this section.