Добавлен prog,
опубликован
Перенос из блога
Содержание:
Первичная версия после переноса из блога
На данный момент в проекте используется относительно простой процесс рендеринга сцены:
- данные об id материала и смещении хранятся в массиве байт и при необходимости запекаются в текстуру для каждого фрагмента карты
- текстуры с данными передаются шейдеру путем натягивания на прямоугольники, размещенные на сцене
- для каждого фрагмента карты на основе полученной текстуры выполняется конвертация данных в реальные координаты пикселей на текстуре-атласе
- для отображения отправляются полученные из текстуры-атласа цвета пикселей
- персонажи и прочие подвижные объекты должны вроде как накладываться сверху, но за их отсутствием пока не накладываются
Такой подход хорош его простотой - например, добавление передвижных объектов сводится к тому, чтобы добавить их на сцену и выдать им другой шейдер, не пытающийся рассматривать текстуру, как набор id материалов. С другой стороны, попытка реализовать специальные эффекты, которые бы использовали исходные данные о материалах пикселей поверхности, превращается в форменную пытку т.к. данные о материалах теряются на этапе обработки каждого отдельного фрагмента карты, а для эффектов желательно иметь данные о всех соседних пикселях, а не только о тех, которые принадлежат конкретному фрагменту карты.
Решением этой проблемы может быть добавление промежуточного этапа в процесс рендеринга, а именно, можно отдавать на выходе из шейдера для отдельных фрагментов карты не итоговый цвет, а только id материала и пересчитанные текстурные координаты (из относительных в абсолютные). Затем эти данные обрабатываются любыми дополнительными фильтрами, в том числе и преобразующим id материала в цвет пикселя с текстуры, но действующими в рамках экрана, а не в рамках каждого отдельного объекта.
Таким образом можно избавиться от необходимости хранить ссылку на текстуру-атлас для каждого отдельного фрагмента карты, а значит и вносить изменения в атлас становится куда проще за счет того, что ссылка на атлас есть только у экранного фильтра. Кто-то может сказать, что в таком случае теряется возможность использовать страничные вариации атласа, о которых говорилось ранее, но это не совсем так - вместо ссылок на конкретные страницы атласа в свойствах фрагмента карты можно хранить номер вариации.
Возникает еще один вопрос - как передать из шейдера для объекта в шейдер для экрана информацию о том, какую вариацию текстуры использовать, но решение тривиально - для передачи данных об id материала и смещении достаточно трех каналов (R, G и B), в то время как канал A остается не задействованным (при передаче данных от ядра игры в шейдер используется трехканальная текстура, в то время как дальше используется уже четырехканальная, независимо от того, записывается ли что-то в альфа-канал).
Получается, что можно записать номер вариации в альфа-канал и радоваться жизни - экранный фильтр запросто использует эти данные чтобы выбрать правильную страницу атласа, а на прозрачность результирующего изображения такое шаманство не повлияет. Более того, нет реальной необходимости в 256 вариациях атласа, так что имеется потенциал для передачи какой-то дополнительной информации.
Более того, в перспективе можно перейти от трехканальной текстуры для передачи данных в шейдер к четырехканальной и получить возможность выбирать вариацию текстуры атласа не в рамках фрагмента карты, а в рамках каждого отдельного пикселя, но это обойдется в дополнительные затраты памяти и пока не нужно.
Содержание
`
ОЖИДАНИЕ РЕКЛАМЫ...
0
Mihahail
10 лет назад
0
Ктстаи, jmonkey умеет шейдеры?
0
prog
10 лет назад
0
Mihahail, хороший свет на современных технологиях еще не умеет (разработки есть, но пока не в ядре движка), а вот сама работа с шейдерами там на высоте.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.