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

While Next got the tools for the .TX workflow it needed right into the basic installation, 3.x needs a bit of attention to get it to work.
This thread aims to detail the steps, and provide the tools for, the conversion of a scene’s texture, or disk archive, to .TX files, loaded through VRayHDRI maps.

A) You should have “makeTX.exe” in the v-ray bin folder. It should be enough to have V-Ray correctly installed.

B) Use this script to convert the textures on disk to .TX format.

Because the script analyses a folder and subfolders recursively, attention should be paid to the location of the scene’s textures, to avoid lengthy conversion processes.
If you already had the textures converted to .tx, side by side with the original files, then you can skip this step.
The script will try and find makeTX by itself, and if it doesn’t (as is the case for 3.x) it will offer inputting a path manually.
In that case, point it to the path as per point A) above.

C) Open a scene, and use the right-mouse click menu utility called “V-Ray Bitmap to VRayHDRI converter”.
As the dialog comes up, press “convert” without checking any box.
This will convert all the scene’s shaders’ bitmaps to VRayHDRI loaders, preserving gamma.
Notice this part can be fairly slow, because to know a max bitmap’s gamma, one needs to *open* the file, to then query the Max setting.
This will produce storage/network activity, and potentially take quite a long time, but it will spare us from having to fix the gamma values manually later, so overall it’s a huge saving.

D) Use this script on the open scene to change the VRayHDRI loaders (only!) to .TX.
TXSwapper_002.zip
Notice the script assumes that the .TX files are in the same folder of (i.e.: side-by-side with) the original textures.
Running it in quick mode without that condition satisfied will produce a stream of “file not found” errors in the asset tracker, while running the script in safe mode will swap no texture out at all.

E) Render. If the scene worked as expected, you can now delete the source textures, should you wish to do so.

EDIT: makeTX_batcher_006.zip has fixed the issue with the ini file and manual maketx.exe search. It also adds the --unpremult and the --hicomp options.
EDIT: makeTX_batcher_008.zip Added multi-threading with four threads. It should be considered a testing version. I’ve prettied up the listener prints (now also with the size of the file being processed, and all decimal places limited to 2), made the dos window invisible (Thanks Vlado!), and added cancelling messages.
To cancel, simply have the script selected, and stand on the ESC key. Some threads may take longer to stop as they are processing, and i can’t currently quit them mid-work.
TXSwapper_002.zip (1.16 KB)
makeTX_batcher_006.zip (3.95 KB)
makeTX_batcher_008.zip (4.95 KB)

Updated to work with V-Ray 6.x

makeTX_batcher_006.zip has fixed the issue with the ini file and manual maketx.exe search. It also adds the --unpremult and the --hicomp options.​

Hi Lele,

This script does it utilize multithreading or does it just go through one texture at a time?

It’s single threaded, one image per spawned process. Could be done with a deadline command line job if you wanted to thread it, or find <> | xargs -P etc.

It could surely be made to output batch files, but i am unsure if it’d go any quicker that way.
You can always run multiple max instances, and a script per folder, f.e.

EDIT: nvm, i’m looking into multithreading the script itself via dotnet.

EDIT: unnecessary now.

Awesome. Will check it out. Yeah, the focus stealing was an issue with just the one thread. I can only imagine four.

I have a fix for the focus stealing, but thread stopping has so far proven exceptionally capricious.
The dotNet documentation doesn’t specify the stuff i’d need, the MXS one neither, i’m left with trial and crash to desktop. :slight_smile:
I may need more time to come up with a clever way to stop them all, maybe with progress passing, who knows.
Alas, the threading makes Max *extremely* unstable.
Ensure you don’t run it while a production scene is open.

makeTX_batcher_008.zip​ Added multi-threading with four threads. It should be considered a testing version.
I’ve prettied up the listener prints (now also with the size of the file being processed, and all decimal places limited to 2), made the dos window invisible (Thanks Vlado!), and added cancelling messages.
To cancel, simply have the script selected, and stand on the ESC key.
Some threads may take longer to stop as they are processing, and i can’t currently quit them mid-work.
Sometimes, it will even print out that no threads have been left active.
Closing the script will once again call quit to all four threads, just like the manual cancelling, and then all makeTX instances should stop.

It can be found in the Original Post

Thanks, @_Lele I am getting a 404 on the link to the zip file.

Sorry for that, i’ll relink it in the OP.
EDIT: Forum’s playing up a bit.
It seems to be working right now, find it in the list of attached files in the OP.

Hi, one question: V-Ray’s native “Bitmap to V-Ray Bitmap-Converter” only seems to convert textures to tx if the starting point is a standard 3ds Max Bitmap. It doesn’t do anything if the starting point is a V-Ray Bitmap already. Is there a recommended way to convert scenes that use VRayBitmaps already but no .tx textures to tx with a single click? Or would I need to batch create all the .tx files and then manually replace them? What’s the recommended workflow to convert existing scenes to tx that requires minimum effort?

use my scripts. :slight_smile:
The behaviour has been the same for over a decade now (with tiled EXRs before it), and so have been my various scripts.
The swapper in the OP ought to do what you need, so long as you have the tiled files side by side with the original ones.
Feel free to edit the script (it’s nearly natural language) should you want a different path to search for tiled textures in.

When the new scene converter will be ready, this will also be taken care of, of course.

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.

Hi,

great, thanks a lot for the detailled explanations! :slight_smile:
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

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.

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

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.