Так как вы попросили опыт, вот мой.
В те времена, когда я программировал игры для PS2, подход «многослойных альфа-квадратов» был способом, которым мы часто применяли туман. Иногда как наземный туман, но гораздо чаще, чем полноэкранный туман. И это работало просто отлично в любом случае. Так что да, это было жизнеспособно в дни, предшествующие фрагментам-шейдерам.
Ну вроде. Проблема, как вы заметили, заключалась в том, что если вы хотите получить плавный туман, подобный тому, который показан на скриншоте, вам нужно довольно абсурдное количество альфа-квадраторов.
На PS2 мы обычно могли позволить себе где-то между тремя и пятью слоями. Который определенно выглядел как "стены" тумана, плавающего перед вами. Более того, скорость заполнения стала убивать нашу частоту кадров.
Обычно эти четырехугольники рисуются на фиксированных расстояниях перед камерой, поэтому вы никогда не сталкивались с ситуацией, о которой говорите, «проходя» одну из них. С другой стороны, используя эти фиксированные расстояния, все остальное в мире делаетпроходите сквозь эти плоскости, пока игрок движется, что является довольно очевидным графическим затруднением. Почти все делали это тогда, но сейчас это было бы неприемлемо (если вы не делали это по стилистическим соображениям). (Исключение: некоторые люди рассчитывали значения тумана как часть эквивалента вершинного шейдера PS2. Это работало и было намного быстрее, но требовало высокой степени тесселяции ваших моделей. Например, вы не могли иметь длинные стены, потому что туман был только вычисляется по углам стены, а затем размазывается по всему лицу стены. Стена выглядела полностью запотевшей, например, если вы стояли прямо рядом с ее серединой, поскольку она проверяла только уровни тумана на своем конечные точки)
Обратите внимание, что если вы разместите туманные квады статически в мире (как вы упомянули как возможность), то вы не сможете получить вид чрезвычайно гладкого тумана, как на изображении, которое вы предоставляете - между ними будут странные совпадения смежные квадраты в зависимости от ориентации зрителя. Эти перекрытия могут отображаться в виде полос или трапеций (если квадраты не текстурированы) или в виде комков (если они текстурированные).
Но давайте предположим, что мы используем широкие четырехугольники, обращенные к экрану, для создания этого наземного тумана и сделаем некоторые расчеты, как сделать действительно гладкий туман, используя этот метод, на ровной поверхности, с камерой, смотрящей прямо вперед - это наша идеальная ситуация , Давайте предположим, что разрешение HD: 1920x1080, что помещает наш горизонт в линию сканирования 540. Давайте также предположим, что у нас есть видимость вплоть до горизонта (то есть, если у вас нет тумана, достигающего полной непрозрачности до достижения горизонта). С одним запуском четырех туманов и одним остановом на каждой линии сканирования (чтобы получить плавный туман) нам понадобится (540 * 2 ==) 1080 четырехугольников тумана. Каждый из этих 1080 туманных квадратов покроет все горизонтальное пространство экрана,
Давайте оценим низко и скажем, что в среднем плоскость тумана будет покрывать около 300 рядов пикселей. Ближайшие будут меньше, самые дальние - меньше, средние ряды - намного больше.
С этой оценкой мы получаем (1920x300 ==) 576 000 пикселей, которых касается средний квадратор тумана. В общей сложности это (576 000 * 1080 ==) всего 622 080 000 пикселей, которые были затронуты для всего эффекта «сглаженного тумана через рендеринг большого количества полупрозрачной геометрии». И это число увеличится для людей, работающих с более высоким разрешением. Более того, мы получаем такое же количество тестов для z-буфера и почти такое же количество операций смешения пикселей, поскольку все эти прозрачные слои снова и снова рисуют друг над другом. Это много пикселей.
И это лучший вариант сценария - вы получите гораздо больший охват экрана квадратами тумана, если пользователь смотрит вниз или приседает.
Обратите внимание, что, поскольку мы перекрываем четырехугольники 1080, мы, вероятно, хотим установить альфа-значение около (1,0 / 1080 ~ =) 0,0009 для каждого, чтобы наш туман достигал полной непрозрачности при просмотре всех четырехугольников 1080. (Мы могли бы пойти выше, чем это, но это значение предполагает, что мы хотим максимально расширить диапазон). Обратите внимание, что это значение не может быть представлено как альфа-компонент 32-битного значения цвета (256 * 0,0009 ~ = 0,237 и поэтому будет округлено до 0, если вы попытаетесь). Вам нужно будет предоставить значение 0,0009 для OpenGL в качестве значения с плавающей запятой, чтобы это работало вообще. (Также обратите внимание, что на самом деле вы не захотите устанавливать одно и то же значение для каждого - хотя мы определили, что мы хотим, чтобы один квад был запущен, а другой - закончен на каждой линии развертки ниже горизонта, чтобы дать нам плавный туман,
Также обратите внимание, что при таком подходе смешивание тумана не будет работать правильно, как это было бы с современным шейдером - вместо того, чтобы получить одно вычисление «смешивания между цветом базового объекта и цветом тумана, используя этот процент», вы получите 1080 расчеты "смешивания цвета до настоящего времени с цветом тумана в процентах от тумана". Это означает, что туман будет влиять на объекты после логарифмического спада. (То есть объект, на который воздействуют 20 квадратов тумана, будет казаться менее чем в два раза более туманным, чем объект, на который влияют 10 квадратов тумана, поскольку первые туманные квады оказывают большее влияние в операции смешивания).
Все это говорит: пожалуйста, используйте фрагментный шейдер.
Нет, правда. Это проще и дешевле, быстрее и быстрее в реализации и менее подвержено ошибкам, и позволяет вам вернуться к фактическому созданию вашей игры, а также лучше во всех отношениях. Мы бы полностью сделали это еще в эпоху PS2, если бы это было даже смутно возможно в то время.
