Пишу реалтайм global illumination на cpu [В теме обсуждают что-то совсем другое, поэтому закрыта] (2 стр)

Panzerschrek[CN]
> ИМХО свет лучше считать до растеризации, в пространстве текстуры
Так и делаю.
Я наверное криво объяснил.
Речь шла про то, что текстурные эффекты уже были, очень простые. И доступ к текселям не содержал привязку к 3д координатам. Теперь, для этого рассчёта - содержит.

Suslik
> то есть получает вторичное освещение, только от тех точек, которые ничем не
> загорожены
А, понятно. Загораживание в алгоритме будет считаться.

> используя в качестве источника освещения маленький объект, отбрасывающий
> вторичный свет
А вот тут скорее нет, столь высокая точность, думаю, будет отброшена. Это скорее задача уровня рендера за минуту, чем рендера 60 раз в секунду.
Ведь ртх Н-видии, скажи, он ведь так тоже не сможет?

А вообще, я буду очень рад если кто-то даст скриншотов, ориентиров, как можно считать реалтайм GI сегодня на ГПУ и на ЦПУ. В каком качестве и на какой скорости. (Скриншоты, плиз, под спойлерами, без спойлеров только скрины моего проекта для удобства посетителей темы)

Запустил я короче Квейк-2-РТХ. С официальной плашкой Н-видии. Легальная стим версия, скачана только что. И там, ох, как же там всё плохо.
Память меня обманула, мне казалось там всё было лучше. Но когда я запустил его сейчас снова, там просто ад.
Вот пара скринов, в опциях можно частично отключить текстуры, чтобы свет был виден лучше.
На первом я ловлю тень от лестницы, на втором показываю что тени настолько лагучие, что можно отойти от стены, а твоя тень будет висеть там ещё пару секунд. И это в помойных 30 фпс.
На игровом компе с 3070 картой.

Именно поэтому я и прошу ориентиры нормального реалтайм света.
Кажется, Н-видия идёт куда-то не туда.

Dampire
> Я не догоняю почему целочисленные до сих пор считаются быстрее флоатов.
Основная экономия это отказ от флоат-деления и флоат-умножения.
Они без труда заменяются на целочисленную операцию + арифметический сдвиг.
Разница в скорости значительна.

Ну типа ты в цикле делал что-то вроде

x_float = y_float / z_float;
return (x_float);

А заменяешь это на

x_int = (y_int<<12) / z_int;
return (x_int); // upscaled by '12'

Но с целыми числами работать тяжелее: для сохранения точности все рассчёты должны вестись близко к предельным значениям переменной, 2^31 для знакового 32-бит инта, например. Так что, переводя рассчёт из флоата в целые, основная трудность это идти к максимальным значениям но избегать переполнения.

122
Вставлю свой опыт по использованию Godot 3.5, там есть GI Probes.
Стоит также отметить, что эти GI Probe являются реалтайм ТОЛЬКО для источников света, статическая геометрия уровня же вокселезируется и запекается. Полностью реалтайм источников света и окклюдеров да ещё и без задержек мне кажется не реализуемо на данный момент даже на GPU.

После настройки GI Probes (и уменьшения BIAS почти в ноль) удалось получить на мой взгляд более-менее приемлимые результаты, в 60 фпс на встроенной в проц видеокарте! (Ryzen 5300u, 1920х1080):

- тут ОДИН источник небольшого света освещает конкретную стену, и от неё отражённый свет идёт дальше. Именно при подобных условиях (типа Cornell Box) надо тестить GI, а не как обычно показывают в  красивых демках (в том же Квейк-2-РТХ, в том же Unreal Engine 5), где много источников света, текстуры с нормалмапами и прочими красивостями - сложно вообще понять как ДОЛЖНО быть и реально ли работает GI без задержек и прочих подстав.
Согласен с Сусликом:

- этого и пытался добиться настройками GI Probes. Да, результаты неидеальные конечно тысячи косяков присутствуют (из-за особенностей настройки нет теней от вокселей, но можно сделать обычные тени), много подводных камней, но тут и вводные были очень сложными - запустить на дохлой видеокарте в 60 фпс. Зато обновления от источников света реалтаймовые без задержек, источников света может быть много.

122
> Основная экономия это отказ от флоат-деления и флоат-умножения.
> Они без труда заменяются на целочисленную операцию + арифметический сдвиг.
Целочисленное деление, наоборот, обычно медленней вещественного (а в x86 еще и не имеет векторных аналогов). Вещественное сложение/вычитание/умножение — это, по факту, одна операция — FMA, и по скорости соответствует целочисленному умножению. Вот целочисленные сложения и сдвиги, действительно, являются быстрыми операциями, не имеющими вещественных аналогов. Еще имеет значение, что размер необходимых целых обычно меньше, чем вещественных (за счет углубленного анализа задачи и выбора оптимального compile-time порядка, так что все динамические биты приходятся на мантиссу). Соответственно, меньше размер, больше помещается в векторный регистр, больше операций, быстрее доступ к памяти.

}:+()___ [Smile]
> Целочисленное деление, наоборот, обычно медленней вещественного
Только что деление проверил, всё ещё быстрее.
Если что, я про обычные операции типа imul, idiv. Что там в векторных не знаю.
Но я тут не буду этим заморачиваться, может от каких-то обстоятельств теста зависит.

