Войти
ПрограммированиеФорумГрафика

Пишу global illumination на cpu. [gpu vs софтвар] [итог в последнем сообщении, тема закрыта, всем спасибо]

Страницы: 1 2 310 11 Следующая »
#0
(Правка: 26 апр 2024, 12:45) 14:39, 19 апр 2024

Доброго дня.

Уже какое-то время я пишу реалтайм освещение, в пределе это global illumination, то есть распространение переотражённого света от всех объектов сцены.

Сама по себе это задача проблемная с вычислительной точки зрения, она требует быстрой памяти и значительных вычислительных ресурсов. Ближайшие аналоги - ртх от нвидии и люмен в движке уе5. Я пишу свою реализацию, на CPU, сразу прошу прощения но особенности алгоритма пока не планирую раскрывать.

Зачем создал эту тему: мне требуется сравнение с уже существующими аналогами realtime global illumination. То есть с какой-либо реализацией ртх от нвидии, или с готовой подсистемой люмен в уе5. Сравнение покажет мне, куда расти, где хорошо, где плохо и так далее.

+++

От темы я бы хотел увидеть следующее:

1. Ваша визуальная оценка освещения по записанному видео. Оценка конкретно в контексте сравнения с реалтайм rtx\pathtrace и того, что показали бы другие движки с realtime global illumination на именно этой же сцене.

2. Реализация этой сцены на других движках с поддержкой global illumination и протяжёнными источниками первичной эмиссии. Архив геометрии и текстурного атласа сцены: https://drive.google.com/file/d/1T28Y9QsTBB2-OlnfyEFoFTpFosMPSudS… w?usp=sharing

+++

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

Полная сцена на видео:

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

Малая сцена:

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

#1
16:04, 19 апр 2024

Это интересно. Но без чётких теней и зеркал это просто киловатты на ветер.

Надеюсь, не очень злобно вышло.

#2
18:28, 19 апр 2024

iw4nna.rock
Сергей такого не прощает.

#3
(Правка: 5 мая 2024, 19:49) 18:33, 19 апр 2024

iw4nna.rock
> без чётких теней и зеркал это просто киловатты на ветер
На счёт теней ты прав только отчасти. Ты прав в том что у них детальность низкая. Однако, они и должны быть размытыми: в случае глобал иллюминейшена вся сцена источник света, отсюда и размытость теней. Ну и первичный источник света протяжённый (белые шары) а не точечный.

Вот например картинка, включение ги вполне заметно размыливает тень от колонны. Справа только первый шаг света, хотя и от протяжённого источника, и там тень от колонны чётче.

+ Показать

> киловатты на ветер
Немного меньше, видос снят на примерно 95-ваттах потребления по процу. Видеокарта как видно на той же картинке, простаивает.

#4
19:37, 19 апр 2024

122
Вам бы демку сделать и закачать в интернет. Тогда люди смогли бы потестить на своих процессорах. Вам польза будет от темы.

#5
19:48, 19 апр 2024

iw4nna.rock
Когда нибудь до этого дойдёт.

Но сейчас я хочу увидеть другое: ориентир, некую заведомо годную реализацию реалтайм GI. Как по мне, на эту роль лучше всего подходят различные реализации ртх от нвидии, либо люмен в уе5. Сцену выложил в старт посте, надеюсь что придут люди, которым также будет интересно сравнить и сделают это на современном движке с GI освещением.

#6
19:55, 19 апр 2024

122
Ну тут я ничем помочь не смогу. Мой опыт процессорного рейтрейсинга заканчивается на рисовании меша с диффузной (альбедо) текстурой.

#7
20:30, 19 апр 2024

iw4nna.rock
> Мой опыт процессорного рейтрейсинга заканчивается на рисовании меша с диффузной (альбедо) текстурой.
В ртх и люмене рассчёт света на gpu, не на процессоре.
И вот тут появляется интерес: сравнить gpu решение и cpu решение. У меня весь рассчёт это cpu.

За гпу - быстрая память (900 гб\сек против 70 гб\сек у цпу), много специализированных счётных блоков, выдающих колоссальную линейную мощность (85 тфлопс против 1-3 тфлопс у цпу).
За цпу - гибкие ветвления кода и активные межъядерные взаимодействия. Что позволяет писать хитровывернутые алгоритмы.

#8
21:02, 19 апр 2024

Можешь сделать разрушаемость и ретро-бумер шутер из этого.

#9
(Правка: 0:47) 0:43, 20 апр 2024

Почему не GPU? Насколько оно близко к unbiased?

#10
13:45, 20 апр 2024

