Since this has been discussed many times, I just want to share an insight.
The value Texture quality is nothing else than the mathematical relation of Optimal texel size to Texel size.
Now there’s the next question: how does RC determine the optimal size of a texel? Is it just the average of all achievable sizes on the surfaces of the entire model?
I’ve been wondering about the ins and outs of controlling texture quality myself, which begins with Optimal texel size setting, but then continues with the Unwrap parameters. If one is interested to glean the most from the source data for high res textures, then I’d think you’d want to closely match Optimal texel size with texel size and pick as high a number as system resources will support (largely about RAM, in this case) for Max texture count. Yes?
I recall Wishgranter stating that it’s a more efficient use of UV space to select 4K textures than 8K or 16K, that this produces the same texture quality, assuming you compensate for the smaller texture maps by upping Max texture count in return. I always see one of the texture maps using just a tiny portion of the whole map for texture, believe this is what he’s talking about. Texturing fills up so many maps, any leftovers have to be assigned to the a map, even if the remaining space is wasted, so better to waste space on a 4K map than a 16K.
Does this understanding accurately reflect RC functionality?
Hmm, I think that the texel size should be as you need it to be. I find that Texture Quality is not a good choice of words (on behalf of RC) because it just states that a higher resolution is probably possible. If you don’t need that, then you don’t have a worse “quality” if that value says 30% or lower. It just means your model could provide a higher resolution. The result might be brilliant. If you need everything you can get, then you are probably right. On the other hand you could set the texel size even smaller and see what happens. In the worst case the texels will be represented by more than one pixel in the UV.
I think you are right about the 4K map but I don’t know why anymore - should be easy enough to find with the new search.
I’m thinking quality is quality, whether or not it’s appropriate to the scope of a project and commensurate with the limits imposed by system resources. Just as one might choose or be forced by economics to stick with standard definition television, foregoing the higher resolutions of HD and UltraHD equates with foregoing (texture) quality. But, I appreciate your point, shooting for quality X is something to be deliberate about, not to waste time and expense gleaning all the value in a dataset (which may should have been downscaled on the front end) when in the end it’s tossed aside to satisfy users on mobile or such. That’s not my case, so was asking if I accurately described the function of the tools in RC driving quality, with an eye on max quality.
All Wishgranter said about 4K maps was that they used the UV space more efficiently, I’m inferring what’s behind that, having noticed that one of say 10 or 20 of my materials usually turns up largely empty of texture data. This is something you only see once you export and view the materials in 3rd party apps.
Hi Benjy, I can’t say anything more useful regarding your specific question.
But on the initial subject:
I realized on the weekend what rubs me the wrong way about the quality term. In my view, it is more relevant to have a relation of the maximum achievable texture resolution according to the source images and the current texel size. Because it does quite often happen that the texture has a lot less resolution than the images would theoretically allow for. Since this is very often an alignment problem, it would be helpful to see where you stand in respect to your images.
Could someone od the RC Team shed some light on this?
I may be on a different page here, sorry. With “quality” I was hearing a choice about how detailed one desires the texture map(s) to be, i.e. resolution (but also max number of those maps). The size and number of maps is relevant to texture quality, but then if I’m hearing you right about how texel size also figures in, you’re wanting to know how to set texel size in relation to resolution of the source data in order to optimize for textures. No? I thought Optimal texel size is what you want if gleaning everything from the source data is what’s important. Increasing texel size I would think would result in going the same direction as downscaling images.
“Since this is very often an alignment problem, it would be helpful to see where you stand in respect to your images”
I’m not following you. How is alignment relevant here?
It’s just that if my interpretation is correct, the quality value gives you only an idea of how your current texel size (texels = pixels on the triangular faces) relates to optimal texel size. So it’s tied to the current unwrap and not to the source images. It often happens that if the alignment isn’t ideal (or something else I don’t know about is wrong), then the texture does not resemble the max resolution of the images but some badly washed out imitation with a lot less details than on the source images. And in my opinion that is then bad quality, as in a worse result that can be achieved. Whereas now it just tells you a geometric relation to something called Optimal Texel Size, of which we don’t know how it is determines (but is in my view directly attached to the unwrap and not the source images).
Look here, the first attached file:
I figured out now that the reason for this is indeed that the texels are bigger than my orthophoto resolution, that’s why they are represented by several texels. So texture quality only tells me how far off my current tesel size is from the ominous “optimal” texel size. From my example I know that the resolution of my source images would allow for a MUCH higher resolution (or smaller texel size) as you can see in the attachement of the link. But still my example says tx quality 62% and determines the optimal size at 0.0011 instead of the 0.0018 of my current unwrap. Guessing from my screenshot, I would say the images would allow for a texel size of at least 0.0008. That again is relatively close to 0.0011, so maybe the optimal texel size is just exactly what I am looking for…
I’ve read through this and your linked post and realize I’ve definitely been on the wrong page. Thus far I’ve been using Max texture count and size of maps to tap into what’s in the source files, but with no idea how much more detail isn’t being used. Since I’m my deliverable is real time rendering, and yours is print or at least being able to zoom way in with orthos, that explains why you’ve pushed on maxxing quality, and I’m happy with exploring virtual environments within inches of a surface without losing frame speed. I see by moving away from max texture count and using Fixed texel detail or such, that this discussion of quality explains the shift in meaning. You’re way ahead of me here, let’s get on a Teamviewer session soon and go over this, much appreciated.
Not too sure that I’m too too far ahead - some of it is guesswork! 
Another reason why I need to push is that I use a 12 mpx camera and you 42 !!!
I think you still win in terms of absolute resolution… 
I got it confirmed: Optimal texel size is an average of the reprojected pixels of the images on the mesh.
That means for a project where all surfaces are at more or less the same distance to the camera, the value will be very accurate and reliable. With more complex geometry, it is only a rough guideline and there should be smaller texel sizes possible…
Okay, that now makes good sense. So, in those cases where the subject matter forces you closer to surfaces in order to get coverage, but you don’t care about using that extra detail, just want coverage, the Fixed texel size/Optimal texel size option would seem to be the best fit. And when say you have “hero objects” in the scene, regions or objects with special interest where you would benefit from presenting greater detail, lowering the Optimal texel size might get you there, but at the expense of blowing system resources on many other regions where that effort is wasted (since there’s no more detail to squeeze from the source imagery than using Optimal texel size), this is where you’d want to use Adaptive texel size, which then provides smaller texel size when the camera was closer to surfaces, and bigger when farther. Nice.
That’s a very good summary!
So in a way the optimal texel size is what I was looking for - a way to determine the maximum that is achievable with the source images. I still think that the term “Quality” in this context is confusing. If it were only an image we are talking about, we would not necessarily say that an image with higher resolution has a better quality - we would say it has a higher resolution. Quality can mean much more than resolution. So maybe it should rather be called that? Texture Resolution 70% - everybody could easily guess what that means.
Agreed, “quality” begs to be qualified. When I implemented this workflow the other day, moving away from using Max texture count, it was on a test I shot in my studio, have my CD collection on a shelf. I kicked out a render from RC, was easily able to read each the labels on the spines. To see the labels this large in the real world I’d have to wear magnifiers to view within 4-5".