Атмосферное небо рассеяния от космических артефактов


20

Я нахожусь в процессе осуществления атмосферного рассеяния планет из космоса. В качестве отправной точки я использовал шейдеры Шона О'Нила из http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html .

У меня почти такая же проблема, связанная с fCameraAngle, за исключением шейдера SkyFromSpace, а не шейдера GroundFromSpace, как здесь: http://www.gamedev.net/topic/621187-sean-oneils-atmospheric-scattering/

Я получаю странные артефакты с небом из космического шейдера, когда не использую fCameraAngle = 1во внутреннем цикле. В чем причина этих артефактов? Артефакты исчезают, когда fCameraAngle ограничен до 1. Мне также, кажется, не хватает оттенка, который присутствует в песочнице О'Нила ( http://sponeil.net/downloads.htm )

Положение камеры X = 0, Y = 0, Z = 500. GroundFromSpace слева, SkyFromSpace справа. введите описание изображения здесь

Положение камеры X = 500, Y = 500, Z = 500. GroundFromSpace слева, SkyFromSpace справа. введите описание изображения здесь

Я обнаружил, что угол камеры, кажется, обрабатывается очень по-разному в зависимости от источника:

В оригинальных шейдерах угол камеры в SkyFromSpaceShader рассчитывается как:

float fCameraAngle = dot(v3Ray, v3SamplePoint) / fHeight;

Тогда как в пространстве от космического шейдера угол камеры рассчитывается как:

float fCameraAngle = dot(-v3Ray, v3Pos) / length(v3Pos);

Однако различные источники онлайн повозятся с отрицанием луча. Почему это?

Вот проект C # Windows.Forms, который демонстрирует проблему и который я использовал для генерации изображений: https://github.com/ollipekka/AtmosphericScatteringTest/

Обновление: я узнал из проекта ScatterCPU, найденного на сайте О'Нила, что луч камеры отклоняется, когда камера находится над затененной точкой, так что рассеяние рассчитывается от точки к камере.

Изменение направления луча действительно удаляет артефакты, но создает другие проблемы, как показано здесь:

Отрицательный луч для угла камеры

Кроме того, в проекте ScatterCPU О'Нил защищает от ситуаций, когда оптическая глубина света меньше нуля:

float fLightDepth = Scale(fLightAngle, fScaleDepth);

if (fLightDepth < float.Epsilon)
{
    continue;
}

Как отмечено в комментариях, наряду с этими новыми артефактами это все еще оставляет вопрос, что не так с изображениями, где камера расположена на 500, 500, 500? Такое ощущение, что гало сфокусировано на совершенно неправильной части планеты. Можно было бы ожидать, что свет будет ближе к месту, где Солнце должно попадать на планету, а не к тому месту, где оно меняется со дня на ночь.

Проект github был обновлен, чтобы отразить изменения в этом обновлении.


1
Я хотел бы ткнуть ваш код и попытаться помочь, но, похоже, для установки XNA для VS 2012 мне требуется VS 2010 ...

Я удалил все внешние ссылки на проект, и проект больше не нуждается в XNA. Это простой проект Windows.Forms, и для его запуска не требуется ничего особенного. Следовательно, преобразование в более старую версию Visual Studio должно быть довольно тривиальным.
ollipekka

Вы говорите о пиксельных артефактах к центру сферы в вашем первом изображении? Это не должно действительно влиять на окончательное изображение. Предполагается, что шейдер SkyFromSpace применяется к сфере изнутри, поэтому будет видна только та часть атмосферы, которая выходит за пределы планеты, а центр с артефактами будет скрыт за планетой. Тем не менее, как земля, так и затенение неба смотрят на камеру с 500 500 500 ..... хмм

Ответы:


1

У меня сейчас нет рабочего кода, так как я перевожу свой движок, но это были мои настройки рабочих параметров:

// Inited in code
float innerRadius = sphere.Radius;
float outerRadius = innerRadius*1.025f;
float scale = 1.0f/(outerRadius - innerRadius);
float scaleDepth = outerRadius - innerRadius;
float scaleOverScaleDepth = scale/scaleDepth;

Vector4 invWavelength = new Vector4(
    (float) (1.0/Math.Pow(wavelength.X, 4.0)),
    (float) (1.0/Math.Pow(wavelength.Y, 4.0)),
    (float) (1.0/Math.Pow(wavelength.Z, 4.0)),
    1);

