When using EXR’s as textures, the following errors will pop up:
error: Error loading texture tile (1, 1) from level 5, file “\\servername\folder\texture_name.exr” : [EXR TileLoaderParams::loadTile] OpenEXR error: Error reading pixel data from image file “\\servername\folder\texture_name.exr” . EXR file read failed ([PfileStream::Read] (59) An unexpected error occured. )
The following are band-aid fixes I’ve found
Restarting Max
Increasing the cache size in the tiled texture cache. (though our one animator says that )
I haven’t had any luck with “Clear Cache on render end” I thought that it might be caused by the exr’s getting “locked” as unlike other texture formats we have had problems overwriting exr’s whenever max is active.
Linux file servers. Windows workstations. Local renders. No distributed rendering. Happens in both vray 3.6 on 3ds max 2019 and vray next max 2020.2. Also there is a posting from several years back in the maya forum.
Ok could you try to copy everything to your local machine and try render from local disk to isolate that its not any kind of network issue. If the textures load fine with no problem, do a couple of renders to confirm. Then it would suggest there is an issue with the way they are being transferred from network. If they do not render as same issue exists, then that would suggest there might be some problem with the way those were created. Perhaps try using maketex to create .tx instead of tiled exrs and see if that works at all.
Definetly try TX, the performance is superior, your filesizes will be much smaller, because you can store as 8bit TX files.. With EXR you have to go float…
Here is Win compiled version Chaos Docs , For linux you can just install OpenImageIO library, maketx is included inside.
Thought .tx is an option we are likely going to be sticking to exr’s (we actually want 16 bit float textures for our current purposes). Thank you for the recommendation though. Just have to figure out the friction point with the Cache that is causing the hiccup.
I just have this variable set: “VRAY_TEXTURE_CACHE=16000”
which enforces the tex cache to always be quite high, never have issues really. I would strongly recommend exploring .tx because it will keep you float / bit ratio as it is in all your maps, but imho its a better way of working then tiled exr.
From my understanding .tx files are .tif or .exr files renamed with some extra attributes. I set the environment variable yesterday so we’ll see what happens when my teammates come in on Monday. Thanks for the help!
Know it’s only a bitness promotion, the data will still be in the 8bit range, and with 8bit stepping between values.
I prepared a script to convert files to .tx from the disks, and an ancillary one to swap the side-by-side files in vrayhdri loaders. Here.
Colleague of mine has the same error with a Peter Guthrie HDRI. Local render, it renders fine for about most of the 5K render, at 80% done all of a sudden gives him that error. I’m guessing this is network related? All the assets are on the NAS. Only difference that it’s not a tiled EXR I guess.
Adding the environment variable and setting it to 16000 didn’t resolve either. haven’t had time to test .tx either as I have a team with a bunch of assets and projects that are already using exr formatting so it will have to be a “in my freetime” type of thing to test.
If its not tiled, it will be loaded into ram before render starts, as soon as the first ray intersects the first triangle in the scene where HDRI is traced. So if you are not using any tiled textures then all of them would be loaded into ram ahead of time. If it failes mid render like at 80% the issue is with something else. Perhaps it crashed for a different reason. Could be a build related thing.