Option to view texel density?

[Megavoxel01]

Hi!
The quad overdraw visualization feature is really handy, so I would like to know if it's possible to add something similar to texture debugging, like visualizing texels per meter or texel/pixel ratio as heatmap?

Search around the web and find something similar:
http://docs.cryengine.com/display/SDKDOC2/Texels+Per+Meter
http://aras-p.info/blog/2011/05/03/a-way-to-visualize-mip-levels/

[baldurk]

The difficulty with displays like that is that for it to be useful, you need to know exactly the UVs being used to sample the texture.

To begin with, there's no reliable way to identify which interpolator is used to pass the UVs from the vertex shader (or even if it's some combination of more than one, or something like that). To solve this would mean some integration between the mesh viewer and texture viewer. It's a bit of a complex UI problem, but doable.

The other hiccup is that there's no particular guarantee that the UVs are used unmodified. E.g. in one case, a 512x512 texture on a teapot has one texel density because the UVs passed from the vertex shader are used as-is. In another case, the UVs passed from the vertex shader are rotated and scaled, giving a higher density. It also means there's not a single texel density - it varies per texture sampled (and even the same texture sampled different times or at different rates).

Of course, none of this is impossible to solve! You could ask the user to input a scale/offset or something like that which would cover 99% of cases that you care about. But what I'm getting at is that it's not the kind of display that RenderDoc is best placed to provide, since the engine already has this information and can do that kind of overlay more easily.

Although I have added a few things that are helpful for profiling, I explicitly do not describe RenderDoc as a profiler. It's a debugger, and I don't want to split my focus while there's still lots to do to make it a great debugger. This would be quite an in-depth feature to implement, so as a profiling function it's not likely to make the cut for a long time. But on the other hand there are related debugging features that have exactly the same kind of requirement - e.g. a companion to the 'wireframe overlay' that instead shows the mesh in UV space on each texture that samples it. The same problems must be solved for that.

[Megavoxel01]

Thanks for the detailed explanation!