Артефакты интерполяции у узких треугольников на радеонах (или нет) (2 стр)

ncuxonaT
А если сузить near/far plane лучше становится?

Выглядит вообще странно, каким кодом восстанавливаются координаты?

samrrr
> А если сузить near/far plane лучше становится?
Если отодвигать near, то немного лучше. Если приближать far, то примерно то же самое.
samrrr
> каким кодом восстанавливаются координаты?
вполне вероятно, что неправильным

vec4 ndc = vec4(gl_FragCoord.xyz / vec3(screen_size, 1.0) * 2.0 - vec3(1.0) , 1.0); 
ndc = inverse_mvp * ndc;
vec3 fixed_pos = ndc.xyz / ndc.w;

>gl_FragCoord.xyz / vec3(screen_size, 1.0) * 2.0 - vec3(1.0)
можно +0.5 пикселя сделать, может лучше будет.

ещё есть такая вещь как inverse depth
при нём матрица становится лучше.

>inverse_mvp
На cpu же эти матрицы в double считаются?

samrrr
> можно +0.5 пикселя сделать, может лучше будет.
> ещё есть такая вещь как inverse depth
> при нём матрица становится лучше.
Увы, ни то ни другое не помогает (матрицу с обратной глубиной брал отсюда https://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html).
samrrr
> На cpu же эти матрицы в double считаются?
Хм, вообще я обратную матрицу считал в вершинном шейдере как inverse_mvp = inverse(gl_ModelViewProjectionMatrix);
Думаете, есть смысл проверить на даблах?
upd. Попробовал в шейдере считать через dmat4, всё то же самое

ncuxonaT
> Увы, ни то ни другое не помогает (матрицу с обратной глубиной брал отсюда
Одной матрицы мало будет

АкронимЛета
сколько матриц будет достаточно?

ncuxonaT
> сколько матриц будет достаточно?
Ты диапазон отсечения глубины менял при inverse depth?

АкронимЛета
если имеется в виду glDepthRangedNV(-1.0,1.0), то да, менял

>glDepthRangedNV(-1.0,1.0)
это не inverse, а хрень какая-то получается

>upd. Попробовал в шейдере считать через dmat4, всё то же самое
уже поздно, при рассчёте матрицы надо double а не только при инверсии

ncuxonaT
ты пытаешься пофиксить то что невозможно пофиксить

Danilw
> треугольник/квад не должен быть больше экрана, когда он больше и будут потери -
> это обычная практика
>
> очевидно в OpenGL размер шага в пиксельном шейдере не должен быть ниже 1/4096

я тебе сказал причину
у тебя UV растягивается что шейдер получает значения UV с потерями точности

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

>ты пытаешься пофиксить то что невозможно пофиксить
это возможно пофиксить

Не уверен, что догнал в описание проблемы, опенгл не мое. Но на всякий случай, если "нужно во фрагментном шейдере знать мировые координаты фрагмента", то может перед всеми вычислениями из позиции вертекса убрать позицию камеры, а потом в пиксельном шейдере добавить? (из трансформаций матриц лучше тоже)

BorisV
Не поможет. Всё, что передается из вершинного шейдера во фрагментный, криво интерполируется. Никак же нельзя повлиять на интерполяцию?

samrrr
Попробовал считать матрицу на даблах, эффект незначительный. Сделал нормальную reversed depth с использованием glClipControl(GL_LOWER_LEFT, GL_ZERO_TO_ONE), стало намного лучше, но всё равно есть разница с нормальными интерполированными значениями. Сомневаюсь, что можно добиться лучшего результата таким подходом с умножением gl_FragCoord на обратную матрицу.

ncuxonaT
> Никак же нельзя повлиять на интерполяцию?
А как ты хочешь на неё повлиять?