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

Красивое процедурное небо (4 стр)

Страницы: 1 2 3 4 5 Следующая »
#45
(Правка: 16:11) 16:07, 4 июля 2021

san
> На современных картах это быстрее чем frac(sin()).
Это не везде правильно работает, вот в чем основная проблема. На некоторых видеокартах просто полосы получаются. Но если брать широкий спектр видеокарт, то даже если на более мощных видюшках вычислительный шум медленнее чем обращение к текстуре, то это не так сильно проседает по производительности, как на слабых обращение к текстурам.

MikeNew
> замеряно на gtx1080, думаю на других картах будет примерно так же
И все же лучше делать через текстурный кеш. Генерить пару текстур с уже склеенными несколькими слоями шума и разной скоростью и масштабами анимации, и в конце их между собой смешивать.


#46
17:32, 4 июля 2021

foxes
> Это не везде правильно работает, вот в чем основная проблема. На некоторых видеокартах просто полосы получаются.
Не мог ли ты дать примеры карт где чтение из текстуры вызывает полосы? Я не очень понимаю как это возможно.

С разными алгоритмами генерации шума я работаю давно, лет 15. На картах поколения GTX 660 чтение текстур было очень медленной операцией и алгоритмический шум работал существенно быстрее. В этом случае "шум" генерируемый на AMD и Nvidia отличался, но это можно было заметить только сравнивая попиксельно - общий характер шума был одинаков. Я заметил это только при мультиадаптерном рендере, когда часть картинки считается на одной карте, а другая часть на второй и они разных вендоров. Тогда становится видна граница раздела. С текстурой этого эффекта не было - там части картинки стыковались идеально.
В любом случае начиная с 1080 чтение текстуры стало работать быстрее чем тригонометрия и я вообще отказался от процедурного шума.

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

#47
(Правка: 17:40) 17:36, 4 июля 2021

san
> Не мог ли ты дать примеры карт где чтение из текстуры вызывает полосы?
Я про frac(sin()), а не про текстуры.
san
> Я это делаю разными каналами одной текстуры. 4 канала с шумом разного типа
> обычно вполне достаточно.
Если ты 4 раза считываешь каналы под разным масштабом, то это не очень эффективно, тоже самое что и 4 разных текстуры. В общем помимо двух текстур для разного масштаба можно и 4 канала с разной формой облаков для разнообразия использовать, интерполируя между ними.

#48
17:40, 4 июля 2021

foxes
А... Но тогда тот же вопрос. Я использовал этот алгоритм (frac/sin) на разных картах разных вендоров, от AMD и Nvidia до микрософтовских эмуляторов и никогда не видел вырождение шума в полосы. Шум, как я сказал, отличался, но это всегда был шум.

#49
(Правка: 18:02) 17:43, 4 июля 2021

san
> но это всегда был шум.
https://gamedev.ru/projects/forum/?id=229698&page=3&m=4586151#m32
Очень часто такое бывает на ноутбуках и офисных компах на ресепшене.
Ну и у некоторых особо одаренных
Какая там у них видеокарта не в курсе, но чаще AMD и INTEL. Последние 5 лет я такое начал замечать.

#50
(Правка: 18:10) 18:03, 4 июля 2021

foxes
Тут вроде речь идет о перлин-нойсе. В любом случае я не верю в "православный синус". Тригонометрия от вендора на зависит, у них может быть (и бывает) разная точность но не более того. Вот программеры бывают криворукие, это факт.

>Если ты 4 раза считываешь каналы под разным масштабом, то это не очень эффективно, тоже самое что и 4 разных текстуры.
Тут экономия не скорости а просто меньше текстур передавать. Все равно у тебя 4 канала, логично их использовать. Хоть место сэкономишь.

#51
(Правка: 18:16) 18:07, 4 июля 2021

san
> Тут вроде речь идет о перлин-нойсе.
Там везде перлин аналога MikeNew. И эти же примерчики запускал на ноутбуках - результат линии.