Андрей5000
> Насколько оно близко к unbiased?
Если я верно понимаю термин, то unbiased это алгоритм без оптимизаций влияющих на качество. Примерный аналог, сжатие архиватором 7z - unbiased, а сжатие кодеком x265 - biased.

Если это моё понимание термина правильное, тогда у меня конечно biased. Результат несёт в себе немалое количество оптимизаций, меняющих картинку.

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

> Почему не GPU?
В целом причин несколько.

Сама по себе это большая тема для обсуждения, кратко оффтопом.

- Меньшая чем у цпу стабильность базы. Код на openCL (Open Computing Language) часто ломается при выходе новых поколений видеокарт. В общем случае нельзя гарантировать, что код написанный для 1080ти и драйверов 2018 года, запустится на 4090 и драйверах 2024 года. Для процессора это заметно в сильно меньших масштабах, код написанный для ш9-9900к и визуал студии 2015, почти гарантированно скомпилируется на современной студии и 13900к.

- В более простых проявлениях, код на гпу слишком сильно зависит от драйвера. Отрисовка на интеловских дискретных картах могла давать артефакты в 2023, но в 2024 драйвера улучшили и артефактов стало меньше.

- В целом, отрисовка на гпу не гарантирует совпадения пиксель-в-пиксель, картинка из 2004 года на тех видеокартах, может не быть идентична картинке в 2024 году. А картинка на карте амд может не совпадать с картинкой на дискретке от интела (intel arc). Опять таки, влияние драйверов и тысяч скрытых настроек рендеринга. Хотя и в цпу есть эта проблема, в основном не совпадают результаты по флоатам, а вот по интам 1-в-1.

#11
22:27, 20 апр 2024

Основная проблема растеризации на CPU - игрушечные сцены. В принципе это не так уж критично, на программном растеризаторе работали Quake, Quake 2, но смотреть на летающие кубики в 2024-м году грустно. Если бы взять какую-то реальную игровую сцену, пусть там даже будет 10-15 тысяч полигонов в кадре, максимум, это бы смотрелось куда интереснее. Кажется год назад, во время предидущей демонстрации я говорил тоже самое.

у меня даже демка с прошлого теста где-то лежит, хех.

#12
(Правка: 10 мая 2024, 12:31) 0:02, 21 апр 2024

g-cont
> Основная проблема растеризации на CPU
> Если бы взять какую-то реальную игровую сцену, пусть там даже будет 10-15 тысяч полигонов в кадре
Не, растеризатор здесь не ограничивает.
Мой растеризатор на современном CPU держит 40-60к полигонов в кадре, в 4к на 60фпс.
Если речь о просто растеризаторе без реалтайм освещения и реалтайм физики. (со статическим освещением)

> смотреть на летающие кубики в 2024-м году грустно
А зачем сложнее? Это тест освещения а не растеризатора.
Для теста освещения вообще корнелл-бокс часто юзают. Там три стенки, конус, куб, и типа такого.

Пока не вижу, как справляется с этим уе5 например, или иная реализация GI.
Хоть скрин-спейс, я буду рад увидеть любой метод GI. Но - на той сцене что выложена в стартовом посте. Чтобы сравнение было адекватным.

Если условный люмен в уе5 сможет эти кубики крутить, тогда подумаю над большим. Ну то есть, немного обидно слышать про кубики, когда непонятно, смогут ли уе5 и ртх-основанные техники выдать реалтайм GI свет лучше.

+++

Добавил позже.
Вот нашёл в инете рандом композицию. По блендеру, в композиции 16к полигонов.
Добавил на сцену несколько штук таких композиций, все не влезли в кадр, получив около 100к полигонов. По быстрому посчитал для них статический свет, он грубый но просто чтобы был. И - в кадре около 60к полигонов, проц даже не напрягается это отрисовывать. Жалкие 30 ватт, почти простой по сравнению с 95 ваттами рассчёта реалтайм света.

+ Показать
#13
8:40, 21 апр 2024

122
А можно примеры когда опенсл ломался ?

#14
11:16, 21 апр 2024

innuendo
> А можно примеры когда опенсл ломался ?
По запросу "houdini new gpu problem" или "opencl new gpu problem" - гугл выдаёт вполне себе подходящие под твой вопрос результаты. Прости, сам я гуглить не буду потому что это не профильное обсуждение для этого треда.

Напомню, что цель треда - сравнить мою реализацию реалтайм ги, и реализацию на условном ртх или люмене в уе5. А для качественного сравнения требуется смотреть освещение на той же сцене. Отсюда - оплачиваемое предложение в 10к: запихать сцену из архивчика в нулевом сообщении, в уе5 люмен.

Так что я тут сижу в ожидании именно этого.

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

Страницы: 1 2 310 11 Следующая »
ПрограммированиеФорумГрафика

Тема закрыта.