Народ, при всей моей безграничной
Народ, при всей моей безграничной умственной мощи в ней есть как минимум одна большая прореха в области шейдеров. Я сейчас работаю над допиливанием демки проекта DeadStar и хочу поюзать шум для обозначения пограничных к «туману войны» зон. В целом у меня получилось, но пока что я использую преренедрённый шум сделанный фотошопом из нескольких кадров спрайта. Выглядит очень дёргано и раздражающе. Я хочу использовать шейдер для генерации текстуры шума. Но всё не так просто, мне нужно два шейдера:
1) Шейдер, который будет рисовать мне текстуру облаков аля фотошоп. Как я понял — это Perlin Noise. Но мне нужна управляемая генерация, чтобы я мог рулить параметрами и плавно менять очертания этих облаков с течением времени. Как я понял, там псевдогенерация, так что если скармливать один и тот же seed, но менять параметры то я получу те же самые облака, но немного другие так ведь?
2) Шейдер статического шума который будет имитировать помехи. По моей задумке он должен накладываться на сгенерированную выше текстуру.
Инфа которую я нарыл в инете по данному вопросу требует довольно много опытов и глубокого погружения, чтобы разобраться чё к чему.
В общем, если у кого есть под рукой подобные шейдеры — буду рад если поделитесь. Или может у кого есть под рукой инфа, как такой шейдер можно просто состряпать не особо погружаясь в запредельную математику языка шейдеров.
- 25 июня 2019, 09:36
- 03
101 при написании шейдеров - если что-то можно записать в память без сложных просчетов, это нужно делать. Все текстуры шумов и облаков (которые не являются шумом Перлина, гугли Diamond-square algorithm) записаны в битмап для ускорения работы шейдера. Текстура, сгенерированная в шейдере ничем не будет отличаться от записанной текстуры, кроме, конечно, повышенной требовательности к железу.
Это как? Анимация шума записана в кадры спрайта что-ли? Неудивительно что будет дергано, анимация шума в шейдерах делается случайным изменением оффсета текстуры шума.
Генерация высококачественных Clouds это не самый быстрый процесс в игровых приложениях, обычно очертания их меняются следующим образом - высчитываются определенные цвета пикселей, которые не будут отрисовываться в текстуре облака, либо к ним смешивается другая текстура, которая тоже со случайным оффсетом двигается, что создает иллюзию того, что очертания облака плавно меняются.
То есть вместо генерации каждый раз новой текстуры облак или шума, шейдер каждый кадр применяет различные действия к уже готовым текстурам.
Если текстура не очень большая, то может отличаться явно прослеживаемым паттерном. Те примеры шейдеров с генерацией шума что я видел - частично этим страдают.
Я часто так и делал раньше и мне этого казалось достаточно для тех нужд. Сейчас я вижу что мне нужен совершенно новый алгоритм и мои старые методы не канают.
Ну мне высокое качество не очень нужно на самом деле. Там же от размера текстуры многое зависит ещё? У меня текстура будет, допустим 512*512 это ведь не очень много? Или много для шейдера?
Я уже посмотрел пару примеров шейдеров.
Вот это походу то о чём ты говорил - делаем из готовой текстуры что нужно: https://www.shadertoy.com/view/ldlXRS
Вариации обычных шумов:
https://www.shadertoy.com/view/4ssXRX
https://www.shadertoy.com/view/4djSRW
А это походу та самая генерация что мне нужна:
https://www.shadertoy.com/view/XsX3zB
Теперь только понять бы как это адаптировать в шейдеры Game Mаker Studio 2
P.S. Покурил мануалы и запредельная математика теперь выглядит не такой уж и запредельной XD Может к выходным и доделаю что задумал.
Про perlin noise - там есть параметр типа времени, при небольшом его изменении как раз и получается плавное изменение.
Может быть видел, но может быть и нет - https://thebookofshaders.com/11/
(там можно жать на картинки, дабы код узреть)
и тут в конце https://thebookofshaders.com/13/
статический шум можно попробовать имитировать взятием дробной части от какой-то функции, зависящей от времени. Или я не понял вопрос!
Хочу предупредить по использованию готового кода из советов в интернете.
По моему опыту в 50% случаев в коде есть ошибки (не то что логические, а даже синтаксические), а в других 50% его приходится переделывать или вносить правки, потому что он делает не совсем то. В любом случае тебе придется в нем разобраться.
Гораздо надежнее и быстрее разобраться в проблеме и написать код самому (пусть и подглядывая в чужой код или беря из него куски). Нельзя брать чужой код целиком на веру - в большинстве случаев его пишут прямо в комментарии и по памяти, не тестируя и даже не компилируя.
Да это понятно, я же по CSS и JS частям на фултайме работаю, так что знаю каково это.
Так что привык уже чужое допиливать. Даже на конкурс после того как прикрутил ситему динамического освещения потом дописывал код для оптимизации.
При малых объемах кода только работает.
Я же пишу "из советов в интернете".
Разумеется там малые объемы кода. Когда пишут много, то обычно проверяют то что пишут.
Тоже проблема с шейдерами, очень сложно понимать логику, как их нормально писать, приходится вырывать куски из разных мест склеивая как попало в одно. И то часто такая сборка не работает, а ошибки не понимаю,
в обычном программировании намного проще, чем в шейдерном для меня.
Там основная залупа в том, что функция отработки шейдера знает только цвет пикселя и его координаты. Ну ещё немного входной инфы-параметров. Приходится юзать линейную алгебру чтобы делать какие-то преобразования. Шарики за ролики заезжают - это да.
Там одна сплошная математика.
Попробовал прикрутить вот это:
https://www.shadertoy.com/view/XsX3zB
Хуй, просто серый экран.
И вот это:
https://www.shadertoy.com/view/4ssXRX
Ну там ваще ахтунг. Да, генерация есть, но она какими-то явными паттернами о чём я писал выше. Нужно на основе какой-то текстуры это делать.
Буду вечером ещё курить эту тему. Хотя с тем как шейдеры работают, какие параметры принимают и что возвращают я в целом разобрался. Математическая алгоритмика не для меня. И пока непонятно почему шейдеры на одном и том же стандарте GLSL ES в примере из веба работают одним образом, а прикрученные в гамак - совершенно по-другому.
На сколько я знаю, но могу сильно ошибаться, примеры в вебе построены на gles2 (как и игры на андроид). Гамак явно использует gles3. А второй и третий gles совсем не совместимы и работают по разному.
З. Ы. Если кто знает этому опроверждение, дайте знать
Третьи сутки пытаюсь вкурить какого хуя не работает.
Стандарт же GLSL SE он же везде должен одинаково работать? Или у GMS2 какая-то своя охуительная реализация? Нахуй тогда нужен такой стандарт если его все реализуют по-разному?
По моему опыту стандарт-стандартом, а язык Си разными компиляторами поддерживается по-разному.
Нужно разбираться в каждом конкретном случае. Это так, к слову. В юнити, Love2D - у каждого свои примочки для языка шейдеров, а тебе нужно читать что авторы GMS2 наворотили.
Если бы не было стандартов, то вообще была бы жопа. Каждый бы делал свой велосипед как ему больше хочется. А так на 90% все у всех одинаково, но в мелочах все равно отличаются.
Оказалось что я сам дурак. Спросил на форуме и мне тут же сообщили что я координаты неправильно считаю.
Проверил - заработало. Я то думал что pass throught для vector shader кусочка - это типа оставить всё как есть. Оказалось что там много чего интересного можно поменять.
Теперь всё тормозит ажпиздец. Правильно чувак выше говорил что генерация шума в шейдерах = bad smell. Нужно искать другие пути. Микс текстур, получается что ли.
шейдер нужно умудриться сделать узким тормозящим местом, вон тут я делал три шейдера в итоге на обработку и шум и не шум, например:

