- Лис®©™
- Постоялец
всё ещё хочется увидеть как это будет работать с анимированным контентом и расчётом физических теней у движущегося с 200 fps объекта. А лучше если их в кадре будет пара сотен.
PeeKay
> всё ещё хочется увидеть как это будет работать с анимированным контентом и расчётом физических теней у движущегося с 200 fps объекта. А лучше если их в кадре будет пара сотен.
Ну, на самом деле я бы тоже хотел это увидеть воочию, ибо применяю много R&D-техник, визуализацию которых не находил в интернете, но тем не менее. Насчет 200 FPS на GeForce 8800 GTX (железо 2006 года) обещать не буду, ибо это технология своего времени, и в случае с ней мы все-таки упираемся в шину и филлрейт тех лет. Но архитектурно движок к этому готов, а что он сможет в итоге на современном железе, это откроется в процессе.
Ну и вот насчет "пары сотен объектов с физическими тенями" - тут будет сюрприз. Мы не используем Shadow Maps. Мы используем аналитическую аппроксимацию (H16/Bessel), которая стоит копейки для GPU и дает бесконечно гладкие края. Собственно, эта технология и создает такой приятный полумрак\тень в различных частях Спонзы.
Сейчас мы как раз "запекаем" босса в математическую формулу (полиномы), чтобы рендерить его не как меш, а как облако уравнений. Как только закончим с одним - апробируем создать армию клонов.
На днях пытался привести рендерер к более-менее адекватному виду. Сегодня реализовал базу для отражений, правда в шейдере Metallic и Roughness заведены сугубо номинально и назначаются коэффициентами, так что их тут и не видно, да и глобальное освещение на этих двух скриншотах отключено, работает только прямой свет.
Процесс отладки. Черные области на ткани и колоннах - те самые места, где должны проявиться отражения (и они соответствуют эффекту Френеля, заложенному в их механизм), но на тот момент результат уходил в минус, поэтому рисовалась чернота.
Когда включил глобальное освещение
В процессе отладки стартанул движок на 1660. Похоже, это сломало ему лимитер.
Возвращаюсь к отладке. 8800 не потянула патчи из проблемы Гильберта №16, так что потихоньку перерабатываю рендер, так что проблемы визуала на данном этапе являются следствием уже известных и решаемых недоработок.
вообще не понимаю на что я смотрю, но мне нравится, выглядит прикольно. Для 8800 весьма неудрной результат, впрочем всё ещё интересует вопрос как это покажет себя в динамике, где придётся в реальном времени рассчитывать освещение на модели с множеством подвижных частей
Записал небольшой ролик актуальной версии. Кое-какая динамика там есть (правда, модель выглядит кривоватой из-за использования вместо bounding box-а для гильбертовых патчей), но мы это починим.
Перебросил самые тяжелые вычисления (SFQL и тени Бесселя) из вершинного шейдера во фрагментный. Производительность упала, но визуал теперь выглядит лучше.
Продолжаем дорабатывать рендерер
Учерась перенес, однако, фрактальную функцию SFQL из вершинного шейдера во фрагментный. На старой 8800 GTX это было необходимо ради производительности, ибо ей тяжело работать с фрактальными функциями. Ну а на 1660 Super я таки вертаю вычисления обратно, и это даст кристально четкие узоры света. Да, FPS упал вдвое (что ожидаемо), но картинка стала на порядок живее.
Ну а сегодня пришел черед вернуть в строй свой старый добрый ReDAG (Reactive Directed Acyclic Graph), который у меня еще в спагетти-коде отвечал за умное управление сценой. Пока что я интегрировал его только в систему глобального освещения (ага, RadiositySystem).
Ну и таперича результат налицо, что называется: ReDAG своей графовой магией уже почти полностью компенсировал падение производительности от тяжелых шейдырей.
В итоге, мы получаем и более качественный свет, и сохраняем высокую частоту кадров. Теперь интегрирую ReDAG глубже в ядро движка, чтобы он управлял не только светом, но и геометрией, а в дальнейшем, и физикой. Это будет играть значительную роль на различных этапах физических вычислений, включая правдоподобную (и невероятно производительную, согласно проведенным мной исследованиям и тестам) симуляцию жидкостей и частиц, а также позволит значительно упростить вычисления как в узкой, так и в широкой фазах физической симуляции.
Прилагаю несколько ночных скриншотов, вот они:
Глубокая интеграция ReDAG и адельной модели памяти (т.н. Adelic Storage) в ядро движка идет полным ходом.
Можно сравнить с операцией на открытом сердце. Тут мы аккуратно заменяем стандартные вектора на разреженные страничные структуры, которые существуют только в момент обращения. Ну, как и ожидалось, столь фундаментальный сдвиг архитектуры, да еще и на промежуточном этапе заставил "поплыть" некоторые метрики:
1. Производительность временно просела (с 600+ до ~150-300 FPS), так как сейчас работает мост совместимости, который каждый кадр перегоняет данные из новой памяти в старый рендер. Как только будет реализован прямой Zero-Copy доступ для GPU, мы не просто вернем старые цифры, но и превзойдем их.
2. Картинка стала более матовой ("сухой"), ибо часть PBR-параметров (блеск, шероховатость) временно отвалилась при миграции данных в ReDAG.
Это классический этап, который можно охарактеризовать как этакий шаг назад для разбега. Сейчас главное - стабильность новой архитектуры памяти. Блеск (хотя по сути, этот блеск уже намекает, что встроенная механика отражений работает, и ей нужен обыкновенный импульс в виде Metallic\Roughness карт) и тысячи FPS вернутся в следующем патче, когда "швы заживут".
Ковыряю потихоньку ядро Radiosity. Решил несколько ошибок с утечками света и материалами. Теперь занимаюсь оптимизацией пары модулей, которые сейчас тянут производительность на дно. В частности, убираю динамический поиск соседей (KNN) на каждом кадре. Перевод на предрасчитанные топологические связи должен вернуть FPS на законное место.
кстати ещё один вопрос. а что оно по объему сейчас кушает? сколько весит эта демосцена в памяти? сколько весят модели? я к тому - нужно понять что будет когда тут будет сцена с полигональным бюджетом в 600к трисов
PeeKay
> кстати ещё один вопрос. а что оно по объему сейчас кушает? сколько весит эта демосцена в памяти? сколько весят модели? я к тому - нужно понять что будет когда тут будет сцена с полигональным бюджетом в 600к трисов
Спасибо за вопрос, он на самом очень важен, и, безусловно, весьма интересен в контексте MagnaVerse. В частности, меня весьма волнует тема роста цен на память. Да и вообще, сама идея разработать движок, целиком основанный на экспериментальных технологиях, обязана своим возникновением кризису полупроводников и последовавшему за ним взрывным ростом цен на компьютерные комплектующие и одновременным замедлением набившего оскомину закона Мура.
Сейчас, в процессе "хирургической пересадки" ядра на новую архитектуру, потребление подскочило до ~350 МБ. Это жирок отладочной сборки: данные дублируются в старых буферах совместимости и в новых структурах, пока я не завершил полный переход на Zero-Copy пайплайн.
Но я могу назвать целевые цифры, потому что в предыдущей итерации движка (на "спагетти-коде", где ReDAG работал на полную) эта же сцена занимала 60–100 МБ в RAM. Тогда же я впервые невольно провел первый стресс-тест технологии ReDAG (тогда еще предварительной версии), нечаянно обнаружив, что в 13 гигабайт спокойно помещается 1,5 миллиарда узлов. Для справки поясню: такое количество узлов позволяет спокойно загрузить в оперативную память целый город.
И это еще без патчей, основанных на 16 проблеме Гильберта (H16).
Насчет 600к трисов: для моего подхода это не проблема, а скорее разминка.
У меня есть собственный формат .MVO3, который использует сжатие через целочисленные октонионы Грависа. Он жмет исходную Спонзу (570 МБ OBJ) в 60 МБ на диске без потери точности нормалей.
А с внедрением H16 (где геометрия описывается формулами, а не полигонами) понятие т.н. полигонального бюджета вообще уходит на второй план. Там любая стена превратится в 1 формулу, будь она хоть 100 метров длиной.
Так что 600к, миллион, десять миллионов - если это инстансинг или процедурная геометрия, память будет расти логарифмически, а не линейно.
Конечная цель - вернуть публике ощущение океана оперативной памяти при работе с такими объемами, как 8 и 16 гигабайт. Посему, форматы данных будут развиваться. На подходе также собственный формат текстур с предварительным названием .MTDAG. Его принцип работы я изложил еще 20 лет назад на этом форуме - он попытается совместить растр, вектор, а также процедурные элементы. Но в случае с этим форматом данных лучше всего будет один раз увидеть, чем пытаться объяснить его принцип работы.
PeeKay не спрашивай у него больше ничего. Не надо оно тебе.
Полагаю, в текущей точке я могу смело зафиксировать финал эпохи MagnaVerse v0.4.
Мы только что уперлись в фундаментальный предел вертексного освещения (Vertex Radiosity). Как ни крути математику, если хранить свет в вершинах, детализация света всегда будет заложником плотности сетки.
За сим, возможности OpenGL 3.3 для моих задач исчерпаны полностью. Пришло время выпускать кракена выдвигать тяжелую артиллерию, а именно - OpenGL 4.6 и Compute Shaders.
В ближайшие дни займусь расконсервацией технологии SVDAG (Sparse Voxel DAG), которую разработал в начале лета специально для отвязки света от геометрии. Это позволит получить те самые четкие рефлексы и AO, которых невозможно добиться на вершинах без миллионных полигонов.
Ну и, наконец, реализую чистый, современный рендерер на SSBO, без всего того адового кладбища юниформов и легаси-кода, в котором сейчас, честно говоря, конь не валялся. Старая архитектура свою добрую службу сослужила, пора строить новую.
