Shoulnd't have multiplied by diffuse BRDF result. It should be encoded
in diffuse-vs-specular split, and the cosine term is already taken care
of in sampling.
Only engage soft particles/blending after a certain distance. Makes
certain see-beams-through-weapons visual glitches disappear.
Engages soft particles with a smoothstep so the don't immediately pop up
after a certain distance, rather appear gradually.
There are lots of empirical (and less-well undrestood things) scaling
color values in native code, it makes sense to consolidate them in one
place:
- less weird math in shaders. shader should be as streamlined as
possible
- one big block of weird math is untangleable in the future when we get
to work on light and clusters
1. Sample point lights as spheres. Use existing pdf value (`one_over_pdf`), as it was basically correct.
Compute max_theta angle based on light radius and distance to the
center. Sample cone direction based on this theta angle, in z=n space.
Don't do anyhting fancy wrt horizon, etc.
2. Sample environment light with max theta derived from real world sun
solid angle. Uses the same cone direction sampling.
Known issues:
- still get some NaNs sometimes, esp. on test_light map.
- Too many different light sources try to use the same code. They should
be split.
Relevant issues: #266, #151
This makes math even more stable, but it removes imprecisions that were accidentally helping the rendered image. Thus it looks a bit darker.
Fixing that would need proper sampling, with disc angle and what not.
Guard against:
- spot_attenuation being too small
- pdf denom being zero. It could be inverted, e.g. not pdf=1/denom, but one_over_pdf = denom and then multiplying color with that directly, but we'd still need to clamp it to positive values.
As opposed to more compute intensive local-frame sampling. They seem to
produce the same results.
Local-frame sampling might still be needed for specular bounces.
Introduce several shader debugging/validation tiers:
1. Basic key values validation, to make sure there are no nasty NaNs or
invalid values written to G-buffers. Enabled by `DEBUG_VALIDATE` macro
in debug.glsl
2. Key value validation with whining: use `debugPrintfEXT()` function to
report any invalid values to Vulkan validation layers. Enabled using
`DEBUG_VALIDATE_PRINT` macro. Currently this is the one enabled, as
it allows us to catch any serious numerical issues during development
and testing.
3. Extra validation and printing for intermediate values. This is for
deeper investigations, and enabled only there temporarily.
Ivan Avdeev
Ivan 'provod' Avdeev