скорее всего где-то потом уже провисает, хотя я, конечно, не знаю, как в гамаке всё у вас устроено
Вот у меня тоже есть подозрение что дело не в шейдере.
Вчера весь вечер оптимизировал генерацию прелинового шума. Сделал в итоге через пререндерённую текстуру. И понял что тормозил не он! Тормозит bloom. Притом что шейдер вроде как там совсем простой - там только точки с текстуры 10 раз забираются. Не думаю что это такая уж долгая операция. Скорее всего я его как-то криво прикрутил к объекту пост-процессинга. Буду разбираться вечером.
В общем, вот что-то такое я сумел родить за неделю пыхтения над шейдерами:
Тормозило потому что я сам себе злобный буратино. Неправильно использовал сурфейсы. Хотел сделать пост-обработку всего кроме UI и для этого включил ещё один вид который рендерил в отдельный сурфейс. То ли оно слишком медленно этот вид обрабатывало, то ли я криво написал менеджер сурфейсов. Покурил мануал. Понял что application_surface рисуется отдельно от GUI слоя, и перенс весь UI в GUI, а для блума поюзал как раз application_surface без выебонов с менеджментов видов.
Очень красиво вышло.
А почему зелёный? Цвет будет меняться в зависимости от здоровья персонажа? Было бы интересно посмотреть, как будет выглядеть этот же шум, меняющий цвет.
Ещё, кстати, интересно, что получится, если эта штука будет чёрной, как и фон - будет ли это выглядеть как будто темнота живая и тянется к персонажу?
А, ок, прочитал в другом треде, что это основная цветовая гамма.
Мне кажется, если это - неинформативная декорация, то она уж слишком отвлекает внимание. И ощущается более клаустрафобично, чем в конкурсной версии. Но это субъективно, конечно. К тому же я только по видео могу судить, наверняка в игре глаз быстро привыкает.
Вообще это будет информативная декорация типа сканера. Т.е. в этой области я планирую показывать дополнительную информацию про окружение. Пока ещё не решил, как, но думаю что это будет.
Зелёная потому что будет менять цвет в зависимости от здоровья персонажа, да
Да, это вглядит именно так и я планирую использовать этот эффект, когда игрок попадёт к рефлекторным существам.