Slower render times when using .tx textures (on a local NVMe disk)

[Alex_M]

Hi,

I wanted to see what's the fuss about .tx textures after seeing some posts from ^Lele^ saying that it saves a lot of RAM and speeds up renders and interactivity too. A Youtube video also seems to indicate better render times (although in Arnold). Chaos Cosmos assets also all use .tx textures. Unfortunately, I've had the opposite experience with them. Every scene I've tested so far shows slower render times of up to 10% on the scenes I've tested and none exhibited any speedups. These are production scenes, not synthetic or simple ones with just a couple of low-res textures. All bitmaps are loaded through VrayBitmap and filtering is at 1.0. Cache size for .tx textures in Vray settings is set to 14GB. All textures were on my local NVMe disk (Samsung 960 Pro) to rule out network bottlenecks from the equation. Still, my renders were 6-10% slower compared to using JPGs, TIFs, PNGs etc. Am I missing something?

[^Lele^]

Perhaps the texture cache size?
If you overflow it, they'll start swapping in and out of RAM to maintain occupancy within the limit, which will slow things down a bit.
Setting it to 0 ("use as much RAM as you need") makes any difference?

[Alex_M]

Thanks for the suggestion, ^Lele^ . This fixed the render slowdown issue. I'm now getting exactly the same render times as using normal, non-tx textures though. I have tested quite diverse scenes, interiors and exteriors alike, with lots of textures and detail, and all of them rendered in the same amount of time in both cases. Is it just my scenes that don't benefit performance wise from tx textures? If so, where exactly can I expect the speedups that you mentioned in your posts?

PS: From my preliminary tests, using tx textures also leads to slower times to first pixel compared to using non-tx textures. Up to 3-4 times in some scenes. Am I missing something?

[^Lele^]

It's generally down to what the camera sees: if you have stuff in the far distance, where smaller mips come into play, there will be bigger benefits.
Also, it's important that the textures sit on a quick drive: compared to standard bitmap loading there may be more disk activity, depending on a few factors.
Notice that using the "sharp isotropic" filtering in the v-ray bitmaps will load a bigger atlas than the normal filtering does, so that may lead to slightly slower, but more detailed, renders.

If you have scenes which you expect to speed up and aren't, please pass them over, so we can profile them.
The guide is a few years old, the bitmap loader changed a few times, we may have some non-obvious issue creeping in.

[Alex_M]

Thanks for the input. All my tx files are in a single folder on my local NVMe drive though, as I already mentioned (Samsung 960 Pro), which is plenty fast. The scenes I tested include exteriors with lots of textures in the distance. Filtering on all textures is the default "Isotropic" with Interpolation set to "Default". Still, so far I don't see any of the advertised speed benefits of up to twice as quick render times. The best I saw is same render times as using regular textures and most often than not I see slowdowns in time to first pixel of up to 3-4 times longer compared to using JPGs. This makes using tx textures counterproductive, especially when doing IPR lookdev and I constantly have to wait before the scene starts rendering. This is a problem for me since the assets in Chaos Cosmos use TX textures and for me time to first pixel is longer with TX in my personal tests. Can you kindly show me or share a scene where you used TX and it rendered faster for you? Screenshots with render times of the comparison would be great too. I want to see if it's a problem with my setup so I can fix it if that's the case. I would really appreciate this.

[^Lele^]

To be precise in my quote:

(in worst cases, the time loss was below 10%, in best cases, it went twice as quick.).

That, as mentioned, is a post from 2019, and the vrayBitmap loader has changed heaps since then, please share a specific scene (or set thereof) so we can profile it to see where the time loss may be.

A couple of points to make perfectly clear:
*) Swapping textures per se doesn't mean you'll get quicker rendertimes: they may even provide benefits, but be invisible because other parts of the scene eat up CPU time, maybe because the sharper-looking textures will force more sampling.
It will wholly depend on what the texture is driving, and how that will affect the overall sampling, at a given resolution and camera angle, and as such it's impossible to predict.
My quote above wasn't to cover all bases, it was factual, based on numeric results.

*)They may even be slower, but will definitely use less RAM for a generally sharper outcome.
This is why we elected to use them for anything we put out: we want users to be able to pile assets in their scenes without a second thought as to the memory usage of their textures.
A speed loss of a couple of percental digits is wholly acceptable in this context, it's unlikely we'll provide for non-Tx textured assets.

*) Lastly, no one spoke of first pixel times: picking a disk-bound atlas will be slower than burst reading a png of the sameish size of the atlas: that's wholly expected.
The benefit may come through other stages of the rendering phase, like when picking very small MIPs instead of huge textures, and not least by not running out of system RAM.

Here's a link to one of the spreadsheets i prepared at the testing time (once again: in July 2019. mileage will vary by now, possibly a great deal.).
Notice the last two scenes exceeded the 64GB of available RAM, so the reference times are those for vrayHDRIs.
The number of textures' discrepancy in the notes (between jpg/png and exr/tx) are purely due to original max bitmap loaders not being instanced, and being counted multiple times, whereas the actual number of file textures is the one shown for the .TX (as those have been physically written to disk.).
All the renders came out essentially identical.

[Alex_M]

Thanks for the thorough answer. I really appreciate it.
Another issue I'm seeing. My renders come out differently when I use tx textures. See attached. What causes this? The scenes are identical, only textures are different. I used the converter in the right click quad menu.

[M.Max]

Do you by any chance have Blur parameter less than 1.0 under Vraybitmap settings ?
I haven't tested, but I remember reading that lowering it will force VRay to use higher res verson of the mipmap.
Please correct me if this is not true for *.TX textures. ^Lele^

[^Lele^]

It indeed looks like different sharpness to the details (higher for .tx).
It's expected to a degree (one of the reasons why .TX is good: we can use much higher resolution textures/mips, so we get sharpness.).

Ways to counter it:
*) Raise Blur (not "Blur offset"!) on the offending textures: that will make V-Ray pick lower-sized mips, you will get some blurriness back.
*) Change interpolation type: there are softer interpolation types for each filtering mode in the vrayBitmap: using bicubic or biquadratic will soften the result.

However, if the comparison with the original isn't absolutely necessary, i much prefer the look of the .tx version: it has a better contrast rolloff in many places (tree, bushes, side of the house.), for my eyes, and the flowers don't "glow" as much anymore (possibly opacity at play, better defined with .tx).

[garipodelu]

Do you guys have a script to change all the VrayBitmaps Blur value to the default 1?

Edit:
I managed to figure it out. Will post here in case someone else will find it usefull.

for m in (getclassinstances VRayBitmap) do m.coords.blur = 1

[^Lele^]

Do you guys have a script to change all the VrayBitmaps Blur value to the default 1?

Edit:
I managed to figure it out. Will post here in case someone else will find it usefull.

for m in (getclassinstances VRayBitmap) do m.coords.blur = 1

You made my scripting day.