float ESun = 15.0f;
float kr = 0.0025f;
float km = 0.0015f;
float g = -0.95f;
float g2 = g * g;
float krESun = kr * ESun;
float kmESun = km * ESun;
float epkr4Pi = epkr4Pi = (float)(kr * 4 * Math.PI)
float epkm4Pi = epkr4Pi = (float)(kr * 4 * Math.PI)

Это был шейдер:

struct AtmosphereVSOut
{
    float4 Position : POSITION;
    float3 t0 : TEXCOORD0;
    float3 c0 : TEXCOORD1; // The Rayleigh color
    float3 c1 : TEXCOORD2; // The Mie color
    float4 LightDirection : TEXCOORD3;
};

// The scale equation calculated by Vernier's Graphical Analysis
float expScale (float fCos)
{
    //float x = 1.0 - fCos;
    float x = 1 - fCos;
    return scaleDepth * exp(-0.00287 + x*(0.459 + x*(3.83 + x*(-6.80 + x*5.25))));

}
// Calculates the Mie phase function
float getMiePhase(float fCos, float fCos2, float g, float g2)
{
    return 1.5 * ((1.0 - g2) / (2.0 + g2)) * (1.0 + fCos2) / pow(1.0 + g2 - 2.0*g*fCos, 1.5);
}

// Calculates the Rayleigh phase function
float getRayleighPhase(float fCos2)
{
    return 0.75 + (1.0 + fCos2);
}

// Returns the near intersection point of a line and a sphere
float getNearIntersection(float3 vPos, float3 vRay, float fDistance2, float fRadius2)
{
    float B = 2.0 * dot(vPos, vRay);
    float C = fDistance2 - fRadius2;
    float fDet = max(0.0, B*B - 4.0 * C);
    return 0.5 * (-B - sqrt(fDet));
}

AtmosphereVSOut
AtmosphereFromSpaceVS(float4 vPos : POSITION )
{
    // Multiply the camera position vector in world space by the 
    // World Inverse matrix so that it gets transformed to
    // object space coordinates
    float4 vEyePosInv = mul(vEyePos, mWorldInverse);

    // Compute a ray from the vertex to the camera position
    float3 vRay = vPos - vEyePosInv.xyz;

    // Transform the Light Position to object space and use
    // the result to get a ray from the position of the light
    // to the vertex. This is our light direction vector
    // which has to be normalized.
    float4 vLightDir = mul(vLightPosition,mWorldInverse) - vPos;
    vLightDir.xyz = normalize(vLightDir.xyz);
    vLightDir.w = 1.0;

    // From the vRay vector we can calculate the 
    // "far" intersection with the sphere
    float fFar = length (vRay);
    vRay /= fFar;

    // But we have to check if this point is obscured by the planet
    float B = 2.0 * dot(vEyePosInv, vRay);
    float C = cameraHeight2 - (innerRadius*innerRadius);
    float fDet = (B*B - 4.0 * C);

    if (fDet >= 0)
    {
        // compute the intersection if so
        fFar = 0.5 * (-B - sqrt(fDet));
    }

    // Compute the near intersection with the outer sphere
    float fNear = getNearIntersection (vEyePosInv, vRay, cameraHeight2, outerRadius2);

    // This is the start position from which to compute how
    // the light is scattered
    float3 vStart = vEyePosInv + vRay * fNear;
    fFar -= fNear;

    float fStartAngle = dot (vRay, vStart) / outerRadius;
    float fStartDepth = exp (scaleOverScaleDepth * (innerRadius - cameraHeight));
    float fStartOffset = fStartDepth * expScale (fStartAngle);
    float fSampleLength = fFar / samples;
    float fScaledLength = fSampleLength * scale;
    float3 vSampleRay = vRay * fSampleLength;
    float3 vSamplePoint = vStart + vSampleRay * 0.5f;

    // Now we have to compute each point in the path of the
    // ray for which scattering occurs. The higher the number
    // of samples the more accurate the result.
    float3 cFrontColor = float3 (0,0,0);
    for (int i = 0; i < samples; i++)
    {
        float fHeight = length (vSamplePoint);
        float fDepth = exp (scaleOverScaleDepth * (innerRadius - fHeight));
        float fLightAngle = dot (vLightDir, vSamplePoint) / fHeight;
        float fCameraAngle = dot(-vRay, vSamplePoint) / fHeight;
        float fScatter = (fStartOffset + fDepth * (expScale (fLightAngle) - expScale (fCameraAngle)));

        float3 cAttenuate = exp (-fScatter * (vInvWavelength.xyz * kr4PI + km4PI));

        cFrontColor += cAttenuate * (fDepth * fScaledLength);
        vSamplePoint += vSampleRay;
    }

    // Compute output values
    AtmosphereVSOut Out;

    // Compute a ray from the camera position to the vertex
    Out.t0 = vEyePos.xyz - vPos.xyz;

    // Compute the position in clip space
    Out.Position = mul(vPos, mWorldViewProj);

    // Compute final Rayleigh and Mie colors
    Out.c0.xyz = cFrontColor * (vInvWavelength.xyz * krESun);
    Out.c1.xyz = cFrontColor * kmESun;

    // Pass the light direction vector along to the pixel shader
    Out.LightDirection = vLightDir;

    return Out;
}

