Практически во всех известных мне 3D-движках на Flash пересчёт графики происходит постоянно, даже когда ничего не меняется. Учитывая один из принципов оптимизации “не считай того, что уже посчитано” мы ещё в первых версиях движка задумались над расчётом лишь изменённых элементов.

Самым простым и логичным способом мы посчитали систему флагов. Например, при установке новых координат объекту, устанавливаем его флаг coordsChanged = true. Далее, через систему разнообразных проверок визуализатор решал, что нужно всего лишь подвинуть графику объекта не перерисовывая его графику. Так эта система дожила до 4-й версии и, во многом благодаря ей, мы имеем хорошую производительность в демке.

По мере развития движка, зависимости между флагами становились сложнее и запутаннее. Где-то происходила избыточная проверка, где-то наоборот. Да и очистка флагов после каждого пересчёта тоже оказалась затратной задачей, т.к. объектов, точек, граней, материалов много, флаги разнообразные, да ещё и составные (в виде списков) встречаются. В итоге мы получили непрозрачную систему, которая ещё и давала паразитную нагрузку на процессор (30-40% при отсутствии изменений на среднесложной сцене с тенями) из-за постоянных проверок и очистки флагов.

Это стало одной из главных причин пересмотра архитектуры движка. На данный момент разработана и проходит обкатку новая система отслеживания изменений — система сигналов.

Читать полностью »

После запуска демо-версии стали очевидны минусы в разработанном движке. Недостаточно эффективно распределяется нагрузка на процессор — например, при отсутствии изменений на сцене процессор нагружен на 30-40%, что неприемлемо; сложные и зачастую “костыльные” методы оптимизации.

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

По ходу многое было переосмыслено и на прошлой неделе приняли волевое решение создавать сразу 5-ю версию, в которой будет принципиально изменена архитектура движка (архитектуру не трогали со 2-й версии). В ней предполагается поддержка нескольких камер в одной сцене, перспектива и вообще восприятие камер как трёхмерных объектов. Z-сортировка будет построена на основе BSP-дерева — этот метод и сейчас, при гигантских мощностях видеокарт, активно используется в большинстве не-браузерных 3D-игр. Уже разработана новая система отслеживания изменений, которая позволяет максимально эффективно использовать процессор (другой вопрос, что пока не понятно, сколько ресурсов потребует сама система ;).

Параллельно с этим идёт пробная интеграция 3D-движка третьей версии с сервером.