Оскільки ви попросили досвіду, ось моє.
Ще в часи, коли я програмував ігри на 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, якщо ви спробуєте). Вам потрібно буде надати OpenGL значення 0,0009 як значення з плаваючою точкою, щоб це взагалі працювало. (Також зауважте, що ви насправді не хочете встановлювати таке саме значення для кожного - тоді як ми визначили, що хотіли запустити один квадроцикл і один закінчити на кожній лінії сканування нижче горизонту, щоб забезпечити плавний туман,
Також зауважте, що суміші туману не будуть працювати коректно, використовуючи такий підхід, як це було б із сучасним шейдером - замість того, щоб отримати один розрахунок "суміш між базовим кольором об'єкта та кольором туману за допомогою цього відсотка", ви отримуєте 1080 обчислення "поєднання між кольором досі та кольором туману за відсотком туману". Що означає, що туман буде впливати на об'єкти, що слідують за логарифмічним випадом. (Тобто, об'єкт, на який впливає 20 квадратів туману, виявиться менше, ніж удвічі меншим, ніж щось, на що впливає 10 квадратиків туману, оскільки перші квади-тумани мають більший вплив у процесі змішування).
Все, що потрібно сказати: Будь ласка, використовуйте лише фрагмент шейдера.
Насправді ні. Це простіше і дешевше, швидше і швидше втілити, і менше схильний до помилок, і дозволяє вам повернутися до фактичного створення вашої гри, і краще всіляко. Ми б повністю це зробили ще в епоху PS2, якби це було навіть невиразно можливо на той час.
