Converting Textures to tiled .TX format with V-Ray (3.x to 6.x). Guide + Scripts.

[^Lele^]

So since there seems no way to automatically just convert the texturefiles I have in my scene

Per-Scene it's circuitous, we should indeed streamline this.

The idea behind the OP was this:
*) User has a ton of assets in various formats. The main script converts all those to a side-by-side TX file.
*) User can open any scene which contained the original texture files and run (optionally the conversion to vraybitmap loaders) the swapper on it, the scene will then have only TX files (if found side-by-side) in the loaders.

The reasoning was that the script can't know in advance if an existing .tx file is current, or needs overwriting because the source (f.e. png) has been updated (assuming so based on modified date is dangerous.).
So, instead of risking multiple conversions of the same file used in various scenes, the texture files this way need to be pre-handled properly by the user: folders and so on should help.
Duplication of files (for example for shared textures) is a minor issue in this day and age, as storage is plenty and plenty cheap.

and I would I would want to manually convert only specific textures using maketx.exe can I use following command line arguments?

--opaque-detect --constant-color-detect --fixnan box3 --oiio -v -u --oiio --filter lanczos3 %%i

I got this from an Arnold Forum so just want to confirm if that everything is also supported in V-Ray. Or if not which would be the recommended command line arguments to convert a texture?

None of those have any impact on the file format itself, they should work just fine as far as reading is concerned.
The script above that converts files on disk uses what Vlado deemed the ideal flags (a few of the above are set by default.).

Notice stuff like constant color, opacity detection and fixnan cost a wee bit of time to calculate, particularly for big images, but will lead to very minor size gains, as the .TX format is already compacted quite efficiently (zipping a 4k image made of one-value pixels is already quite efficient, in other words.).
I hope you don't have textures with NaNs in them, but if converted like the above, those HDR images would produce severe ringing around HDR values, as Lanczos is a sharpening filter, and the pixels in the resulting image/atlases will not be 1:1 with the source, unless range-compresed first.
In general negative-component filters should be avoided.
As makeTX does not detect the image type, you can't set those options selectively to fit the right kind of image being processed (f.e. LDR or HDR.), while performing mass conversions: one needs to know exactly the image type to be converted, and then can set the proper options for it.

They may well work for the images you have in mind, but unless you know you absolutely need any of those options, your best bet is to leave them alone.

Also I have issues that sometimes when loading tx files it pops up a window in my scene. It seems to render fine though. So I'm not sure if something goes wrong during the conversion.

It could well be it's a conversion issue, we'd need the image(s) to be sure.

[JonasNöll]

Hi,

great, thanks a lot for the detailled explanations!
Curious about the flags that Vlado deemed as ideal though. Any way to know what those are, so that I manually convert textures they would be the same like the ones using the batch converters?
I understand the flags should be handled on case by case basis, but it would be great to have the same starting point like the official V-Ray converters.
Maybe this would also get rid of those strange error messages which I am getting

[^Lele^]

The options are defaults in makeTX when run as it is, which is how the script runs it.
The script only allows for two options: hicomp and unpremult, both off by default.
The issues you're having won't go away if you manually converted your texture with makeTX.

[JonasNöll]

Hi, ok great thx for clearing that up!
As it turns out I have those messages for any tx file, also for the ones that come with Chaos Cosmos assets. Always this warning pops up.
It displays and renders everything fine though, so for now it seems it doesn't really have any real affect. Still a bit annoying.
It randomly happends when loading/changing any .tx texture file to the VRayBitmap...

[jackieteh]

Hi, ok great thx for clearing that up!
As it turns out I have those messages for any tx file, also for the ones that come with Chaos Cosmos assets. Always this warning pops up.
It displays and renders everything fine though, so for now it seems it doesn't really have any real affect. Still a bit annoying.
It randomly happends when loading/changing any .tx texture file to the VRayBitmap...

Same here, mine is everytime i click the preview button, the message pop up

[Helgi Smith]

Hi, ok great thx for clearing that up!
As it turns out I have those messages for any tx file, also for the ones that come with Chaos Cosmos assets. Always this warning pops up.
It displays and renders everything fine though, so for now it seems it doesn't really have any real affect. Still a bit annoying.
It randomly happends when loading/changing any .tx texture file to the VRayBitmap...

Can confirm that I got the same issue. A pop-up window appears on some *.tx textures.
3ds Max 2023.3 + V-ray 6.10.04 (Windows 11 22H2).

I did allow all permissions to both Administrator and User, didn't help.
Found this on Chaos Forum. Unfortunately, no solution there.

[Joelaff]

You get the same pop up with VrayBitmaps loading <UDIM> files. Though I don’t believe you get it every time you load one.

I assumed that pop was some “feature” of Max asset tracking that had problems when it is a format not internally supported by Max itself.

[^Lele^]

Found this on Chaos Forum. Unfortunately, no solution there.

The solution would be to talk to Autodesk about it.
As Peter mentioned, we have no hand in that stage of the file loading.