You can monitor the individual nodes by simply pulling the end pin to the postprocess output, so you don’t have to guess what is happening at a particular point in the sequence. Anyways, it should work, you pry forgot to set something up correctly. I am using a depth map in the version above, but you don’t have to do that, so just simply disconnect the multiply and divide nodes around the ceil node, and just use 16.0 as a constant value for both operators. I also am mixing back the original content at the Add and Div/2 nodes, but you can pull the end node of (x*norm) mul result instead and that’s it.
This only is a cheap way to set the luminance, but it’s far from accurate. It’s better actually to split the channels according to the YCoCg color space, and you should be able to modify only the luminance Y channel. The engine already have this colorspace conversion thing implemented, it pry just not exposed to materials. However, this simple math code can be easily fitted into a custom node, only the math stuff is enough to Float3 as RGB in, Float3 as YCoCg is out. And then convert it back to RGB before outputing it to the postprocess node. I implemented both conversions in custom nodes and i can freely modify the luma this way.
I’m using a different gamma curve here, but the colorspace conversion really helps to use the full range of the luminance.https://youtube.com/watch?v=90qPpMaVNps
The banding gets too distracting to me. The clouds and the distant city at the outside scene are simply just disaster. Maybe a different quantize algorithm that weights more to the actual color differences (rather than only the luminance) would be a better way to set this up, but in the end the textures could really be the key to make the inkish effect more apparent on the entire scene and you don’t really have to quantize the color informations at all, the sobel should be enough that way.