`throughput` should be scaled based on BRDF. I.e. diffuse bounces should
be scales by base_color at the very least.
This fixes lighting being too bright after 3-5 bounces.
Our gaussian blur is incorrect, as it doesn't preserve luminance, and
the final imaga ends up being darker than it should be.
Do a box blur as a simple test. It does result in a correctly looking
white furnace test image (modulo square blocks and luminance leaking).
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.
Ivan Avdeev
Ivan 'provod' Avdeev