C4dtoA: Crash if Arnold Procedural path points to broken link?

[Shawn_Kearney1]

Tonight I was rebuilding our .ass library to conform with some naming convention changes. I noticed when I re-opened a file that now points to the broken link, c4d hangs. The way to get around this is to use my dev installation, which has all plugins removed and deleting the procedural object.

This problem seems to be unique to R18 with Arnold 5. My R17 installation has Arnold 4 installed, and the files opened fine, but will break some shader networks upon saving (along with some other odd behaviors)

We'll be upgrading to R19 soon. I'd like to report to my boss that this will be fixed.

[peter.horvath6V6K3]

I'm not able to reproduce the issue. Opening an old scene with an Arnold Procedural pointing to a non-existing ASS file works fine here. Could you please send me the scene you have trouble with?

[Shawn_Kearney1]

Hi Peter. I will try today to replicate. I've already replaced the broken files. Some other details, the c4d and .ass files exist in different folders on the same network-attached directory. I am not sure what operating system the servers are running, but we're using a Facilis/TerraBlock system. I've updated my C4DtoA, and will get you the C4D release and problem file by the end of today.

[peter.horvath6V6K3]

Does the broken path point to a non-existing network drive? There could be a delay (couple of seconds, even 20+) coming from the OS when it tries to access the drive. If there are a lot of procedurals in the scene it might add together.

The procedural tries to read the file (.asstoc and .ass) to define the bounding box. The code looks fine to me, it tries only once, does not repeat over and over again if the file is not found.

[Shawn_Kearney1]

Thank you for your attention to this, as well as my other questions. It is very much appreciated.

I've tried to replicate my file structure the best I could. Inside this zip file you will find a folder with some sub folders. The 3D Assets folder would be located on a network attached drive called "VFX_Workspace". The C4D file is located at:

3D Assets/Models/Arnold Models/test/test_sphere.c4d

Likewise the .ass is located at:

3D Assets/Procedurals/ball_sphere.ass

The .ass is absolutely referenced, and I've conformed namings to our in-house convention and exported using a script we'll be using. However, I don't think that this matters, and I am pretty sure I'll get the same crash no matter.

We're using C4D R18.075 (RB203954). On my workstation I have C4DtoA 2.1.1 installed with Arnold core 5.0.1.3 running on MacOS 10.10.5 (14F2411) on a Mac Pro (Late 2013).

I have confirmed this will crash, even when opened from the desktop. Running C4D from terminal did not print any errors or messages. I will see if it behaves the same on other machines.

[peter.horvath6V6K3 · Accepted solution]

I'm able to reproduce the issue on OSX. It will be fixed in the next release.