Хотелось бы обсудить кое что о лайтпамах и долгих компиляциях. Ещё с тех пор как я только ознакомился с процессом создания карт для сталкера и ничего не понимал в программировании, мне было интересно, почему для статики рассчитываются лайтмапы десятками часов на центральном процессоре, и в довольно низком разрешении, а на динамике видеокарта успевает производить по нескольку десятков кадров в секунду с гораздо более чёткими тенями, создаваемыми каждый раз с нуля. Неужели нельзя ГПУ запрячь для создания статических лайтмапов из шадовмапов? Я думаю это было бы гораздо быстрее чем считать их на процессоре. И нет, я сейчас не про всякие там куды-хуюды, опенкл и прочую нехристь, я именно про самый обычный рендеринг.

Вот к примеру как запекает свет xrLC: там есть функция LightPoint, которая вычисляет освещённость точки в пространстве. Сначала освещённость принимается равной нулю, потом перебираются все источники света, при помощи рейтресинга делается проверка есть ли препятствие между точкой и источником, и если препятствия нет к освещённости прибавляется какое-то число.

Можно ли с помощью рендеринга есть препятствие между точкой и источником? Конечно можно! Именно так работает шадоу-маппинг. Что для этого нужно? Нарисовать сцену с видом из точки источника, для точечных источников, или всю сцену целиком под определённым углом, для источников направленных. Потом трансформировать координаты нашей точки в экранное пространство и сравнить Z с глубиной из Z-buffer'а. Если Z больше, то точка чем-то перекрыта, препятствие есть, освещённость не прибавляется.

Самый смак в том, что видеокарта рендерит обычно не одну точку. Нарисовав сцену в разрешении 1024x1024 можно заменить при удачном раскладе до миллиона с копейками проверок пересечений луча на центральном процессоре, и это миллисекунды, в отличии от.
Конечно такой подход требует серьёзных архитектурных изменений, тут нужно перебирать все освещаемые точки для источника, а не источники для точки, но это задача решаемая, благо количество этих самых точек известно (равно количеству пикселей в лайтмапе), у каждой есть своя позиция, всё можно вычислить, что и делается при обычном запекани лайтмапов.

А теперь внимание вопрос, почему так никто не делал? Рендерить чцену и получать zbuffer можно уже очень давно, однако поиск по запросам типа "lightmap calculation with gpu" ничего толкового мне не выдаёт, как будто никто даже не пытался такое воплотить никогда. В чём смертельный недостаток такого метода? Вроде же должно работать.

Modera, я конечно не разбираюсь в исходниках xrlc и исходниках движка. Но чисто интуитивно кажется, что на динамике тени конкретно фейковые. А компилятор делает можно сказать физически корректный просчёт освещения (чтобы были мягкие тени, hemi и нормальные источники света), как это делают рендеры для 3д программ (v-ray например). Может xrlc - это упрощённый vray, в котором есть только затенение.

А вообще, мне было бы интересно узнать от си++ программистов, которые изучили весь движок (в том числе xrlc), про то как устроен xrlc и не только. Может есть что-то интересное в движке и его устройстве?

Очевидно, что компилятор освещения считает свет рейтрейсингом, причем не шибко эффективно. Подозреваю однопоточность и отсутствие BVH. Ускорять просчет света не надо, лучше подумать, как в блендер экспортировать скомпилированую геометрию и юв развертку карты, и там уже все позапекать сайклсом.

В шадоумаппинге самый обыкновенный рейтрейсинг, только разрешение гораздо ниже. Если на динамике размер карті теней максимум 4096*4096 (это при указании флага -smap4096, по умолчанию меньше, не помню точно, толи 1024*1024 толи 2048*2048), то разрешение карты теней для всех лайтмапов вместе взятых - на порядки выше.

На динамике есть два вида освещения - ambient occlusion (по факту - все освещение кроме теней от солнца) и обычные динамические тени. Первые занимают 90% освещения и они заранее просчитаны компилятором. Получается на динамике видеокарта динамически отрисовывает лишь малую часть освещения, единицы процентов.

Для статики компилятором делается второй проход просчета теней, где запекается не только АО но и тени от солнца.

В точности же.
Берешь точечный источник, для него делаешь 6 шадовмап на все стороны кубика. Фов - 90 градусов. На расстоянии 1м пиксель соответствует квадрату со стороной 90 / 1024 * 1м = 9см - уже 10ppm. На расстоянии 30м - это уже будет квадрат со стороной 90 / 1024 * 30 = 2.6м -> 0.4ppm

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

С шадовмапами ты вместо лучей используешь четырехугольные пирамиды с вершинами в источниках света.


Почему фейковые? Нормальные и корректные тени.

Тогда нужно ко всем популярным 3д редакторам писать.

Преимущество блендера не в том что он "популярный", а в том что его можно форкнуть и работать с нужной версией, не опасаясь, что кто-то что-то сломает апдейтами. Ну и прочие преимущества бесплатного опенсорса. Для запекания света он достаточно хорош, как готовое решение. А написание скриптов для автоматизации этого процесса - дело гораздо более простое, чем создание своего инструмента.

Давайте больше зависимостей для зависимостей чтобы решить зависимости, ведь apt нас ничему не научил

Согласен, Modera чутка не додумал. Все гораздо проще.
apt get escape-lm-20 и все. А то выдумал какие-то шадовмапы.

А как освещение запекается в xrlc? Можно по исходникам понять или там всё сложно? Я давно здесь на форуме читал, что создаётся сфера для hemi. Прям геометрия. И эта геометрия, насколько я понял, является источником света. Свет испускается из каждого треугольника и освещает со всех сторон меши. Но что ещё есть в просчёте освещения? Как выглядит алгоритм для каждого типа света (sun, hemi, light)?

Мне просто интересно, почему так долго запекаются карты освещения.

Там все просто и даже слишком просто. Как и написал Modera, из каждого пикселя лайтмапы бросается лучик к каждому источнику света.


Ну не прям геометрия-геометрия Просто хемисфера апроксимируется некоторым количеством вершин в зависимости от настроек качества. И каждая такая вершина считается источником света.


Бросается лучик, если лучик дошел, считается переданная энергия и прибавляется к накопленному значению в лайтмапе.


Очень много пикселей в лайтмапе и много источников света. Например:

Полусфера hemi апроксимирована 314 вершинами(источниками света). Солнце для мягких теней считается как 49 источников света. Ну и дизайнер поставил 88 + 16 источников света. Возможно он поставил меньше и некоторые тоже заменяются несколькими источниками.

Получается из каждого пикселя лайтмапы запускается ~500 лучиков. К сожалению общее количество пикселей лайтмапы в лог не выводится.

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

Вот там статики 1.2кк вершин, после применения групп сглаживания будет под 2кк. Вот уже миллиард лучиков чисто на освещении вершин. На это ушло 22 часа => получается 25к лучиков в секунду.

abramcumner, понятно. Думаю, если делать тоже самое с помощью запекания блендера + скрипт для автоматизации (который создаёт нужные изображения, юви-карты и делает запекание автоматически), то время просчёта карт освещения будет дольше.

А оптимизировать просчёт освещения никак нельзя? Или нужно переписывать код на абсолютно другой, более производительный метод просчёта?

Переносить алгоритм из хрлц в блендер смысла нет. Надо, как писал Supple Hope, использовать встроенное запекание и преобразовывать в хреевские лайтмапы или даже не в хреевские.

Вот-вот, там вся плавность достигается тем, что тень считается не как одна проверка луча = один пиксель, а по нескольку раз с некоторым отклонением. По идее на это влияет параметр Jitter samples. А если считать в один проход, то получается такая же пиксельная каша как на динамике с шадоумапами.




Хм, ну а почему тогда на динамике тени получаются вполне себе нормальными не смотря на все эти проблемы? Тем более в случае с направленными источниками света нужно использовать ортогональную проэкцию, и качество с расстоянием падать не будет. А такие источники как раз отнимают больше всего времени на просчёт, поскольку влияют на весь уровень сразу, а не на малюсенькую по меркам уровня сферу точечного источника.

1. Перенести расчет на ГПУ, лучиками или модеровскими пирамидами. Минимум x10 должно быть ускорение.
2. Ну 300 хеми и 50 солнц это наверное перебор. А в этом логе по идее от них основной вклад во время компиляции. Можно просто столько не задавать.


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

Еще можно вообще забить на лайтмапы и компилировать локации за 30 секунд.

Блюрят. Я кстати не уверен, что они получаются нормальные, когда тень уходит в даль. Но да, у тебя лайтмапы будут такие же, как тени на динамике. А стандартные лайтмапы везде ровненькие и четкие.

Надо поставить "Ночь, улица, фонарь, аптека, Бессмысленный и тусклый свет." и посмотреть, что там за тень получается.


Тебе придется кучу кадров делать, каждые 1024 / 20ppm = 50 метров.

А может все давно так и делают, надо orange`а спрашивать.

Знакомый знакомый. Мастер диалога

Если человек может дать совет - почему бы его не привлечь?

Молодчина!

Дай ему ссылку на xray_re, пусть не мучается

Trollz0r, он не декомпилит, он готовый левел грузит.

abramcumner, не можешь расписать как происходит просчет лайтмапов в билдах до 1537? Те что без смены погоды. Там потрясающе красивая графика получается

Много буков. Моя теория по "оптимизации" такова:

1. Отказаться от лайтмапов. Компиляторы с лайтмапами оставить только для билдо-проектов.
2. Отказаться от статичного рендера (dx8). Использовать не воспрещается, но безлайтмапная карта на нем будет выглядеть УГ.
3. В объектах отказаться от шейдера "default". Только def_shaders\def_vertex, def_shaders\def_aref_v, def_shaders\def_trans_v и т.п.
4. Ставить у проектов качество hemi 0. (см. пункт 7)
5. Грамотно настроенный безлайтмапный компилятор компилирует навороченную карту в среднем за 15-20 минут.
6. Результирующая картинка в игре дотягивается шейдерными спецэффектами типа SSAO, контраста и подстройкой r2_sun_lumscale* командами.
7. Вот проверенный компилятор тов. Дизеля для ЧН-СДК (может подойдет и для ЗП) с кое-какими моими техническими оптимизациями.
https://cloud.mail.ru/public/BmXE/7JBfyCYXH
Из минусов, что он 32-битный, на сверхсложных проектах упрется в ограничения памяти.
Также с картинкой были какие-то глюки, пока в настройках проекта не выставил Hemisphere quality в 0.
Из плюсов: почти мгновенная перекомпиляция сложных карт, оперативное внедрение правок, изначальная совместимость карты с ТЧ/ЧН/ЗП.
8. Как пример сочетания такой карты и шейдерных эффектов см. Liberty City для ТЧ.
https://www.gameru.net/forum/index.php?s=&a...t&p=1686665

Как будто хрей-ре не грузит готовый левел перед тем как его декомпилить. Я вот недавно делал редактор спауна для билдов на основе хрей-ре, с ЧАЭСкой из 1472 билда он справляется лёгко, хотя там всё очень отфанарно сделано, геометрия вся хранится в дисплейных списках, MU модели перестают быть MU, нет даже самой банальной оптимизации вроде фрустум куллинга.


Короче сделать просмотрщик уровней из сталкера проще простого в наше время.

Не могу, не знаю. Думаю, точно так же, как и в финалке. Единственное, что в финалке опять что-нибудь сломали

abramcumner,
без сомнения.
Слава билдобогам - рассеяные тени от солнца восстановили. И кривость sun-источников тоже пофиксили.
Осталось лишь саму графику пофиксить. При одинаковой погоде в например 1511 билде и 1580 - разные картинки, причем не в пользу второго. Полагаю - дело может быть в том, что в 1511 лайтмапы состоят исключительно из статических источников и запекаются сразу вместе с текстурой террейна, а в более поздних - из хеми и сан-источников, которые занимают альфа-каналы

В 1580 вообще нет хеми в лайтмапах, там он только повершинный.

Це внатуре мерзость.

Modera, не знаю что там есть - но отличия явно налицо. Первые два скрина - мертвый город 1511:



Остальные - мертвый город 1537:







Явный даунгрейд графики в 1537 при почти той же погоде:

1. Если под лайтмапами понимается запеченный свет и sun в текстуре, то согласен. Но хеми при этом нужно оставлять. Отключение запечки света и sun было сделано K.D. через ключи запуска, если не ошибаюсь.
2. Уже отказались. Ещё до релиза ТЧ.
3. Запеченка от хемисферы будет выглядеть убого в местах, где сетка не плотная. Надо будет делать сетку плотнее по всей не implicit геометрии. Кто этим будет заниматься? К тому же, есть различия при вертексном запекании и запекании в текстуру, из-за чего могут возникать косяки с затенениями на геометрии с вертексным освещением.
4. Качество сильно в минус. А значит, не вариант.
5,7,8. В этом нет смысла, потому что картинка становится хуже, а значит это не оптимизация как таковая, а лишь попытка сократить себе время компиляции любыми способами. Таким макаром можно выпилить расчет порталов и секторов. Компиляция же быстрее будет, хоть игроки и будут страдать.
6. Это всё приблизительная подгонка картинки, которая проблему не решит. SSAO не вернет того глобального затенения, потому что он для этого не предназначен. Аналогично с консольными командами.


Не так много людей работают с компиляторами и гпу, поэтому и не пробовали. Даже нормально распоточить компилятор мало кто пробовал, что уж о гпу говорить. Если рассматривать расчет на гпу, то надо учитывать ньюансы в виде теряющейся энергии света и "прозрачности" материалов (которая в виде параметра у компил шейдера). Может при расчете на гпу тут могут вылезти проблемы и как итог - не совсем верный результат, но это надо пробовать и смотреть.


К сентябрю 2003 года было сделано много правок по переходу на сменную погоду. Под это дело правились и движок, и компилятор, и шейдеры. К тому времени ряд переменных был вынесен из настроек сцены в константы компилятора и благополучно забыты. Также переменные, которые раньше были выставлены в материалах, перекочевали в параметры погоды (возможно с иным экспортом в шейдеры):

Слишком много всего было задействовано и просто так это всё не вернуть. Считаю, что "ту красивую графику" можно получить изменяя текущие шейдеры и добавляя дополнительные параметры погоды для более тонкой настройки составляющих освещения, а не откатываясь в прошлый век.

SkyLoader, дело не только в компиляторе, но и в сдк. В сдк 2002 куча дополнительных настроек:
https://www.gameru.net/forum/index.php?s=&a...t&p=1628482

Которые потом вынесли aka захардкодили как константы в код самого компилятора) Скай всё правильно говорит.


Плохо ищете, господа, плохо ищете:
https://github.com/ands/lightmapper

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

Такого освещения растеризацие не добиться, только ГИ или ворлдспейс оклюжном - хоть с вокселями, хоть с рейтрейсингом.

В общем понятно. Как я и думал испытания и только испытания дадут полную картину понимания что так или не так с этим методом, и пригоден ли он к применению. Правда внедрять его сразу в xrLC я думаю весьма трудоёмко, а если не заработает будет потом обидно, надо сначала на каком-нибудь легковесном самодельном движке обкатать.
Вроде алгоритм перебора мировых точек соответствующих пикселям в лайтмапе не очень сложный, судя по всяким старинным статьям на эту тему.
https://www.flipcode.com/archives/Lightmaps...hadowmaps.shtml


Если бы xrLC ещё учитывал это всё. В обычной трассировке там вариантов только два - луч либо пролетает, либо не пролетает.
А параметр translucency всего-лишь регулирует, скажем так, размазывание света между соседними вершинами.
То есть как оно работает: берётся кусок геометрии с уже рассчитанным вершинным освещением, у него ищется самое максимальное значение освещённости, для каждого канала отдельно (красный, зелёный, синий, солнце, хеми). Потом перебираются все вершины и их цвет смешивается с максимальным в пропорции указанной этим самым параметром. Если 1.0 цвет у всех вершин будет максимальный, если 0.0 то останется везде оригинальный... И всего то навсего.


Ну мне попадалась эта штука, вроде чё-та там какие-то лайтмапы считаются через GL, как работает толком не написано. Но где там именно запекание шадоумапы в лайтмап?

Продолжил эксперименты со сторонними x64 компиляторами. Есть прогресс. Раньше по образцу Дизелевского ставил hemi 0, и в игре перли глюки с тенями. Сейчас проверил с hemi 3 и со всякими параметрами отключающими лайтмапы. Глюков нет, хотя компиляция заняла 11 часов.

ЗЫ: вроде где-то видел картинки пересобранных SDK, где в свойствах проекта можно было ставить то ли hemi, то ли jitter выше дозволенных 3. Это сильно улучшает картинку?

1, 6) Ну вот если бы кто смог к рендеру добавить дополнительно карту АО, чтоб прям в СДК с ТХМкой создавалась, и работала как нужно - тогда да толк будет. Или вон - есть же решейды, которые успешо "иммитируют" эффект АО - нельзя его "выдернуть" и внедрить в Сталкер(шейдеры)?
3) Я вот пробовал экспериментрировать с одной локацией, одинаковые настройки компиляции, дефолтные шейдеры везде заменял на "def_shaders\def_vertex" - в результате на локации замечено неплохое падение производительности - может ли быть из-за этого? Ибо больше не на что грешить.
7) Вот хотелось бы на этот результат посмотреть на ЗП, на r4 - у вас там с Дизелем нет репозитория с правками по движку и компиляторам? Или у Дизеля как обычно - всё локально свалено в кучу без коммитов - разгребай как хочешь? А то имея репо - можно было бы "углубиться" в ваш "велосипед", перенести на ЗП, правки компиляторов перенести на исходники компиляторов х64, попробовать вылечить АО и т.д. и т.п. ...

Погода вообще сильно разная и солнце светит с разных сторон.


+++

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

У компиляторов есть -gi. Но пока не знаю, как на безлайтмапную r2 влияет. Сейчас как раз компилю.

Наверно можно. Но нужно время на изучение. И взять "вменяемую" основу. Будет странно наворачивать сторонние эффекты на ванильный синюшно-мыльный r2 ТЧ. В сборке Либертисити я постарался шейдерами и смоллскаями закрыть изначальные косяки старого движка, и уже на эту систему врапперы-решейды в будущем ставить будет интереснее.

ХЗ. Но компили всегда с -noise, будет красивее и быстрее.

Лично я из творчества тов. Дизеля почерпнул саму идею безлайтмапности. Плюс его компиляторы изначально x32 и сверхсложную геометрию не тянут. Сейчас проверяю/перехожу на x64 компиляторы "borscht". Осталось проверить влияние -gi и окончательно настроить батники на отключение лайтмапов. Так что, репо наверно уже не нужно. А ЗП в плане моддинга, тема спорная и сложная. Пока есть другие дела, держусь подальше.

Проверил, не влияет.


Пока из проблем: при hemi 0 артефакты. При hemi 3 местами слишком темные тени на геометрии, частично лечатся повышением r2_sun_lumscale_amb, но по качеству до Дизелевского не дотягивает. Буду проверять с hemi 1.

Ну я бы так не сказал - к примеру у меня есть свой проект, со своими компиляторами, куда я вношу свои правки - и вот захотелось добавить/опробовать на своих компиляторах... Готовые/скомпиленные не всегда могут быть полезны, это так сказать - попробовать-побаловаться, не более - а если понравится - практического толку нет, разве что самому садиться и "изобретать велосипед".

Спорная - да, к тому же есть такая платформа - как КоК, которая юзает всё от ЗП, которая может уже и не так набирает обороты - но и не сбрасывает.

Именно лайтмапное АО дает большое качество картинке, а такими настройками вы его максимально убьете, особенно для лоуполи объектов.Быстрее, и возможно красивее.... Изза отсутствия шакализирования полигонажа моделей на удалении.ИМХО конечно, но проще чем ТЧ.

В плане моддинга - ЗП конечно проще, я сам достаточно долго просидел на ТЧ, когда перешёл на ЗП - оказалось гораздо проще. А КоК ещё прощё, т.к. там уже введено много дополнительных механик и возможностей, доп. колбеков по скриптам и прочего - часто замечаю, как на ЗП мододелы вечно изобретают велосипеды, в то время как в КоК это уже изначально есть - бери и пользуйся...

А у господ моддеров проблем с добавлением новых скриптовых или xr-шейдеров в ЗП не возникало?

С xr вообще ниразу.

Тут я не спец по шейдерам - но вполне успешно затаскивал коммиты от людей, у которых такой проблемы не было, и всё работало...

Извини, дядя Макрон, но статика, с другой стороны, прекрасна для тестов. По аналогии с сорсом - это аналог запуска на минималках. По аналогии с Урина Энжайн 4 - это компиляция на минималках (а там считаются пути ии, и лайтмапы, грубо говоря).


А конпелять на средних 2 часа локу в 5к поли - я и бал.

Короче поэкспериментировал с созданием лайтмапов из шадовмапов, тени от солнца при проверке пересечения 1 к 1 получаются вот такие:

Они же с джиттером а-ля считаем освещённость девяти соседних пикселей и записываем среднее значение:

Вот так выглядит hemi/AO полученный этим методом:

Вот так выглядит хеми+солнце (+ какие-то непонятные баги:D ):

Тоже самое но увеличил размер лайтмапы с 1024х1024 до 2048х2048:

Вот так выглядят тени в билде, откуда я взял уровень для тестов:


Что касательно производительности, при компилировании с максимальной оптимизацией рассчёт лайтмапа в разрешении 2048x2048 с одним источником солнца и 192 источниками хеми занимает 148 секунд.
В данном примере видеокарта используется только для создания zbuffer-а, рассчёт и закраска пикселей в лайтмапе делается целиком на процессоре в одном потоке. (тоже можно вынести на ГПУ при использовании шейдеров, ибо это является собой по сути обычную отрисовку с поменянными местами мировыми и текстурными координатами).

xrLC с этим уровнем в максимальном качестве (хеми 3 - 192 источника, солнце 3 - 49 источников, 20 ppm, jitter 9) справляется за 13 минут. Если качество солнца опустить до 1 (9 источников) справляется за 9 минут. Если jitter samples опустить до 1 справляется примерно за те же 140 секунд.

Насчёт закраски полигонов, видокартой или не видеокартой, хотелось бы уточнить как не получить вот такую лажу:

На скринах можно увидеть много нежелательных чёрных полос и точек. Те что возникают между соседними полигонами в UV 100% являются следствием косяков в моей функции закраски треугольников, а вот насчёт подобных артефактов в месте UV стыков у меня такой уверенности нет, и даже при залитии треугольников белым цветом при помощи видеокарты и наложении получившейся текстуры на модель получается результат как на скрине.

Если открыть какую-нибудь лайтмапу в граф. редакторе, можно увидеть как цвет от каждой части расползается в стороны:

Это xrLC так борется с подобным или для чего-то другого было сделано?

А вообще, в хрлц самый долгий этап - это просчёт хэми? 90% всего времени? Получается остальные стадии можно не оптимизировать?

И как можно ускорить процесс просчёта хеми, солнца и статичного света, не изменяя хрлц, а только регулируя настройки? В этой теме советовали уменьшить количество источников света. А какие ещё параметры влияют на производительность?

И вообще, за что отвечают параметры компиляции? Понятно что качество хеми - для улучшения качества света. Но не понятно, что такое качество. Это количество источников света хэми? Или не только?

Jitter samples. В зависимости от этого параметра для каждого направленного источника(солнце и хеми) запускается 1, 4 или 9 лучей, с некоторым отклонением, для плавности.

Параметры Sun Shadow Quality и Hemisphere Quality регулируют только количество источников света.

Modera,
Это просто неиспользуемое пространство текстуры.