sebh / unrealengineskyatmosphere Goto Github PK

Hi Sébastien,
thank you for sharing this awesome technique. I could already implement the approach in a toy project vr space flight simulator. https://www.youtube.com/watch?v=LGN-KqRX9Z4
Since the simulation is rather realistic I have a non-spherical earth.
Where would be the best place to skew the calculations so that the horizon (EarthBottomRadius) starts 21km lower on the north/south pole?
I assume replacing all ray to sphere intersection calculations might be too costly for a non-spherical on the Oculus Quest.
Thanks in advance.

Hello Sebastian,

Great contribution and thanks for sharing production ready code. One of the things I noticed is no matter the SKY LUT Format. (F16, F32) or resolution there will be visible banding.

1. Due to Horizon texel compression. The top of the sky has low texel count.
2. Due to the smooth transitions for Gradients of sky rendering.

I was able to fix this by applying a Jitter at the end post Tonemapping. I tried this pre-tonemapping and it won't work so well due to range of F16 or F32.
I think Unreal defaults to TAA which is inherently eating up these banding artifacts.

For any one interested here is sample code. This works well for F16 SkyLUT 256 x 144

/**

• Interleaved gradient noise. Jorge Jimenez
• Reference : https://blog.demofox.org/2022/01/01/interleaved-gradient-noise-a-different-kind-of-low-discrepancy-sequence/
  */

inline float sampleInterleavedGradientNoise(float2 pixelPos)
{
const float3 magic = float3(0.06711056f, 0.00583715f, 52.9829189f);
return frac(magic.z * frac(dot(pixelPos, magic.xy)));
}

inline float3 applyDitherToPixelColor(float3 pixelColor, float2 pixelPos)
{
const float2 scaleBias = float2(1.f/255.f, -0.5f/255.f);
float noiseDither = sampleInterleavedGradientNoise(pixelPos) * scaleBias.x + scaleBias.y;
return (pixelColor + noiseDither);
}

In order to have the project built using SDK v10 and Toolset v142, I had to include #include <string> in Dx11Device.h.

The multi-scattering precompute shader numerically integrates incoming light using sample rays distributed uniformly along polar coordinates:

As always, thanks for publishing this excellent paper and the very helpful example code regardless.

only ViewHeight and forward are changed.

I am a little bit confused about the way, aerial perspective froxels are supposed to work. I mean, I understand that basically they store the integrated (in-)scattering and transmittance of a slice at a certain depth, however this also implies that if the sun is obstructed by terrain, all scattering effects will still be applied on top of the geometry, even if one would not expect them to be there. I realized this was an issue, when moving the sun behind a mountain and was still able to see the mie halo. I naively disabled mie scattering for AP, however I then realized, that this made no sense for situations where mie scattering is expected, i.e. if the sun is (partially) visible.

The following image demonstrates what I mean. Right is mie on, left is off. Top is sun obstructed, bottom is with sun visible. Basically I want to get rid of the mie effect in the top row, whilst retaining it in the bottom row.

I also tried pre-multiplying the transmittance with the luminance when applying the AP, which reduced the effect, but did not completely eliminate it - especially, if the obstruction happens by geometry that is far away from the camera. This makes sense, given the way I understand this implementation of aerial perspective. So... shouldn't the terrain already be considered when computing the froxel? Do you have any advice on how to solve this issue in an adapted implementation?

Hello,
First of all, thank you very much for providing the implementation example for your excellent document!
I tried to implement it in my own project, but now everything that is not the sky is way too bright with a 10.0 exposure used in this paper and in Bruneton's paper.

If I understand the equations and the code, the HDR buffer contains luminance values.
According to wikipedia (https://en.wikipedia.org/wiki/Orders_of_magnitude_(luminance)), an average cloudy sky has a luminance of 2 kcd.m^2 but in this implementation it seems that the bright blue sky has an order of magnitude of 10^-1 cd.m^-2.

Is a 10.0 exposure appropriate for outdoor scenes? Am I missing something with the values in the HDR buffer?

Hello,
Thank you for sharing this code. It helped me a lot in understanding volume rendering algorithms.
I'm reading the path tracing implemention. I‘m a little perplexed by the following code. With uniform sampling, phaseValue / phasePdf is not constant 1. Why throughput is not updated?

First off, thanks for publishing this code and the corresponding paper! Very cool work.

I'm working on an implementation, and I'm a bit perplexed by the use of SampleSegmentT in the core integration loop. It looks like it has the effect of shifting the sample positions forward by 0.3 times the interval between samples. I also didn't see any trapezoidal weighting as used in Bruneton's method.

Could you clarify the reasoning behind the integration method you went with? Thanks!

git submodule update --init does nothing.
I assume something is wrong with repo setup.
Maybe something like this:
https://stackoverflow.com/questions/39765663/git-submodule-init-does-absolutely-nothing

Not critical because it is possible to manually clone imgui and tinyexr.