bevyengine
Histograms
What problem does this solve or what need does it fill?
I'd like to have objective measures of what cameras are rendering in order to improve lighting and overall scene composition.
Histograms can help with this. This is a nice article- some takeaways:
- Allows game makers to objectively talk about a scene's tonal range.
- Example conversation: "Your scene looks good but perhaps lacking a bit depth. The histogram shows it's lacking in the shadows- perhaps try that?"
- Allows detecting clipped highlights which might be a sign of overexposure. This is shown by the histogram having a peak at the rightmost (max brightness) edge.
- Similarly allows detecting a peak at the leftmost (black/shadows) edge, which could hint at perhaps increasing ambient lighting might balance the lighting
- Provides a way to talk about the amount of contrast in the scene by looking at the shape of the histogram.
- Example conversation: "Your game has a nice parallax effect, but I find the background distracting. The histogram shows the background has high contrast, perhaps try lowering it?"
What solution would you like?
A way to display the histogram of a given render target post render.
It would be nice if it could be presented visually via an Image. Such an image could be displayed via UI nodes.
Implementation strategy 1: On-demand
If the histogram isn't required often, a strategy similar to taking screenshots could be used.
Implementation strategy 2: GPU real-time
A compute shader could sample the render target's renderered texture for all pixels and count the colors. A float buffer with 256 capacity could be used to sum occurrences then normalized after.
A second shader could then render the histogram to a texture (which does not need to be high res, perhaps 256x256) by reading from the buffer.
Future work
- Allowing per-color-channel histograms, either presented separately or overlaid in a single multi-colored histogram
- Dealing with arbitrary texture formats
- Allow choosing after which place in the render graph the histogram is created. Perhaps some users are interested in it before post-processing, other users might be interested after post-processing, or even both
- If real-time: Perhaps some configurable time averaging is needed to not have the histogram jitter too much across frames
Additional context
The linked article's example presentation is a good starting point visually.
If the real-time version is implemented it would be good if the background of the histogram supported transparency such that it can act as a debug overlay without being too distracting.
