I want to try multi-res exr convertion for memory conservation, but I’m not keen on creating a load of massive 16bit files if I don’t need to (or at least my IT manager won’t be).
Has anyone come across a GUI based converter that can output 8bit files? The Vray one can only do 16 or 32bit
I’m also not handy enough with coding to handle the maketx solutions I’ve found so far.
Have a look at this, it works really well.
makeTX.exe does just that (which is why we moved away from tiled EXRs, which didn’t support 8bpc).
You can convert with the provided scripts (in the max UI, or the one i prepared, if that one comes without warranty.)
I’m on 3.6, are these bundled with that, or only next?
I’ve bought the Pixamoon script already, but it would be good to know for reference.
For 3.x, you’ll need to download makeTX from our website (you’re also suggested to use this build, not any other found in the web, for best results.), put it into the tools folder of your v-ray installation (f.e.:“C:\Program Files\Chaos Group\V-Ray\3ds Max 2019\tools\”), and use my script as offline converter.
Next will use makeTX natively from the RMC scripts.
Both V-Ray versions support the .TX format just fine, in any case, regardless of how they were made.
Oops, I already bought the Pixamoon script. No bother, it looks handy in other ways.
To edit textures, are people editing a tiff, then converting that to .tx? It seems you can’t open a .tx in photoshop.
far from me telling you you did wrong supporting a fellow scripter! 
To edit textures, are people editing a tiff, then converting that to .tx? It seems you can’t open a .tx in photoshop.
In general, as you well spotted, the conversion to .TX is a post-process to the editing.
So in theory edit → publish the (editable?) source in whichever format you prefer → convert to .TX for rendering.
Yeah, the pixamoon guy is great, I think I have all his main scripts now!
One more thing, I want to test the difference in memory usage between Tiff and tx, what part of the log should I be looking at for memory dedicated to textures (vray 3.6)?
There isn’t a memory report for those in 3.x, i’m afraid.
What you can do is render the scene before and after .TX conversion, and check the 3dsMax.exe process’ allocated RAM in the task manager.
Notice that once textures are tiled, they will obey the tiled texture cache size (by default, at 4GB), so make sure to set that to the size of your system RAM (say, 32000), or 0 (i.e. use all available RAM) to avoid capping your effective RAM usage (and incur in some performance penalty as they are swapped in and out of RAM).
All good stuff, thanks. I wondered if that was the case.
Also I lied: two more questions. Where are the converted maps stored when running the EXR convert in-scene, out of interest?
And do you have a script version of the ‘convert bitmaps to VrayHDRI’? I want to be able to convert bitmaps on a load of asset files without opening them individually.
Thanks Lele!
Side by side with the originals.
And do you have a script version of the ‘convert bitmaps to VrayHDRI’? I want to be able to convert bitmaps on a load of asset files without opening them individually.
Yeah, the one i linked above does that. Make sure you do not remove the converted files’ append string, or the script won’t work.
You need “” to make the string work.
In fact, you’d need the @“your\path\with\these\slashes” format, or need to swap the slashes direction around ( / ), or to double them up so they are escape characters ( \\ ).
But why are you editing the script, may i ask?
Does it error out and not find makeTX by itself?
EDIT:Oh, i see. Why not put the makeTX file in the v-ray bin folder? User Rights?
You mean …3ds Max 2019\Plugins\vrayplugins?
“C:\Program Files\Chaos Group\V-Ray\3ds Max 2019\bin”
Bah me, it won’t work with 3.x, only with Next.
Luckily, i modified the original script a little bit to allow for custom maketx path input.
It will still make its checks on the file existence, but i am not exactly sure i covered all bases, so please poke back if the script errors out.
On the plus side, it’ll save a small ini file of its own in the max’s plugcfg folder, and remember the last choice.
makeTX_batcher_002.rar (2.96 KB)
It may be a gamma issue on that map.
Wrong gamma would make it brighter or darker and change the opacity as a result.
Have you tried changing that in the VRayHDRI loader (i.e.: 1, 2.2, 0.4545)?
It should be noted you can achieve gamma matching automatically by converting the loaders to vrayHDRI first with the right-mouse click utility.
I believe you’d be missing a tool to replace the disk-converted .TX files with the bitmaps, but that’s very easily written, i’ll post you one later.
EDIT: Ignore this thread and the previous links to scripts, they all had a bug which prevented them from converting anything at all. A new thread with the fixed and improved scripts and clear instructions will be up shortly. (will link it here too.)
So, go here for the correct workflow, and most importantly, the fixed scripts!
@busseynova i tried the file, in my case (with 3.6) i only see very minor differences in the resulting alpha between bitmap, and VRayHDRI, and between VRayHDRI in 2.2 gamma vs. sRGB mode.
It’s to be expected, and is really hardly noticeable (i see the differences at the max zoom only).
This though, in the case of the leaf shader applied to a flat plane, rendered by itself.
EDIT: For the leafy patch, you want to set the opacity mode for the shader to “clip”, changing it from the default of “normal”.
That will fix the render, and rendertime, with or without .TX files. 
Cheers @_Lele . I’m gonna have to have a closer look at these materials anyway as they appear to have a transparency map within a 2-sided which is probably slowing thing up a lot. This is all really helpful though
They do look ancient, for setup.
You can likely get equivalent, or much better, results in a fraction of the time with a 2sided material.