Новости с фронта

Что-то опять сомневаюсь что cpu вытянет такие требования. Нужно будет заморочиться с оптимизацией. Шейдеры здесь прямо таки напрашиваются.

Движок будет freeware хотя бы? Мне всякие старые 2d игры нравятся (иногда), было бы интересно попробовать сделать что-нибудь.

sam0delk1n пишет: Что-то опять сомневаюсь что cpu вытянет такие требования. Нужно будет заморочиться с оптимизацией. Шейдеры здесь прямо таки напрашиваются.

С оптимизацией не надо заморочиваться только если делаете арканоид и то лишь в случае если из области абы как. При должном подходе CPU и не с таким справиться - буферизация и частичное обновление творит чудеса ))

sam0delk1n пишет: Движок будет freeware хотя бы? Мне всякие старые 2d игры нравятся (иногда), было бы интересно попробовать сделать что-нибудь.

Незнаю, вообще изначально это должен был быть пререндер двиг для РПГ, но из-за айстерии не малый крюк вышел.

А тем временем Ваш покорный примат прибывает в активном поиске света. Честно говоря по началу его и самого слегка пугала эта тема, так как казалась достаточно сложной задачкой. Но после изучения старинных манускриптов и древних фолиантов известных и не очень алхимиков, посвященных изучению магии тьмы и света, оказалось что сам принцип до неприличного тривиален, настолько что даже стыдно углубляться в детали. По сему да останутся они пока за кадром, БУЛЬК! Все сырники-бобры с плясками и ритуальными жертвоприношениями начинаются лишь для сглаживания и интерполяции теней. Он уже потихоньку начинает присматриваться к лаптям и подбирать атаме для сих целей, но а пока в первом приближении реализовал, то что ученные мужи на древне бугорском именуют "флэт шейдинг". Ниже приводиться пруф-скрин(ы) для разных положений небесной колесницы великого Амон-Ра:

UPD: Нормализовал цвета, внимательные такэе могут заметить что теперь тайлы разбиты на трианглы, тобишь теперь у тайла не 4 вершины а 5, что позволяет более честно передать геометрию и освещение.

Здорово.

Моё мнение ещё вот какое: вместо того чтобы делить тайл на четыре триса, лучше поделить его на два с возможностью выбирать в редакторе положение ребра которое будет делить тайл пополам (горизонтально или вертикально). Тогда например горы будут выглядеть лучше и вообще будет возможность создавать более сложные детали, меньшим количеством трисов.

А что касается сглаживания: можно конечно интерполировать нормали, учитывая соседние трисы, а можно сделать проще -- делать выборку нормалей из normal map. Будет фактически некое подобие bump mapping'а и без дорогих операций интерполяции. Для этого нужно вместе с цветной текстурой для тайла сделать текстуру в которой в rgb зашифрованы xyz-координаты нормали для каждого тайла. Накладывать на тайл ровно также как цветную. Единственная дорогостоящая операция будет умножение вектора на матрицу, чтобы из пространства карты нормалей преобразовать в пространство модели (мира) самой поверхности, но это вроде бы всё равно дешевле чем считать барицентрические координаты для интерполяции. Если поверхность карты нормалей будет достаточно неровной, то и угловатость общего флэт-шейдинга на этом фоне будет малозаметна.

А вообще эта интерполяция в gpu аппаратная :laugh: .

sam0delk1n пишет: Здорово.

Спасибо, однако пока все еще не очень съедобно, лишь после сглаживания можно будет окончательно судить о результате.

sam0delk1n пишет: Моё мнение ещё вот какое: вместо того чтобы делить тайл на четыре триса, лучше поделить его на два с возможностью выбирать в редакторе положение ребра которое будет делить тайл пополам (горизонтально или вертикально). Тогда например горы будут выглядеть лучше и вообще будет возможность создавать более сложные детали, меньшим количеством трисов.

Спорный вопрос, во первых в ручную возиться с гранями муторно, во вторых это лишние ветления в коде (хотя с другой стороны меньше трианглов - меньше итераций), в третьих менее точный результат, в простейшем случае когда лишь одна вершина поднята опущена по Z действительно два триангла лучше, но если у 2х-3х вершин разные координаты по Z? То там уже не 2 плоскости, с другой стороны 5я вершина сейчас берется как усредненная по 4м вершинам, из-за чего не всегда лучшим способом определяется, к примеру тут лучше бы дополнительная диагональ выглядела бы так


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

sam0delk1n пишет: А что касается сглаживания: можно конечно интерполировать нормали, учитывая соседние трисы, а можно сделать проще -- делать выборку нормалей из normal map

