На данный момент в проекте используется относительно простой процесс рендеринга сцены:

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

Решением этой проблемы может быть добавление промежуточного этапа в процесс рендеринга, а именно, можно отдавать на выходе из шейдера для отдельных фрагментов карты не итоговый цвет, а только id материала и пересчитанные текстурные координаты (из относительных в абсолютные). Затем эти данные обрабатываются любыми дополнительными фильтрами, в том числе и преобразующим id материала в цвет пикселя с текстуры, но действующими в рамках экрана, а не в рамках каждого отдельного объекта.

Таким образом можно избавиться от необходимости хранить ссылку на текстуру-атлас для каждого отдельного фрагмента карты, а значит и вносить изменения в атлас становится куда проще за счет того, что ссылка на атлас есть только у экранного фильтра. Кто-то может сказать, что в таком случае теряется возможность использовать страничные вариации атласа, о которых говорилось ранее, но это не совсем так - вместо ссылок на конкретные страницы атласа в свойствах фрагмента карты можно хранить номер вариации.

Возникает еще один вопрос - как передать из шейдера для объекта в шейдер для экрана информацию о том, какую вариацию текстуры использовать, но решение тривиально - для передачи данных об id материала и смещении достаточно трех каналов (R, G и B), в то время как канал A остается не задействованным (при передаче данных от ядра игры в шейдер используется трехканальная текстура, в то время как дальше используется уже четырехканальная, независимо от того, записывается ли что-то в альфа-канал).

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

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