topic Re: Procedural and texture issue on shared drive in Arnold for Cinema 4D Forum

Procedural and texture issue on shared drive

infoZZVT9 — Wed, 31 Mar 2021 17:30:24 GMT

At our studio we are using a shared storage system, and recently have been working with Arnold Procedurals in a large project. It seems that no matter what we do (setting search paths, relative vs absolute paths, etc.) we have intermittent issues with procedurals and textures unlinking in our project.

Currently we are using the most up-to-date versions of C4D and Arnold. The other bizarre part is that Arnold works fine with procedurals when our Houdini artist is using Procedurals in his scenes.

We have been trying to look for solutions to this intermittent issue for months, and if anyone could point us in a direction it would be extremely helpful. Thanks.

Re: Procedural and texture issue on shared drive

Stephen.Blair — Wed, 31 Mar 2021 17:48:38 GMT

Unlinking? Do you mean that Arnold does not find the specified filepaths?

What does it say in the Arnold logs?

Re: Procedural and texture issue on shared drive

infoZZVT9 — Wed, 31 Mar 2021 18:00:53 GMT

It seems like Arnold is not able to resolve the paths. Here is what the Console says:

Asset Error: V:\8563_CRR_19MV_ProductLaunch\02_3D\00_PROJECTS\C4D\tex\TIBTO_Building.ass (Arnold Procedural)

We've tried setting the search paths in the Render Settings, but this seems to work for a bit and then fail after a while as well. Hitting the green checkmark in the object manager seems to sometimes resolve the issue for a short time when using the IPR.

Re: Procedural and texture issue on shared drive

Stephen.Blair — Wed, 31 Mar 2021 19:11:32 GMT

Hmm, that's not an Arnold error, that's coming from CINEMA 4D, so that suggests that even CINEMA 4D cannot find the file.

For textures, there would be something in the Arnold log, like:

[c4dtoa] 00:00:00  1665MB ERROR   |  [texturesys] /utility|image: Invalid image file "C:\Users\blairs\Downloads\_assets\uv-xgrid.png": Could not open file "C:\Users\blairs\Downloads\_assets\uv-xgrid.png"

Procedurals, unfortunately, silently fail and there's nothing in the Arnold log.

Did you try checking the Arnold Asset/Tx manager?

Is that the right path to the ass file?
What is V mapped to?

Re: Procedural and texture issue on shared drive

infoZZVT9 — Wed, 31 Mar 2021 19:54:59 GMT

Yes, V: is a storage space on our server that is mapped via the server manufacturer's interface.

It connected to my workstation via a 10GBASE-T card to the server, and is on a different IP than my main network connection.

Here is what the TX manager looks like:

All of those red files are located in the "tex" folder, so Arnold should be able to find them since they are relative. Right?

Re: Procedural and texture issue on shared drive

infoZZVT9 — Wed, 31 Mar 2021 20:03:57 GMT

Also, I was sitting in front of my computer talking to a coworker (not touching anything), and the TX Manager changed to this:

The IPR was not running or anything.

Re: Procedural and texture issue on shared drive

infoZZVT9 — Mon, 05 Apr 2021 19:58:13 GMT

Stephen,

Do you have any other suggestions for us to try? If you need more info I can send it to you.

Re: Procedural and texture issue on shared drive

Stephen.Blair — Tue, 06 Apr 2021 10:46:10 GMT

Hi Andy

I have to review this thread. I (and the C4DtoA developer too) have been out of the office for the last five days (vacation and/or Easter statutory holidays).

Re: Procedural and texture issue on shared drive

infoZZVT9 — Tue, 06 Apr 2021 14:18:07 GMT

No problem! I was thinking that might be the case. Let me know if you need anything else on our end to track down the issue. Thanks!

Re: Procedural and texture issue on shared drive

Stephen.Blair — Tue, 06 Apr 2021 17:41:10 GMT

Hi @Andy

If it was just textures, then I would ask about your tx settings (because maybe one machine is updating a tx file while a second machine is trying to use the texture). But since the problem happens also with procedurals, I think it's something more general.

