JMonkeyEngine и пиксельный хаос

Добавил передвижение камеры (немного странное, на QZAD т.к. лень было контроллер камеры свой писать) и столкнулся с неожиданным поведением смешивающего текстуры шейдера на определенном железе. В связи с чем, выкладываю текущую версию в надежде что кто-то её все-же запустит и отчитается о правильности отображения текстур. Архив с текущей версией можно найти ниже в комментариях.

Решено, быть этому 2д-платформером.

У меня все нормально отображается.

2д-платформер с полной разрушаемостью рельефа до отдельного пикселя.

Червяки! \o/

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

Кет, я не гожусь в художники чтобы нарисовать столь харизматичных персонажей, кроме того у меня на уме сеттинг, более близкий к рпг и более ориентированный на строительство. Но на самом деле я пока абсолютно уверен только в четырех вещах:
1 - это будет 2д платформер с видом сбоку.
2 - там будут деревья и по ним можно будет лазить.
3 - слабым взрывом и другими способами можно будет смести листву с дерева, оставив голый ствол с ветками.
4 - в обязательном порядке будет мультиплеер, но не факт что к срокам конкурса сандбоксов.
Все остальное может и будет меняться в совершенно неожиданных направлениях.

prog, тоже неплохой набор.

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

Mihahail, посмотри на последние скриншоты, в которых текстуры заменены для наглядности простыми цветами. Ядро игры оперирует массивом байт, в которых лежат id типа пикселя, а текстуры и дополнительные данные вроде смещения нужны уже в процессе отображения.

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

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

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

Также в планах с высоким приоритетом уже упомянутые автоматическая сборка атласа "на лету" и поддержка вариаций текстур. На автоматический сборке атласа, думаю, заострять внимание не обязательно, а вот подробнее рассмотреть поддержку вариаций текстур очень даже стоит.

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

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

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

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

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

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

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

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

upd:
Кажется пора создавать отдельный проект - ведение этого подобия WIP-а в формате блога начинает вызывать у меня дискомфорт своим внешним видом.

А я вот с удовольствием читаю тут.

Mihahail, ну так текста меньше не станет, просто хочется немного его структурировать.