simple support for local lights on mtoon

[HifiExperiments]

closes #1131

this adds support for basic additive local lights on mtoon. like UniVRM and Lyuma, this doesn't affect the lighting direction used for MToon shading, because we don't have access to the necessary information in the deferred pass.

this ended up being quite a bit simpler than I originally thought once I realized I could store which surfaces were MToon in the deferred buffer using existing mechanisms and use that to skip directional lighting and only apply local lights. I've also added a framebuffer debugging option to luci to visualize just MToon surfaces

Test plan

You can run this script to create a bunch of MToon spheres and confirm that they are now affected by light entities. Note again that this lighting is additive, so a full bright MToon surface (1, 1, 1) will still appear white when lit - although if you have bloom enabled the surface will still glow with the light color since bloom uses the unclamped color.

Funding

This project is funded through NGI0 Entrust, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.

[ada-tv]

This looks relatively simple. I wonder if #1793 could be adapted to use this too after this PR is merged and I rebase the forward lights branch

[HifiExperiments]

This looks relatively simple. I wonder if #1793 could be adapted to use this too after this PR is merged and I rebase the forward lights branch

yeah we’d just calculate the local lighting as you do elsewhere and add it to the color in the mtoon block, should be pretty simple!

[JulianGro]

This is certainly a lot better than before.
One thing that is a bit weird is how little effect local lights have without key light versus with key light:


The pinkish tint comes from the ambient light.
Turning off both ambient light and key light…:

(Still a lot better than the perfect black on master.)

[ksuprynowicz]

Everything looks good :)