Asset/TX Manager vs. Auto-convert textures to TX

[shawn]

12 hours into the "final" render of an animation sequence I noticed that a texture map was not rendering properly compared to draft renders of the same animation. It turned out the problem was that I had Auto-convert textures to TX activated for the earlier draft renders, but I'd deactivated it for this final render (I didn't want it to run that conversion for Every. Single. Frame.). I was under the impression that since that PNG had the (tx) next to it in the Asset/TX Manager that Arnold would be using the .tx version in this final render, regardless of whether Auto-convert was active. I guess I'm not understanding how that really works, and the online manual isn't helping me much.

In this case the texture is a white on black PNG of traces on a circuit board that I'm running through a color correction node (to tweak the gamma) and then into the cutout opacity of the geometry of a light grey plane floating just on top of the PCB model (shadows deactivated).

Without Auto-convert activated the traces are barely visible, as if the gamma is being crushed, clipping out almost all of the white.

Thank you.

[Stephen.Blair]

It's Use existing tx that determines whether C4DtoA tells Arnold to use a tx file.

[shawn]

Stephen:

Thanks for the reply. Use existing tx is always checked for my renders, but it didn't seem to work in this case, or something else is wrong.

Here's my setup for that texture map showing the material settings and the Asset/Tx Manager.

Here's the resulting (correct) render of a simplified scene with Auto-convert textures to Tx activated:

Here's the incorrect render with Auto-convert textures to TX OFF (and Use existing tx is ON):

I'm on C4DtoA 3.0.3.1 on C4D R20 on Windows 10 Pro

Best.

Shawn

PS: I've repeatedly tried on multiple browsers to notify/tag people by using @username, but all I can get to appear is the "@" symbol, even after clicking on the person's avatar.

[peter.horvath6V6K3]

First of all, the Tx conversion does not run every time when auto tx is enabled. The plugin checks if the Tx file exists, then checks if the file is valid (reads the header) and re-generates the file ONLY if needed. (Of course this validation can add some overhead since it's running every frame, but it should be minimal.)

I know there was a problem with color spaces and 'Use existing tx', which is fixed in the latest C4DtoA 3.1.0. However that issue exists only if the color space is NOT set to 'auto'. In summary, auto tx produces a Tx file in linear color space. If the color space is explicitly set to 'sRGB', then this linear texture is considered as sRGB and the result is darker. However in 'auto' color space it should be properly recognized as linear.

Can you send me this texture to take a look? Also could you check maybe with 3.1.0 if this problem still exists? Settings have changed a little bit, now you have to set the Tx generation mode to 'manual' which is the equivalent of the previous 'Use existing tx'.

[peter.horvath6V6K3]

And sorry that this is messed up your render!

[shawn]

Peter:

Thanks for the reply. Upgrading to 3.1.0 doesn't fix this issue for me. Setting the mode to "manual" results in a render with the PCB traces barely visible, even though the TX/Asset manager indicates there's a TX version available.

What's strange is when I save that mini-project with assets its tex folder contains the original PNG but not its associated TX version. Maybe some linkage got messed up in the original project, making it think it had access to a TX version when it really didn't. The TX version of that image DOES exist in the tex folder associated with that project.

Here's a Dropbox link to a zipped folder that contains this mini-project and the original PNG.

https://www.dropbox.com/s/wo902nbhjlltj1r/pcb_tx_demo.zip?dl=0

Best.

Shawn

PS: The 3-4 hours of incorrect renders didn't impact my deadline, but thanks for noting that.

[peter.horvath6V6K3]

It seems there's a problem with 16-bit png's in the plugin, not recognizing the color space properly. I'll fix this in a next release.

[peter.horvath6V6K3]

Seems like that's another bug. By design the tx file should be saved with the project when the mode is 'manual'. In 'auto' mode only the original image is saved, and the tx is regenerated by the client.

[peter.horvath6V6K3]

The issue is fixed in C4DtoA 3.1.0.1. You have to regenerate the Tx file first (render in auto Tx mode or via the Tx Manager), then it should work fine in manual Tx mode.