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

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

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

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

Вводим понятие сигнал и операция. Сигнал — аналог события (Event). Каждый сигнал уникален и принадлежит определённому объекту. Операция — это ссылка на определённый метод у конкретного объекта.

Сигналы могут порождать и отменять другие сигналы, запускать операции. Таким образом, при создании сцены формируются взаимосвязи между объектами, их сигналами и операциями. На схеме последствия сигнала названы “Sequels”, а отменяемые сигналы — “Cancels”.

Каждое изменение объектов сцены порождает соответствующий сигнал. На схеме перемещение Object2 и поворот его дочернего объекта Subobject2 генерирует два сигнала — move и transform.

При очередном расчёте сцены система анализирует накопившийся список и добавляет в этот список порождённые сигналы. На схеме перемещение Object2 порождает перемещение дочерних объектов Subobject1 и Subobject2.

После чего из списка вычёркиваются отменённые сигналы. В нашем примере сигнал transform у Subobject2 отменяет свой сигнал move, т.к. трансформация объекта включает в себя и поворот, и масштабирование, и перемещение, поэтому срабатывание move не имеет смысла и его можно проигнорировать.

В конце из списка сигналов формируется список операций, которые необходимо выполнить, чтобы сцена корректно изменилась. Однако, тут ещё загвоздка — операции должны выполняться в определённом порядке. Например, нет смысла расчитать освещение объекта, а потом его куда-нибудь переместить. Поэтому операциям добавлен приоритет исполнения.

Тут возникла ещё одна проблема — для одинаковых по приоритету операций иногда также важен порядок. В нашем примере не корректно сначала расчитывать трансформацию Subobject2, т.к. ещё не пересчитаны координаты родителя Object2. Поэтому для некоторых операций может быть указан уровень (в нашем случае уровень вложенности объекта).

Теперь сортируем список операций по этим двум полям и последовательно их выполняем.

Первые тесты показали, что паразитная нагрузка исчезла вообще, а сама система сигналов работает быстрее флагов на 15-20%. В плане прозрачности система стала лучше благодаря концентрации зависимостей сигналов в одном месте и возможности легко протрассировать какие сигналы сработали, какие были порождены и отменены, какие и в какой последовательности выполнились операции.