A colleague of mine was wondering if it was possible, to create a render element that could analyse if the resolution of a (diffuse) texture of an object (depending on resolution of the render, distance of the camera, …) is sufficient. As an example: if the resolution is good, the color of the object could be green, if the resolution is too small, color could be red, or if the resolution is too high it could be magenta, or barely big enough, orange. Just an idea.
Thanks.
a mip-mapping render element, so to speak, but also with analysis about textures that are too small and will be resized.
I would love that!
It’s definitely an interesting idea, but i am not entirely sure about feasibility.
What qualifies as “sufficient”?
Nyquist limit? More?
What if a texture is bigger than the expected “sufficient” value?
Also, what if a texture is applied, f.e., as displacement, or other such non-shading, invisible channel (e.g. to drive particles)?
does mip-mapping currently take displacement textures into account?
How does mip-mapping to its calculations?
I think smarter people than me can answer that question better 
You would get a different color, implying that the texture is of more than sufficient resolution. (Ultimately there could be some sort of gradient of colors like the sample rate pass)
Might be nice to be able to create multiple render elements with a drop down menu as to what texture the RE needs to analyse (diffuse, reflection, displace, …)
a) Mip-mapping alone doesn’t tell us if the texture resolution is “sufficient”, it only tells us which MIP level was selected: the top level of a 64px square texture is likely not sufficient, but it’s the highest available.
MIPs aren’t a good metric, as such.
b) The question of what constitutes a sufficient resolution isn’t trivial as it may seem on first read: as i see it, it has to do with user intention, and that is a border we can’t currently cross with code (and even then, if we had AI available for this, i’m not sure i’d like it to perform that task.).
Twice the frequency of the output (said Nyquist limit) would be enough for most scenarios, but not all.
Equally, a texture which didn’t have twice the detail frequency as the pixels on screen wouldn’t necessarily be “insufficient”.
I may want, in other words, a comparatively low-res image as mask to something else (f.e., a 1px square image of a color.).
On the other end of the spectrum, particularly where memory is of issue (be it RAM or VRAM), a texture could be too big for its intended use, so it wouldn’t be safe to just mark it as “sufficiently big”.
c) I find also not trivial to answer the question about maps in non-visible channels, as those maps may not be available at all during rendering (f.e. a static displacement will generate the triangles, and then throw away the bitmap which made them. A particle distribution would have the bitmap implicitly within the system, the renderer not any wiser of its existence. The cases are many.).
d) Also, animation would make this formally invalid from a logic standpoint: a camera tracking into a shot would have textures become too small, or too big, for a given frame and view, changing each frame.
It wouldn’t much help in troubleshooting, but for those textures deemed too small, or too big, across the whole animation range. Even then, one would be back into the realm of point b).
I’d *love* one such tool, but even to make a PoC in maxscript, i find too many peculiar issues i can’t get around of.
Please keep bouncing ideas on this, perhaps i am just confused.
EDIT: this is very similar a problem as picking realtime lightmap sizes (f.e. in Unreal Engine) per object. That too is equally unsolved an issue, that i know of.
Thank you for your time Lele. I know there are A LOT of things that need to be considered and limitations to be taken into account for even creating a PoC. For instance I create a lot of complex shaders with more than 1 diffuse map in different composites together with a few noise maps and or masks, that all have their own mapping, so it would be hard for those shaders and their textures to be analyzed because who will decide which one of the maps will be taken into account for analyses. (Unless all of them and some sort of analyses is performed per object, similar to the memory consumption tool from Update 2 with some sort of table instead of an RE).
I liked the idea of my colleague but I had my doubts as well, just wanted to throw it out here. The question came forward out of our current workflow, for creating a photogrammetry model of half a city, hence he asked me: how can I be sure that the resolution of the texture is big enough for this shot, is there a Render Element that can show if the resolution is too low or too high for this shot/resolution.
Well, for this specific problem, i can offer a straightforward solution, eheh.
Make the base textures as big as you can, and then convert them to tiled TX.
The base resolution being humongous (64k? go ahead!) will ensure the MIP level chosen will be just right for the given camera view (and you have always the “blur” available to move up and down MIP levels.).
True, that’s one of the solutions I suggested as well, but that means they’d have to calculate the texture that big in the first place as well and they like to be very ‘cheap’ when it comes to calculations 
. On the other hand, if they had to analyze if it is big enough in the first place then realize it’s not, and recalculate a bigger version, they’d probably lose twice as much time 
.
.tx maps only grab what is needed from disk. You can have a 64k wide texture but if vray only needs the 1024 version, that’s what it will load.
you may get slightly bigger file sizes on your server if you are used to .jpg textures but they’re incredibly efficient.
Wouldn’t that same system be able to tell what it needs, even if we are talking about bigger sizes?
if vray knows that it had to use the smaller texture for a specific area, it knows that it is too large…
Sorry @lele for being so dumb, but I don’t understand the problem yet…
It can tell you which mip level of a tx map it would load, but i think lele’s questioning was what real benefit that would provide. and how it would decide which to show when the diffuse is 32k wide but the gloss map is only 5k, and theres a 1024x256 mask in play too. Would it flag that material as too low, even though it has a 32k diffuse?
If you’ve got a render element that tells you that a bunch of textures are too big or too small i’m not sure what you’d even do with that information. meticulously pore over the channels and re-make textures from scratch? Seems like it would be easier to make them as big as possible and see where you end up from there. always better to optimize down.
Presumably most people use 4-6k textures wherever possible. running out of memory only really happens on gpu and that automatically mipmaps textures anyway. Most cpu memory issues are due to 10k wide framebuffers and displacement and can always be worked around.
If you use the highest resolution textures possible and occasionally make a lower res copy for distant objects you’ll be fine. or you can turn them into .tx maps and never have to think about it.
Do you know if of any converter that automatically takes my thousands of textures and converts them for me?
Btw, I wouldn’t even need a render element but a list would be enough to get a good overview.
Do tell, i don’t understand it either!
Which is why we’re bouncing ideas in the first place!
I have to say @Neilg makes another valid point about more than one texture per shader, and about how to proceed once one knows a texture is too big, or too small.
Now, if we were talking of getting the actual bitmap size, instead of the screen projection thereof, so to flag, say, anything below 4 Mpx, it would be much much easier to do (but then i suppose tools and scripts which can sort bitmaps for you are aplenty…).
However, if one wanted to be exact in their budgets, the real way forward would be tiled .tx files, as they would also strictly (enough!) obey the texture memory limit, when set.
@MANUEL_MOUSIOL there is a “makeTX.exe” file in the bin folder of your v-ray install.
A batch file should be able to parse subfolders for you.
Alternatively, i could build quickly enough a simple skeleton script to do the same thing.
Notice the “simple skeleton” characterisation there: i am not planning on having the script work out every possible naming conundrum on the planet, but i can probably make it clear enough for anyone to modify it at will (and so work with their own specific naming convention.).
The third option would be to make a scene with all your textures in, and then ask the vrayhdri converter script to convert them to .TX.
Here is a simple tool to convert your file, of type “*.bmp”,“*.cin”,“*.dds”,“*.dpx”,“*.exr”,“*.hdr”,“*.jpg”,“*.jpeg”,“*.png”,“*.ptx”,“*.rla”,“*.sgi”,“*.pic”,“*.tga”,“*.tif”,“*.tiff”.
Those are the formats it *should* support, please report any issue, in case.
A word of warning: it’s hard to impossible for me to pick errors in the conversion.
It will *NOT* work in places where you have no write access, and simply skip the conversion (but it won’t error out, or warn you about it!).
Such folders are, f.e., the 3ds Max folders, and most of those in the “Program Files” and such system locations.
If you’re converting from a library you use often, there should be no issue.
Run the script, pick a root folder, wait while it scans (it will tell you it is doing so) until it shows how many files it found.
If all is good, the “Go” button will turn on, and you’ll be able to press it to start the conversion.
It currently runs serially, a file at a time, to avoid killing you RAM and disks should the conversion find many big files.
I’m unsure if i can make it gently multi-threaded (as opposed to overkill), but i have little hope of being able to do so.
It can however be run on multiple max instances, a few folders per script, to speed up big conversions.
the adventurous ones (but don’t say i didn’t warn you!) can change this line
vrayshellLaunch baseCmd waitExec:true
to
vrayshellLaunch baseCmd waitExec:false
to have it run massively parallel (one makeTX instance per file.).
makeTX_batcher_001.zip (2.42 KB)
It is definietly difficult to show all the textures used (diffuse, glossiness, bump etc) in one map.
So either a list would be good or multiple render elements need to be created, with the different slots in the material. One for diffuse, one for bump, one for gloss etc.
I would just love to know how much a bitmap was resized to fit the current rendering.
Sometimes even mip-mapping wouldnt cut making use of all my vram and I had to go in and use Pixamoons bitmap tracking/resize script to make the largest textures smaller; I guess then they truely werent big enough for my rendering but they did the job; but really KNOWING what size would be the appropiate would help, instead of having to go and analyze the rendering by my own old eyes.
@^Lele^ thanks for the script! I will try it out with a separate folder so nothing gets overwritten or broken.
That alone would be difficult. But that’ just the start. Imagine having multiple bitmaps with different tilings and sizes for example in a mix or composite map within the diffuse slot. How should that be handled? Sometimes when I make landscapes for example I have something like 8 or more different bitmaps just in the diffuse slot.
it would probably be hard to read that RE if you stack the textures with different opacity values. if they are masked more or less black and white, it would be easier. but you are right…in the end we would have colorful mash that noone can understand haha
You’re welcome!
It will just create new files (and overwrite old .tx ones) only.
Just make sure it’s a set of folders for which you have write rights, and it ought to be as easy as click, click, wait.
I use the .tx file linked below to analyse and debug resolution issues. It’s a regular texture file, but with every mipmap resolution step replaced with a unique pattern and color. Add it as an extra text element, and it simply exposes exactly which resolution VRay picks in any given situation, depending on resolution, filter size, camera distance, etc.
Our texture artists and modellers use it to roughly estimate how many udims at which resolution are needed for a given model. Like, if we do X udims at X resolution, is that enough? Or do we need more udims to avoid having to work with 8k or 16k files?
The beauty of it is that it’s an ordinary texture, and it’s simply revealing what VRay is doing under the hood to that or any other texture in a given situation. A dedicated debugging render element would be nice, but it would need the same filtering options as you find in a file node.
I had to track these links down through the internet archive as the original blog seems to be down. Get them before they disappear.
Here’s the texture itself:
http://www.j3pnyc.com/goodies/j3p_uv…_debug_8ksq.tx
Here’s a reference sheet of what the colors and patterns represent:
https://web.archive.org/web/20180520…ion_legend.png