Prescott
> Вставлю свой опыт по использованию Godot 3.5, там есть GI Probes.
Спасибо, реальный опыт лучше сотни теорий.

> Именно при подобных условиях (типа Cornell Box) надо тестить GI, а не как
> обычно показывают в красивых демках
В плане того чтобы текстуры не мешали увидеть само освещение - согласен.

Однако тут есть уточнение: правильность света человек энивей оценивает на глаз. И например отсутствие теней совершенно точно будет замечено. А вот правильность переотражений, ну, не уверен, увидят ли вообще их наличие. Таким образом, есть вопрос: что отрезать от идеальной реалистичности.

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

У GI есть приятные моменты, которые хотелось бы сохранить для визуала. Это например мягкие тени с размывающимся хвостом. Или влияние матовых объектов друг на друга вблизи (окклюжен?). А вот задача "малый источник генерирует массивные переотражения", ну, актуальность этого явно ниже красивых теней. Если потребуется решать, скукоживать\упрощать тени или переотражения, я решу в пользу качества теней. Суслик, конечно, меня заругает.

122
> Запустил я короче Квейк-2-РТХ. С официальной плашкой Н-видии. Легальная стим
> версия, скачана только что. И там, ох, как же там всё плохо.
> Память меня обманула, мне казалось там всё было лучше. Но когда я запустил его
> сейчас снова, там просто ад.
> Вот пара скринов, в опциях можно частично отключить текстуры, чтобы свет был
> виден лучше.
> На первом я ловлю тень от лестницы, на втором показываю что тени настолько
> лагучие, что можно отойти от стены, а твоя тень будет висеть там ещё пару
> секунд. И это в помойных 30 фпс.
> На игровом компе с 3070 картой.
я всегда говорил, что аппаратная реализация rtx — это как аппаратная реализация сортировки пузырьком. взять самый идиотский алгоритм GI и вшить его физически в чип. это настолько же нелепо с технической точки зрения, насколько это гениально с маркетинговой.

ещё можно предположить, что в графике найдутся какие-то там ниши, в которых rtx окажется полезен. криволинейные отражения, может быть, мягкие тени, но я могу гарантирвать, что через 10 лет диффузный GI будет считаться чем-то совершенно другим, а не отдельными лучиками.

122
> Считать свет идеально получится с теми же шансами, что замоделить все молекулы
> вместо того чтобы просто натянуть текстуры на вершины. Компьютерная графика
> (игр и демосцен) всегда отбрасывала и отрезала, да и физика тоже.
>
> У GI есть приятные моменты, которые хотелось бы сохранить для визуала. Это
> например мягкие тени с размывающимся хвостом. Или влияние матовых объектов друг
> на друга вблизи (окклюжен?). А вот задача "малый источник генерирует массивные
> переотражения", ну, актуальность этого явно ниже красивых теней. Если
> потребуется решать, скукоживать\упрощать тени или переотражения, я решу в
> пользу качества теней. Суслик, конечно, меня заругает.
если у тебя есть алгоритм, который считает одно диффузное переотражение, то множественное переотражение на его основе ничего не стоит написать. поэтому классически задача расчёта GI сводится к задаче расчёта только вторичного диффузного отражения, потому что всё остальное — уже дело техники. более того, даже слово "переотражение" можно исключить, потому что GI по факту сводится к распространению света от каждой точки поверхности до каждой точки, и то, откуда этот свет взялся : переотражение или собственная светимость, на самом деле роли вообще не играет. то есть "трудную" часть GI можно свести к задаче расчёта самоосвещения поверхности, для каждой точки которой известна собственная светимость (без переотражений вообще).

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

https://drive.google.com/file/d/19IhzsdjXBC881PuTP0xmx2oVXeLg1ZzR… w?usp=sharing если кто хочет потестить как работает(плохо) разрекламированный люмен
на сцене на которой его действие и баги видны - я тут набросал.

edit:
небольшое обновление, в том числе убирающее один досадный баг влияющий на освещение(там не был выключен объемный туман,
который по дефолту в этом шаблоне включен, критично не влияет, но 1 из явных багов исправляет). Ну и сборку под линукс сделал просто чтобы была.
https://drive.google.com/file/d/1wQLjBlQR5AnTSwjdqScwqdXhv9JD_Ct5… w?usp=sharing win
https://drive.google.com/file/d/11HyYuW-Rr5y9twbFJ5mhy5gxqxix1gGy… w?usp=sharing lin

