shunsukesaito
commented
5 days ago @ligETHZ sorry for late response. Indeed, applying sin to the highest level of mipmap is the bug. However, for preconvolution with different roughness value, the sample density needs to be compensated by the sin.
una-dinosauria
https://github.com/facebookresearch/goliath/blob/570a3324597b749929feda0a2465f76b2c603477/ca_code/utils/light_decorator.py#L67
In the above line, the environment map is multiplied with the sine of the latitude, which would normally be used to compensate for the fact that sample density is significantly higher towards the poles when performing integration.
However, to my understanding of the code, the environment map is never integrated along the pixels; it's evenly sampled in direction space instead.
Specifically here:
https://github.com/facebookresearch/goliath/blob/570a3324597b749929feda0a2465f76b2c603477/ca_code/utils/envmap.py#L316
https://github.com/facebookresearch/goliath/blob/570a3324597b749929feda0a2465f76b2c603477/ca_code/utils/envmap.py#L259
Where samples are computed based on sigma and query direction. However, as the query directions are computed independently of the latlong pixel density, and sample_uv() always computes light intensity based on the nearest pixels regardless of how dense they are, is it not the case that the rescaling factor instead just makes lights towards the poles significantly darker than they should be? Or am I missing something?