The Asset/Tx Manager will update if you do something that loads an image node into the attribute editor (because the material preview is updated). So if there's any kind of file/path/network access problem, the tx entry turns red

I would do the following:

Use Process Monitor to watch what happens during a CINEMA 4D session. Process Monitor will show what files Arnold and CINEMA 4D are trying to access, and what happens.
You can set filters in Process Monitor so that you log only file access by CINEMA 4D.

And, if you need to run Process Monitor for a long time because the problem is not easy to reproduce, you can tell Process Monitor to files on disk instead of memory, so that the log doesn't use up all your virtual memory during the session. Let me know if you need more info on that.
Copy some or all of the textures and ass files locally, for testing. Are there still problems?

Re: Procedural and texture issue on shared drive

infoZZVT9 — Tue, 06 Apr 2021 18:37:48 GMT

I should have mentioned that if I copy the files to a local drive, we have no issues at all with linking. It's only on the server.

I am working with the Process Monitor to see if I find anything of interest.

Re: Procedural and texture issue on shared drive

infoZZVT9 — Tue, 06 Apr 2021 19:05:45 GMT

Should I send you the Process Monitor file. I am definitely seeing some differences between when an IPR session loads the ASS file and when it doesn't load it.

When I filtered by the ASS file's path, I found that the times it failed it only made a few entries, and when it succeeded it made considerably more.

Should I send you the log to take a look at?

Re: Procedural and texture issue on shared drive

Stephen.Blair — Tue, 06 Apr 2021 19:48:53 GMT

Hi @
yes, you can send it to me

zip it up and send to support @ arnoldrenderer.com

Re: Procedural and texture issue on shared drive

Stephen.Blair — Wed, 07 Apr 2021 16:24:27 GMT

Hi @Andy

Thanks for the log file. I don't see any problems in the Process Monitor log. The ass file and every texture file was found.

Re: Procedural and texture issue on shared drive

infoZZVT9 — Thu, 08 Apr 2021 14:44:16 GMT

Any other thoughts on what could be causing the issue? The ASS goes from working, to not working, and back again several times during that 4-5 minute log.

Re: Procedural and texture issue on shared drive

Stephen.Blair — Thu, 08 Apr 2021 15:04:40 GMT

Not working = Highlighted in red in the Asset/Tx Manager?

According to the Process Monitor log, CINEMA 4D.exe had no problems accessing the ass file.

@Peter what triggers a change in the Asset/Tx Manager user interface?

For tx files, do we run oiiotool?
For ass files...???

Re: Procedural and texture issue on shared drive

infoZZVT9 — Thu, 08 Apr 2021 15:19:39 GMT

Sorry, not working = not appearing in the IPR render or final render

We have created the ASS files from the C4D interface and have tried it with both Relative and Absolute paths.

Re: Procedural and texture issue on shared drive

peter.horvath6V6K3 — Fri, 09 Apr 2021 10:12:02 GMT

The Asset/Tx Manager interface updates on any scene changes. It calls the C4D SDK to check if the file exists or not, nothing tricky.

Since everything's fine locally, it sounds like a network issue. I wonder if other renderers or Cinema 4D itself have any issues reading those textures from the network drive.

Re: Procedural and texture issue on shared drive

infoZZVT9 — Fri, 09 Apr 2021 17:48:19 GMT

Arnold works fine in Houdini with the exact same procedurals and textures. So it has to be something on Cinema's side. Any suggestions for further tracing down the issue?

Re: Procedural and texture issue on shared drive

peter.horvath6V6K3 — Mon, 12 Apr 2021 08:30:44 GMT

You can try to run this python script from C4D when the tx manager or render fails:

import c4d
from c4d import gui
import os

PATH = "V:\\path\\to\\myfile"
ITERATIONS = 50

# Main function
def main():
    for i in range(0, ITERATIONS):
        print "chech path in iteration %d" % i
        if (not os.path.exists(PATH)):
            print "Path does not exist!!!"

# Execute main()
if __name__=='__main__':
    main()

Just change the PATH to your file. I wonder if it fails too.