PSOut
AtmosphereFromSpacePS(AtmosphereVSOut In)
{
    PSOut Out;

    float cos = saturate(dot (In.LightDirection, In.t0) / length (In.t0));
    float cos2 = cos*cos;

    float fMiePhase = getMiePhase(cos,cos2,g,g2);
    float fRayleighPhase = getRayleighPhase(cos2);

    float exposure = 2.0;
    Out.color.rgb = 1.0 - exp(-exposure * (fRayleighPhase * In.c0 + fMiePhase * In.c1));
    Out.color.a = Out.color.b;

    return Out;
    }

Дайте мне знать, если это все еще работает. Если вам понадобится какая-либо другая помощь, я постараюсь покопаться в своем коде. Я думаю, что использовал две сферы для рендеринга: одну для поверхности и одну для атмосферы.


0

некоторые следы мыслей: проверьте точность ваших поплавков. в космических масштабах почти все время float32 недостаточно. Проверьте буфер dpeth, если у вас есть примитивный рендеринг, например, сфера под вашим рассеивающим шейдером.

Эти артефакты также можно найти в трассировке лучей, обычно это пересечение вторичных лучей с дрожанием первичной поверхности из-за проблем точности поплавка.

РЕДАКТИРОВАТЬ: при 1000 (все целые числа представимы полностью до 16 миллионов в представлении float32, благодаря 24-битной мантиссе), следующее число для float32 - 1000.00006103, так что ваша точность все еще довольно хороша в этом диапазоне.

однако, если вы будете использовать диапазоны метров, чтобы увидеть планету a, это расстояние будет означать значения 100 000 000, а следующее - 10000 0008: 8 метров точности на 100 000 км.

это может вызвать скачки камеры, если вы попытаетесь, например, передвигаться вокруг спутника, а рендеринг самого спутника будет нарушен, если ноль вашего мира будет центром планеты. если это центр звездной системы, то это еще хуже.

ищите flavien brebion (Ysaneya) и игровой бесконечный квест на землю. У него есть интересный девелоперский журнал gamedev и его форум, где он объясняет, как с помощью абсолютов невозможно управлять расстояниями звездной системы.

Он также упоминает проблему буфера глубины в таких диапазонах и является одним из первых, если не первым, кто ввел логарифмические z-шкалы. http://www.gamedev.net/blog/73/entry-2006307-tip-of-the-day-logarithmic-zbuffer-artifacts-fix/ гораздо более полный здесь: http://outerra.blogspot.jp/ 2012/11 / максимизация глубина-буфер-диапазон and.html

Тестовый стенд для программного обеспечения: хорошая идея, это отличный способ создания шейдеров, чтобы вы могли шаг за шагом отлаживать происходящее. просто проверяйте ваши значения построчно, и если что-то выглядит странно, вы можете исследовать это. Я не видел в коде, который вы разместили, где используется угол камеры в шейдере, поэтому я немного озадачен этой частью.


Не могли бы вы уточнить, что вы подразумеваете под точностью поплавка? Масштабы, используемые в этом примере, находятся в диапазоне от -1000 до 1000. В данный момент пример является чисто программной реализацией, в которой результат шейдера отображается на изображении, а затем отображается с использованием API c # System.Drawing, который означает, что в примере не используются примитивы.
ollipekka
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.