Spectral Color Lighting

[coreh]

Objective

Lighting calculations in the PBR shader currently take place independently over R, G and B channels. (As is usual for 3D engines!)

This works well for approximating the common case of polychromatic light sources that cover a broad spectrum (e.g. daylight) but falls short when attempting to render scenes with monochromatic light sources, with spectral colors of a single wavelength (e.g. sodium vapor light).

This PR adds initial support for more accurately rendering of monochromatic light sources, using a new blending implementation based on hue and value. (Instead of the existing multiplicative blending implementation). Since this more complex blending has a cost associated and isn't needed for most applications, this feature is behind a spectral_lighting feature flag.

Solution

• Add a new SpectralColor struct, describing a physically-based spectral color, with a single wavelength (in nanometers) and luminance (in candelas per square meter)
• Add logic for converting from SpectralColor to Color, using the CIE 1931 XYZ color matching functions; (via a lookup table)
• Add a new spectral_lighting feature flag, and a matching SPECTRAL_LIGHTING shader def;
• Add a new monochromaticity field to PointLight, SpotLight, DirectionalLight, AmbientLight, to control how monochromatic a given light source is;
• Add a new monochromaticity_blend() function, to blend colors in a way that more accurately matches the physical behavior of spectral lights. (Existing polychromatic lights are handled as a special case)
• Update all lights to use monochromaticity_blend() whenever the SPECTRAL_LIGHTING shader def is enabled;

Some notes about the monochromaticity_blend() implementation:

• Sending color information to the shaders in XYZ or spectral format would complicate the uniforms and require lots of changes to the PBR implementation, so the inputs of this function are still in (linear) RGB format
• Since the conversion from linear RGB to spectral would be expensive/complex, we internally use HSV as a crude approximation of the color spectrum
• All material base colors are assumed to be polychromatic (Adding support for monochromaticity for materials is relatively straightforward, but not super useful)
• We use hue distance, plus value and saturation to calculate the final output. Our hue distance importantly does not wrap around. (Since magenta is a non-spectral light, we end up using hues values in 240° and beyond for violet and ultraviolet instead, and these shouldn't produce a response from reds)
• A triangle function is used as an approximation of a gaussian function, to calculate the polychromatic RGB response to a monochromatic light based on the hue distance

Testing

• Did you test these changes? If so, how?
• Are there any parts that need more testing?
• How can other people (reviewers) test your changes? Is there anything specific they need to know?
• If relevant, what platforms did you test these changes on, and are there any important ones you can't test?

---

Showcase

With spectral color / monochromatic lighting:

Without spectral color / monochromatic lighting:

spectral.mov

Migration Guide

• When using the spectral_lighting feature flag, the AmbientLight resource will have one extra property (monochromaticity). We recommend adding ..default() to AmbientLight (as is usual for other light types with more properties) to make sure your code compiles with the flag.

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[valaphee]

Might be better to use the approximations https://github.com/cadacoon/polylight/blob/main/src/color.rs#L88

there is probably not much of a speed difference on modern CPUs.

otherwise, really cool to see

[coreh]

That link is not working for me 😕 Maybe it's a private repo, or they removed it?

[valaphee]

Ah sorry, corrected it

[JMS55]

Example looks fine. Code mostly looks fine minus my comments. I'm going to assume the math is all correct.

I'm happy to merge this once my nits are addressed, meshlet support is fixed, and we remove the cargo feature.

[JMS55]

Why make this a cargo feature? Imo, the less features we have, the better, and we should only use them for things that can't be changed at runtime.

Can we make this a field on PbrPlugin instead?

[JMS55]

Suggested change

	/// A color produced by monochromatic light (of a single wavelength)
	/// A color produced by monochromatic light (of a single wavelength).

Maybe(?). Also in all the fields and other places.

[JMS55]

Shaderdefs need to be copied to the meshlet material pipeline stuff.

(Note to maintainers: This seems like a frequent problem with people forgetting meshlet stuff, idk how to prevent it other than me watching out for it 😓)

[JMS55]

Rather than monochromatic light, single wavelength light might be a better description? Idk what the usual terminology is.

[BenjaminBrienen]

@coreh are you still interested in working on this?

[coreh]

Yeah. Sorry I went a bit radio silent on this, was busy with a couple other things. Looks like there's a lot of conflicts, but I have a more up-to-date version (as of the latest bevy release) of this on the integration branch of my fork of that I can extract and add force-push here.