Community
Arnold for Cinema 4D Forum
Rendering with Arnold in CINEMA 4D using the C4DtoA plug-in.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

C4DtoA is fulling up my SSD with every render.

10 REPLIES 10
SOLVED
Reply
Message 1 of 11
Sazarret
629 Views, 10 Replies

C4DtoA is fulling up my SSD with every render.

I'm working with a kind of complex scene with lot of textures in various formats like tiff, png, jpg and tx. I started having issues with my main SSD, the one with the OS, getting fuller and fuller with every render, until the drive just doesn't have enough free space to even work. I suspect that it has something to do with some kind of cache files that are saved due to the conversion of the textures to .tx but those caches are nowhere to be found and the Arnold's Flush Caches function does nothing to fix the problem. I tried restarting the machine and searching for the bulk of files causing the problem with various Drive tools but there are still about 200 Gb missing from the drive.

What can I do please?

I'm working with C4D R20, C4DtoA 2.4.1 on a Mac running over High Sierra 10.13

10 REPLIES 10
Message 2 of 11
Stephen.Blair
in reply to: Sazarret

there are no cache files for tx conversion

any tmp file would be created in the same folder as the original texture, and then renamed to ".tx"

the texture cache is in RAM, not on the hard drive

a render writes out files, that's it. are you rendering all your files to the ssd?

what disk space analyzer are you using?



// Stephen Blair
// Arnold Renderer Support
Message 3 of 11

Do you have Substance shaders in the scene? Exporting substance assets to Arnold uses a file cache which is under the tex folder. Though, it should not create new files for the same asset and should be removed with the flush textures command.

Message 4 of 11
Sazarret
in reply to: Sazarret

"are you rendering all your files to the ssd?" No, I'm rendering to a separate drive.

"what disk space analyzer are you using?" MacKeeper and Disk Map. I don't know if there's a better one.

"Do you have Substance shaders in the scene?" No, no substance shaders in the scene, just regular Arnold and C4D shaders.

The weird thing is that the space of the drive went down with every render and now the disk is full. I didn't perform any other task nor downloaded any files in this workstation while working.

Message 5 of 11
Stephen.Blair
in reply to: Sazarret

Identify what's using the disk space.

What does Disk Map show? Does it show a "missing 200GB" ?

What does the command df -h print out

http://osxdaily.com/2007/03/20/command-line-disk-usage-utilities-df-and-du/



// Stephen Blair
// Arnold Renderer Support
Message 6 of 11
Sazarret
in reply to: Sazarret

Finally found it!

df -h didn't do much to help me found the culprit, there was still some information that not even Terminal was able to show. So what I did was unhide all hidden files in Finder and sort everything by size. There, under /private/var/tmp, found around 22.000 files that were using 149 Gb of space, 99% of them were image files (png, tiff, jpg and tx) created by Arnold from this and previous projects.

Deleting the files solved the immediate problem but the question is why isn't Arnold deleting the files after they are used and C4D is closed. Is there an Arnold setting that I might be missing?

Thank you guys for the help.

Message 7 of 11

OK I got it. If there are unicode characters in the path , then a copy is made to the temp folder to be able to run the tx generation. It's probably a bug not to cleanup the folder. I'll take a look and try to fix this. Can you confirm that there are special characters in the texture paths?

Message 8 of 11

Actually I might be wrong, that seems to be an old code which is not used any more, so I'm still not sure what's going on.

Message 9 of 11
Sazarret
in reply to: Sazarret

This is the kind of names that the files have:

tmp.1.EEM2sY.tx

tmp.52.8WAwnu.png

tmp.12.H7R4ic.jpg

Of course that is not the original name of the files.

Message 10 of 11

OK, so C4DtoA 2.4.1 still has that code. It was removed in 2.4.3, so it should be fixed if you update the plugin. Let me know if you need the fix specifically in 2.4.1 and I'll make you a custom build.

Message 11 of 11
Sazarret
in reply to: Sazarret

I updated to 2.4.5 and everything seems to be working properly now

Thank you Peter

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums