Направленное освещение для каждого лица с использованием шейдера геометрии?

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

Нормали, рассчитываемые в шейдере геометрии, находятся в пространстве экрана, но они верны в некоторых тестах, которые я провел.

Я могу указать направление света в мировом пространстве или умножить на вид/проекцию/транспонированную/инвертированную матрицу.

Следующий код отчасти работает, но меняется в зависимости от угла камеры/направления света:

void FlipFaceGS(triangle PS_IN input[3], inout TriangleStream<PS_IN> OutputStream)
{
    PS_IN v1 = input[0];
    PS_IN v2 = input[1];
    PS_IN v3 = input[2];

    float3 faceEdgeA = v2.pos - v1.pos;
    float3 faceEdgeB = v3.pos - v1.pos;
    float3 faceNormal = normalize(cross(faceEdgeA, faceEdgeB));

    v1.norm = faceNormal;
    v2.norm = faceNormal;
    v3.norm = faceNormal;

    float4 newColor = (v1.color * Light1Color * max(0, dot(v1.norm, Light1Direction)));
    newColor.a = v1.color.a;//we don't want to affect the alpha levels

    v1.color = newColor;
    v2.color = newColor;
    v3.color = newColor;

    OutputStream.Append(v1);
    OutputStream.Append(v2);
    OutputStream.Append(v3);
    OutputStream.RestartStrip();
}

В приведенном выше примере направление освещения умножается на матрицу ViewProjection камеры и нормализуется перед отправкой на графический процессор.

Какая математика необходима для правильного расчета света в геометрическом шейдере?


normals directx hlsl geometry-shader
person ManIkWeet    schedule 08.03.2015    source источник
comment
Это не делает повершинное освещение. Это освещение для каждого лица с репликацией вершин. Это, вероятно, будет медленным, поскольку вы выполняете репликацию вершин в GS, хотя вы, по крайней мере, производите то же количество выходных данных, что и принимаете входные данные, что означает, что вы не пострадаете от производительности GS в худшем случае.   -  person Chuck Walbourn    schedule 09.03.2015
comment
@ChuckWalbourn Я исправил заголовок, если вы знаете какие-либо варианты освещения, не зависящие от порядка вершин, я хотел бы их услышать :)   -  person ManIkWeet    schedule 11.03.2015

Ответы (1)


arrow_upward
0
arrow_downward

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

person Nico Schertler    schedule 13.03.2015
comment
Тем не менее, клип-пространство не подходит для расчетов освещения. Мне это удалось, спасибо! - person ManIkWeet; 18.03.2015