В случае честного 3д это конечно хорошее решение, но не надо забывать что во первых у нас 2д, что дает возможность (а для оптимизации и требование) упростить и минимизировать расчеты, к примеру у меня как факта нет вектора определяющего положение камеры а вектор освещения является констатой для каждого тайла вне зависимости от его положения на экране. Собственно как и параллельные линии на плоскости в 2д изометрической проекции остаются параллельными, когда в перспективе сходятся как и положено в точку, ибо в зависимости от дальности геометрические размеры уменьшаются. В частности из-за этого даже физически возникает ряд сложностей для реализации алгоритмов применяемых в 3д. К примеру плоский тайл согласно томуже принципу изометрической проекции должен быть одинаково освещен в любом положении, но ведь освещенность определяется углом между векторами нормали и освещения.
А во вторых излишняя детализация и реалистичность тут не нужны, они не дадут значимого улучшения картинки (так как камеру вращать нельзя так что подвох и ошибку освещения заметить будет сложно), а возможно даже ухудшат картинку, опять же так как у нас 2д, главная цель освещения не выпендреж, а улучшение восприятие рельефа, т.е. подчеркивание склонов и спусков. Т.е. лучшим будет не более правильный и\или красивый вариант, а тот что позволяет лучше воспринимать объем рельефа. С этой точки зрения флат шейдинг даже лучше, правда конечно смотрится он через мерно "квадратно".

sam0delk1n пишет: А вообще эта интерполяция в gpu аппаратная :laugh:

Ну да я знаю что я изобретаю велосипед, правда есть и контра аргумент в случае 2д основное правило оптимизации это буфферизация и частичное обновление экрана, т.е. мне не потребуется по 100 раз в секунду рисовать рельеф с нуля. (хотя к слову оно и сейчас на моей машине на окне 2560х1440 под 200+ фпс дает, учитывая что это ручная обратка да еще на менеджмент языке очень даже не плохо)

StaticZ пишет: Спорный вопрос, во первых в ручную возиться с гранями муторно

Дизайнеры обычно так не считают, это кодеры лентяи, всё пытаются автоматизировать.

StaticZ пишет: во вторых это лишние ветления в коде (хотя с другой стороны меньше трианглов - меньше итераций), в третьих менее точный результат, в простейшем случае когда лишь одна вершина поднята опущена по Z действительно два триангла лучше, но если у 2х-3х вершин разные координаты по Z? То там уже не 2 плоскости, с другой стороны 5я вершина сейчас берется как усредненная по 4м вершинам

Четыре сгенерированных триса с ненастраиваемой четвёртой вершиной иногда выглядят хуже чем два триса с настраиваемым ребром. В данном случае действительно спорно, т.к. в тайловых играх вообще всё повторяется, но вот в лоу-поли 3д-моделировании очень важно положение таких рёбер, они очень сильно могут менять форму затенения и в целом визуального восприятия. Я бы предпочёл ручной контроль. Кстати интерполяция по Гуро (и даже по Фонгу) тоже будет зависеть от положения таких рёбер, будет заметно что рёбра как то не так повёрнуты. Либо идти другим путём -- делать более глубокую тесселяцию, например делить тайл на несколько десятков маленьких трисов, тогда интерполяция скроет "неправильные" стороны трисов.

Впрочем пока лучше подождать результата со сглаживанием.

sam0delk1n пишет: Дизайнеры обычно так не считают, это кодеры лентяи, всё пытаются автоматизировать.

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

sam0delk1n пишет: Четыре сгенерированных триса с ненастраиваемой четвёртой вершиной иногда выглядят хуже чем два триса с настраиваемым ребром

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

sam0delk1n пишет: Либо идти другим путём -- делать более глубокую тесселяцию, например делить тайл на несколько десятков маленьких трисов, тогда интерполяция скроет "неправильные" стороны трисов.

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

sam0delk1n пишет: Я бы предпочёл ручной контроль. Кстати интерполяция по Гуро (и даже по Фонгу) тоже будет зависеть от положения таких рёбер, будет заметно что рёбра как то не так повёрнуты.

Вообще в идеале сделать свою собственную апроксимацию Гуро сведя ее к линейной интерполяции. Или просто сделать какое-то сглаживание ребер.

И вот сидел он, то бишь примат за ящиком с забавными картинками и была у него доска с кнопками, а также верный спутник по жизни - некий грызун по кличке "Бу", что основательно расположился на подстилке напротив. Долго ли, коротко ли, скоро код пишется, да не скоро движок делается, - написал он первую версию интерполяции освещения следуя сварам и учению великого Гуро и теперь как истинный орангутанг лениво почесывается глядя на новомодное безобразие и размышляет об извечных предикатах багов и косяков всех алгоритмов:

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

Тем не менее прогресс конечно заметен, если смотреть на реальных текстурах сей косяк почти не бросается в глаза:





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

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

StaticZ пишет: интенсивность освещения для вершины за счет соседних поверхностей оказывается намного выше чем должна быть интенсивность ребра.

Результат на количество поверхностей делишь? Это как среднее арифметическое -- надо делить на количество членов.
Кстати пока в игре только direct lighing от солнца, можно интерполировать затенение. А вот если в игре будут точечные источники света, размером сопоставимые с трисами, тогда лучше интерполировать только нормали, а затенение считать для каждого пикселя отдельно, иначе результат совсем неточный будет. Так в теории для 3д, подойдёт ли это для аппроксимации в случае 2д не знаю. Хотя для простоты можно просто делать пиксели более светлыми в заданном радиусе от источника, не делая никаких специальных расчётов, возможно что и так сойдет.

Ну вот на скринах отдельные тайлы выглядят как с флэт-шейдингом. Даже на безтекстуроной поверхности. Как будто соседний тайл не учитывается. Почему так?