Super_inoy
сделай видос?

> как работает(плохо) разрекламированный люмен
ты считаешь, что он плохо разрекламирован или плохо работает?

Suslik
> сделай видос?
ну видос-то я может сейчас и сделаю по запросу, но это не релевантно, у меня 1080ти, а там лучей нет, вполне возможно что на rtx видяхах оно будет работать лучше.
В настройках проекта RTX включен.
Suslik
> или плохо работает?
он отвратительно работает сам по себе. Но в сочетании с остальными фичами - все мгновенно становится отлично.

Super_inoy
> ну видос-то я может сейчас и сделаю по запросу, но это не релевантно, у меня 1080ти, а там лучей нет, вполне возможно что на rtx видяхах оно будет работать лучше.
если бы нвидия не заплатила эпикам, в люмене никогда бы и не было rtx, потому что он там как собаке пятая нога. все оригинальных докладах по техникам люмена они так и говорили.

Suslik
> сделай видос?
а вот и бесполезный видос.

Super_inoy
на самом деле после того как ты спустился под землю, хороший тест. потому что, ясное дело, для тестирования GI нужно в первую очередь отсечь весь прямой свет. я бы добавил в сцену больше чередующихся объектов : светящиеся и несветящиеся тела, например. причём светящихся тел лучше делать совсем немного, чтобы в поле зрения было 1-2 источника, иначе они все смешиваются и трудно оценить их качество. натолкать побольше моделек с мелкими деталями, чтобы тестить мелкие тени от вторичного света.

ещё интересный тест: просто набросать в тёмной комнате рандомных предметов и просто осветить её висящим в центре светящимся шаром (потестить вторичные тени).

несмотря на то, как остойно это выглядит, это state of the art, добиться этого офигенно трудно.

Suslik
> на самом деле после того как ты спустился под землю
ну просто над землей изначально я показал что в тенях таки иногда видно GI и оно даже не в скринспейсе считается,
а на минус первом этаже прям твой тест с мелким окном, в плане там ничего не работает и только баг ловится.
Suslik
> несмотря на то, как остойно это выглядит, это state of the art, добиться этого
> офигенно трудно.
Да это понятно, и использовать это можно уже прям сейчас, просто не в такой радикальной манере.
Suslik
> ещё интересный тест: просто набросать в тёмной комнате рандомных предметов и
> просто осветить её висящим в центре светящимся шаром (потестить вторичные
> тени).

Suslik
> чтобы в поле зрения было 1-2 источника, иначе они все смешиваются и трудно
> оценить их качество. натолкать побольше моделек с мелкими деталями, чтобы
> тестить мелкие тени от вторичного света.
ну это уже сложно для тестового проекта на 500мб, поэтому только скрин из другого.

Super_inoy
> ну это уже сложно для тестового проекта на 500мб
достаточно просто мелких объектов набросать рядом с объектами покрупнее. суть в том, что в этом случае нарушается любимая мантра GI-фейков, мол "вторичное освещение состоит из гармоник низких частот", потому что это допущение напрочь забывает, что оклюжен может быть сколько угодно высокочастотным (от мелких объектов).

> https://img-host.ru/9RTTL.png
это очень крутой тест. в смысле он очень показательный и добиться такого результата очень трудно

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

По прогрессу.

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

И цвет текстур видят тоже.
На текстурах стен статические светокарты, кстати. Не обращайте на них внимание.
[ удалено ]

+++

Suslik
> если у тебя есть алгоритм, который считает одно диффузное переотражение, то
> множественное переотражение на его основе ничего не стоит написать
Всё верно, идея и ранние тесты такого алгоритма у меня есть.
Да вот только со множественным применением есть проблемы, начиная от накопления дефектов, неровностей в освещении, заканчивая недостаточным диапазоном яркости, диффузное переотражение яркость понижает оч сильно.
В общем, имхо, множественное переотражение скорее для статических светокарт. В реалтайме морочить голову переотражениями это значит писать ощутимо более нагруженный код (да хоть тем же диапазоном яркости).

Super_inoy
> работает(плохо) разрекламированный люмен
Suslik
> как остойно это выглядит
А как по мне, хорошо выглядит.
И быстро, и объектов много.
Вот только бы все фэйки повыключать, оставив одно GI. Картинка невероятно загажена фэйками.
Ну и GI тени слишком размыты, в подвале. Очень размыты.
(Что такое "разрекламированный люмен" я не знаю, какая-то фича известного движка?)

> > просто набросать в тёмной комнате рандомных предметов и
> > просто осветить её висящим в центре светящимся шаром (потестить вторичные
> > тени).
> https://img-host.ru/9RTTL.png
Аккуратно с цветом работает.
Мой софтрендер так аккуратно не сможет.
И тени как-то слишком размыты. Неужели тени это та самая проблема?

Super_inoy
Спасибо за эти примеры!
Хорошие ориентиры.