Войти
ПрограммированиеФорумГрафика

Как "сейчас" работают mipmaping и anisotropic?

#0
15:00, 11 авг 2015

"Раньше" это было понятно - есть треугольник, через него ровно интерполируют текстурные координаты и можно вычислить параметры отображения - min или mag.
Тоже самое с анизатропной фильтрацией - есть весь треугольник, считай чего хочешь.

Но теперь, когда я могу читать из текстурам по любым координатам, и делать с этими данными чего угодно - вот теперь мне работа min/mag фильтров не понятна.
Все хочу читать из текстуры по совершенно произвольным фунциям для достижения различных эффектов, но смущает скрытая кухня - мипмапинг нужен, но как он сработает - не ясно.
Так как он работает в эпоху шейдеров?

#1
15:20, 11 авг 2015

Так же как и до шейдеров.

#2
15:36, 11 авг 2015

Kashey
> вот теперь мне работа min/mag фильтров не понятна.

Градиенты работают по интерполяторам, а min/mag по градиентам. Другое дело что смысл выборок с градиентами может быть особым

#3
15:39, 11 авг 2015

У меня есть пиксель, который надо рестеризовать.
Я беру координаты этого пикселя, вешаю на них sin/cos, делаю texture2D по новым значениям и так далее.
Два соседних пикселя могут долбить в совершенно разные куски текстуры.
Как в таких условиях, зависимых текстурных выборок, работает min/mag?

#4
15:46, 11 авг 2015

Kashey
> Как в таких условиях, зависимых текстурных выборок, работает min/mag?

Есть подозрение, что будут браться из level0

#5
16:10, 11 авг 2015

innuendo
Судя по http://www.gamedev.ru/code/forum/?id=188948&page=2#m15 - так и есть. Хотя подтверждения этого в "нормальной документации" я не обнаружил.
Возможно это к лучшему - желаемый bias я всегда и сам могу вычислить. И никакая магия мешать не будет.
Осталось как-то найти четкое определение зависимых и независимых выборок.

#6
16:25, 11 авг 2015

Kashey

Есть выборка с градиентами, когда uv не зависит от ddx/ddy

#7
17:03, 11 авг 2015

На всякий случай: вот это релевантно?

Also, this is a good point to explain why we’re dealing with quads of 2×2 pixels and not individual pixels. The big reason is derivatives. Texture samplers depend on screen-space derivatives of texture coordinates to do their mip-map selection and filtering (as we saw back in part 4); and, as of shader model 3.0 and later, the same machinery is directly available to pixel shaders in the form of derivative instructions. In a quad, each pixel has both a horizontal and vertical neighbor within the same quad; this can be used to estimate the derivatives of parameters in the x and y directions using finite differencing (it boils down to a few subtractions). This gives you a very cheap way to get derivatives at the cost of always having to shade groups of 2×2 pixels at once.

https://www.opengl.org/discussion_boards/archive/index.php/t-154539.html про древний NV_texture_shader extension :

How is the mipmap lambda parameter computed for dependent texture fetches?

RESOLUTION: Very carefully. NVIDIA's implementation details are
NVIDIA proprietary, but mipmapping of dependent texture fetches
is supported.


From the NV_texture_shader extension.

( http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_shader.txt )

#8
17:30, 11 авг 2015

Судя по описанию там запускается одновременный проход некого блока 2х2, и на основании одновременных выборок для 4х пикселей можно восстановить и mip и другие параметры.
Звучит обнадеживающе.

#9
17:55, 11 авг 2015

Kashey
> Судя по описанию там запускается одновременный проход некого блока 2х2, и на
> основании одновременных выборок для 4х пикселей можно восстановить и mip и
> другие параметры.
> Звучит обнадеживающе.

Только для блока  из 4 пикселей эти параметры будут идентичны, В итоге все разбивается на квадратики 2x2 если  ddx/ddy влияют на результат так что заметно.
По этой причины плохо когда очень маленькие треугольники, если даже виден только 1пиксель из блока, то расчеты идут для всех, чтобы можно было получить  ddx/ddy.

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

#10
9:13, 12 авг 2015

susageP
> В итоге все разбивается на квадратики 2x2 если ddx/ddy влияют на результат так
> что заметно.

sm5.0 даёт возможность считать ddx точно и не очень

#11
15:30, 12 авг 2015

innuendo
> sm5.0 даёт возможность считать ddx точно и не очень
поподробней можно?

#12
15:33, 12 авг 2015

susageP
> поподробней можно?

ddx_fine
ddx_coarse

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

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