К примеру код, с uv= vec2(100,100) и более, уже дает линии.

float noise(vec2 uv)
{
    return fract(sin(uv.x * 113. + uv.y * 412.) * 6339.);
}

Вот тут эту проблему раскрыли для всех видеокарт. Но на тестируемых с линиями, результат на лицо с первого кадра, для остальных просто паттерн появляется.

#52
18:14, 4 июля 2021

foxes
Тут ты просто за разрядность float вылазишь. Вот тебе и линии. К алгоритму это отношения не имеет.

#53
(Правка: 18:20) 18:17, 4 июля 2021

san
> Тут ты просто за разрядность float вылазишь.
Возможно для этих карт как раз разрядность для float не больше 16. Но даже если в ручную указать разрядность типов для glsl такой проблемы с линиями все равно нет, максимум паттерны.

#54
18:31, 4 июля 2021

foxes
100*412*6339=261.166.800. Приращение (по координате) для текстуры 1024х1024 у тебя получается 1/1024. На фоне 260 миллионов общего масштаба. Хочешь что-бы корректно считалось - разбивай на шаги или хоть скобки ставь. Иначе 32 бит не хватит для нормального отображения. Дело не в карте а в оптимизаторе, а точнее криворукости программиста эти нюансы не учитывающего.

#55
(Правка: 19:00) 18:33, 4 июля 2021

san
> Дело не в карте а в оптимизаторе
Результаты то все равно разные.
san
> Иначе 32 бит не хватит
Считай 24 бита мантиса.
А там еще и "vec2 pos = (position + iTime * 1500. + 50.0);" для

fract(sin(dot(p, vec2(12.9898, 78.233))) * 43758.5453);

san
> 100*412*6339=261.166.800.
На самом деле для плавающей точки это не имеет значение. Конечно часть младших бит отсечется в результирующем значении, но как раз благодаря этому большому числу 6339 или 43758.5453 они также смещаются и со старшими. Так что тут вопрос скорее всего в разнице порядков между 113. и 412. Потому что точно теряется как раз при сложении, а не при умножении.

#56
18:57, 4 июля 2021

foxes
Результаты разные поскольку оптимизаторы шейдера по разному работают. Но в любом случае нужно учитывать что карта, в отличие от CPU, считает с точностью 32 бита а не 64. 32х бит достаточно, просто не нужно смешивать очень большие числа и очень маленькие. Иначе получится картинка как по твоей ссылке - типичное поведение при приближении к границе разрядности. Лечится то просто - не надейся на оптимизатор а сделай все шаги вручную. Тогда все будет работать аналогично на любом железе.

#57
(Правка: 19:01) 19:00, 4 июля 2021

float16 максимум 7*10^4 - вот тут 261.166.800 уже перебор
float32 максимум 3*10^38 - а тут еще 30 нолей можно дописать.

san
> Тогда все будет работать аналогично на любом железе.
Если там float16 то нет.

#58
19:07, 4 июля 2021

foxes
Дело не в общей разрядности, а в смешивании чисел float с разными порядками. Если бы ты считал в интах таких эффектов бы не было.

> Если там float16 то нет.
Я не слышал о картах по умолчанию работающих с половинной точностью. Думаю этот случай маловероятен.

#59
(Правка: 19:32) 19:23, 4 июля 2021

san
> Я не слышал о картах по умолчанию работающих с половинной точностью.
Вдруг они входной параметр для синуса урезали.
san
> Если бы ты считал в интах таких эффектов бы не было.
А какая разница, буду ли я брать старшие биты (float), или остаток (int). Если при умножении эти самые порядки не имеют значения.
san
> а в смешивании чисел float с разными порядками.
Ну так на разных картах они одинаковые, а результат различается. Тут даже для инта, какой нибудь (X*400000..00000+y)  - тоже вылетит за разрядность. Но в данном случае, кроме как разница в ограничении максимальной разрядности отдельной функции, ничего не подходит.

Если бы это были две разные формулы тогда вопроса бы не было.

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумГрафика