Идеи как оптимизировать компилятор xrLC Опции

[Modera]

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

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

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

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

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

[Pavel_Blend]

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

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

[Supple Hope]

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

[cjayho]

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

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

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

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

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

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

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

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

[abramcumner]

в довольно низком разрешении
Нарисовав сцену в разрешении 1024x1024
В чём смертельный недостаток такого метода?

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

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

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

Но чисто интуитивно кажется, что на динамике тени конкретно фейковые.

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

Сообщение отредактировал abramcumner - 26.01.2021, 11:01

[Привет, Андрей]

блендер

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

[Supple Hope]

блендер

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

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

[Привет, Андрей]

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

Сообщение отредактировал Привет, Андрей - 26.01.2021, 13:09

[abramcumner]

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

[Pavel_Blend]

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

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

Сообщение отредактировал Pavel_Blend - 26.01.2021, 14:06

[abramcumner]

Можно по исходникам понять или там всё сложно?

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

Я давно здесь на форуме читал, что создаётся сфера для hemi. Прям геометрия. И эта геометрия, насколько я понял, является источником света. Свет испускается из каждого треугольника и освещает со всех сторон меши.

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

Но что ещё есть в просчёте освещения? Как выглядит алгоритм для каждого типа света (sun, hemi, light)?

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

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

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

Код

00:00:03]     |    | *lighting*: HEMI:   314 lights
[00:00:03]     |    | *lighting*: SUN:    49 lights
[00:00:03]     |    | *lighting*: STATIC: 88 lights
[00:00:03]     |    | *         d-lights: 16

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

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

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

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

Сообщение отредактировал abramcumner - 26.01.2021, 16:03

[Pavel_Blend]

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

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

[abramcumner]

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

[Modera]

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

а может и еще какой множитель там есть.

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

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

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

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

[abramcumner]

А оптимизировать просчёт освещения никак нельзя?

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

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

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

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

[abramcumner]

Хм, ну а почему тогда на динамике тени получаются вполне себе нормальными не смотря на все эти проблемы?

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

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

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

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

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

[Привет, Андрей]

Задал тут вопрос знакомому, дав ссылку на этот тред

В Сталкере калечная трасса, раз в 20 медленней той, что использую я.
Отсюда и растёт половина проблем. Я как-то народ призывал к диалогу, но никто не откликнулся, и я снёс ту тему. Ну не надо, так не надо.

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

И кстати насчёт динамики. Индирект считается для 80-150 солнц, равномерно расположенных по полусфере, а динамика считает только прямой свет. Если бы не этот индирект, даже на калечной сталкеровской трассе, скорость бы возросла кратно. Причём динамика ведь этот индирект тоже юзает, иначе была бы чернота как в дуум3.

Дальше там вообще жесть начинается

Цитата:
Подозреваю однопоточность и отсутствие BVH.

Там мультипоток и естественно BVH. Но цымес в том, что BVH дико медленный, там надо юзать k-DOP. Там даже по коду видно какой он медленный, там полная рекурсия.

Цитата:
В шадоумаппинге самый обыкновенный рейтрейсинг

Шадовмаппинг - это не рейтрейсинг в прямом понимании. Хотя смысл тот же.

А кто такой Абрам Куммер я не знаю. Дело не в точности, говорю же.
Дело в том, что индирект от солнца в реалтайме всё равно не рассчитать так, как это делалось всегда. Ну не вытянет ни одна видеокарта 150 солнц одновременно, даже GTX3080. Про рейтрейсинг щас не говорим, там и не нужно их столько рендерить.

Цитата:
Я давно здесь на форуме читал, что создаётся сфера для hemi. Прям геометрия.

Да какая нахрен геометрия? В нулевую точку спавнится 150 точечных лайтов и всё. У каждой нормаль равномерно распределена по полусфере.

Цитата:
Полусфера hemi апроксимирована 314 вершинами(источниками света).

Человек нормали упорно путает с вершинами. Мда.

Устал комментировать, дальше нет смысла.
__________________

[abramcumner]

Задал тут вопрос знакомому, дав ссылку на этот тред
Я как-то народ призывал к диалогу, но никто не откликнулся, и я снёс ту тему. Ну не надо, так не надо.

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

[Привет, Андрей]

abramcumner,

Это было на форуме по хл, где он пилил совместимый с хл1 движок его еще всякие негры запускали на смарт-часах, а казахские программисты на нем портировали кс 1.6 на ондроед, а сейчас вот занимается разбором сталкерских форматов, ну и уже умеет загружать туда локации из сталкера.
http://alxgk.ru/uploader/img/9e076c9ee42ca...9625b314336.jpg
http://alxgk.ru/uploader/img/943b221c47f67...b3bc12e04fc.jpg
http://alxgk.ru/uploader/img/ec70b550aa20b...80a509aee01.jpg
http://alxgk.ru/uploader/img/ce9881dd36733...18d984c9ebc.jpg

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

Сообщение отредактировал Привет, Андрей - 26.01.2021, 19:47

[abramcumner]

Молодчина!