Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Равномерное распределение глубины в z буфере. (комментарии)

Равномерное распределение глубины в z буфере. (комментарии)

Страницы: 1 2 3 Следующая »
GeniusIsmeПостоялецwww11 ноя. 200916:30#0
Равномерное распределение глубины в z буфере. (комментарии)

Это сообщение сгенерировано автоматически.

raxxlaПостоялецwww11 ноя. 200916:30#1
В начале объявлено

matrix ViewProjection;

потом в вершинном шейдере идет

float4 vec =mul(inPos,WorldView);

опечатка?

GeniusIsmeПостоялецwww11 ноя. 200921:33#2
Исправляю. WorldView, конечно.
namotУдалёнwww11 ноя. 200921:37#3
Разве это не приведет к некорректному текстурированию?
GeniusIsmeПостоялецwww11 ноя. 200921:40#4
С чего бы?
На расчет текстурных координат методика никак не влияет.
ExecutorУдалёнwww11 ноя. 200921:42#5
Спасибо за инфу, полезно...
ZПостоялецwww11 ноя. 200921:47#6
Там про один минус не написано - вблизи будет сильнъй z-fighting, т.к. точность вблизи будет ниже чем у нелинейного буфера. И не только z-fighting, будет и альясинг глубинъ совсем близко, если zfar далеко.
namotУдалёнwww11 ноя. 200922:10#7
GeniusIsme
>С чего бы?
Так значения Z влияют на расчет UV.
NULL_PTRПостоялецwww11 ноя. 200922:31#8
>float ScreemHeight;
ScreenHeight

>Потенциально код из предложенного шейдера может работать быстрее, чем еще одно перемножение матриц.
Зачем ещё одно, если можно сделать сразу modelviewprojection.
Да и если два подряд, будет approximately 8 instruction slots used, а с данным шейдером - approximately 18 instruction slots used при компиляции в vs_2_0.
на R600 и выше по тактам выходит одинакого, но на более старых картах может быть хуже. (С одной матрицей - всегда хуже).

>В шейдер нужно пересылать немного меньше данных (на 12 float меньше каждый DIP)
Опять же, при условии передачи modelviewprojection, только проигрываем четыре.

xПостоялецwww11 ноя. 200922:32#9
мдэ.

C++

D3DXMATRIX mProj;
D3DXMatrixPerspectiveFovLH(&mProj,fFov,fNear,fFar);
mProj._33/=fFar;
mProj._43/=fFar;
...

HLSL:

float4 vPos = mul(Input.Pos,worldViewProj);
vPos.z = vPos.z * vPos.w;
Output.Pos = vPos;

from http://www.mvps.org/directx/articles/linear_z/linearz.htm

GeniusIsmeПостоялецwww11 ноя. 200922:35#10
2 namot
Каким же образом?

Вершинный шейдер назначает вершине то UV, которое этой вершине назначено. В общем случае он его не рассчитывает.
Для каждого пикселя значения UV получаются интерполированием значений UV от проекций вершин треугольника. При этом учитываются экранные X и Y вершин, но не Z

2 Z
Ник в тему)

Внесу коррективу. Но я бы не сказал, что в обычных условиях вблизи будет сильный z-fighting. По крайней мере, у себя я не заметил. Но если zfar действительно далеко, то да, уменьшение точности вблизи может стать неприятным.

namotУдалёнwww12 ноя. 20090:27#11
GeniusIsme
>Для каждого пикселя значения UV получаются интерполированием
> значений UV от проекций вершин треугольника. При этом учитываются
> экранные X и Y вершин, но не Z
Без Z получиться аффинное текстурирование, это выглядит не естественно для треугольников с большими градиентами Z. Такое было только в софтовых растеризаторах. Можно проверить, простой способ, в шейдере присвоить Z одно и тоже значение всем вершинам, и редерить какой нибудь кубик с куллингом (чтоб не иметь проблем с порядком отрисовки).

Интересно было бы посмотреть на это в действии, сравнить результаты.

SNVampyreУдалёнwww12 ноя. 20094:28#12
Можно ли посмотреть трилинейку и анизотропку с/без ?
ZПостоялецwww12 ноя. 200911:17#13
GeniusIsme
> Но я бы не сказал, что в обычных условиях вблизи будет сильный z-fighting.
Гм, а если так - стандартное распределение вообще-то не случайно придумали. Зачем? Отсюда уже можно отталкиватся и думать. Т.е. я действительнъх причин нелинейного распределения не увидел, одни минуса - а ето странно, люди могут подумать что твой вариант лучше во всех отношениях, что разумеется не верно.
Можно посмотреть и с другой сторонъ: преспективность - она везде в компютерной графике, очень много методов рендеринга используют сей факт - примерно геометрию хорошо делать с нелинейной плотностью, а не наборот. Резолюшн теней - тоже.
andrianoПостоялецwww12 ноя. 200912:02#14
В статье не указан "самый главный" минус (являющийся следствием "самого главного" плюса).
А именно: если у существующего механизма артефакты проявляются лишь у самых дальних (а потому мелких на экране) моделей, то у предложенного - они равномерно распределяются по всем моделям вне зависимости от удаленности, т.е. существенно увеличивается вероятность возникновения артефактов у близрасположенных, а потому крупно изображаемых объектов.

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

Страницы: 1 2 3 Следующая »

/ Форум / Программирование игр / Графика

Тема в архиве.

2001—2018 © GameDev.ru — Разработка игр