Привет всем!
Готовимся к релизу на ПК :) Мы изначально предусмотрели поддержку ПК, OSX, консолей и даже Linux. Игра подразумевает использование геймпада. Добавить контроллер и опубликовать порты предполагали после релиза. Но последние опросы ввели нас в замешательство.
Нам важно знать Ваше мнение! Что вы предпочитаете: контроллер или клаву / мышку?
Поделитесь пожалуйста своим опытом :)
Наконец дело дошло до интеграции геймпадов!
Мое предполагаемое ТЗ самому себе по части геймпада выглядело примерно так:
- поддерживать всевозмодные варианты геймпадов, а именно: xBox / Playstation / Nintendo / какиой-нибудь ноунейм
геймпады должны удовлетворять следующим требованиям (иначе поддерживать не сможем):
a) наличие 2-х стиков;
b) наличие D-Pad (4 кнопки на геймпаде слева)
c) наличие ABXY - кнопок на геймпаде справа (South/East/West/North)
d) наличие кнопки Start
e) наличие left/right bumper & trigger кнопок
- организовать интерфейс таким образом, чтобы была возможность производить настройку игры через геймпад (как и должно быть, + на игровых консолях не будет возможности использовать клавиатуру и мышку)
- сократить используемые кнопки в игре (до минимума)
- организовать возможность подключения кода геймпада к уже написанному программному интрефейсу (old Input)
- дать пользователю возможность гибко настраивать геймпад под свои требования
Предполагалось, что геймпад введем после выхода PC-версии игры. Но последний опрос показал, что людям важна не только возможность настройки управления, но и возможность выбора игрового контроллера. По этой причине и было принято решение подключить геймпад как можно раньше. Изучив вопрос, пришел к заключению, что нужно брать xBox геймпад 4-й ревизии.
Причины выбора:
- многие знакомые разработчики мне посоветовали именно его
- он часто используется в играх
Приобрел данное устройство за 5 300 руб. Не знаю, оригинал или нет... Но вроде все работает: беспроводное / проводное подключение на PC и OSX, кнопки, вибрация.
Интеграция с кодом
Как ни старался, но возник ряд проблем связанных с интеграцией.
- давно вышла новая InputSystem (Unity). Система гибкая, удобная. Потому было решено использовать именно InputSystem. Это привело к небольшой переписи логики существующего кода и пересмотру логики
- игрвое меню имело ряд проблем, которые возникли при отсутствии мышки. Дело в том, что навигация в меню с помощью геймпада основана на выделении текущего объекта с которым взаимодействует пользователь. У нас такого выделения не было, пришлось его ввести, пересмотрев дизайн всего меню
- вибрация. Удивительно насколько важна вибрация. Осознал это только тогда, когда начал с ней работать. Вибрация - это своего рода "тактильная озвучка", которая доступна только тем, кто играет с геймпадом. Качественная вибрация повышает передачу атмосферы, чувства присутствия. Некачественная (не соответствует происходящему в игре, расходится с анимациями) наоборот, разрушает впечатление и погруженность в игровой процесс.
Пришлось потратить время на создание целой системы вибрации на:
a) примитивные действия игрока такие как "взять"/"бросить" (незаметная вибрация)
b) вибрация движения (удары, полет, прыжки, неудобное перемещение в присевшем состоянии)
c) внешние реакции (вибрация от перемещения массивных обьектов, например: движение платформ, которые имеют внутренний мотор и вибрация от него передается части помещения)
в) добавлена возможность полного отключения вибрации
Что важно: важно не переборщить с вибрацией.
Пока не добрались, но уже в пути:
Говорят есть возможность использовать 4 вибропривода на геймпаде от xBox. У меня получилось использовать только два:
```
gamepad.SetMotorSpeeds(low, hight);
```
Никто не знает как получить доступ к еще двум?
Интеграция с анимацией
Оказалось, что триггеры геймпада работают "как курки", а не как кнопки. Если использовать их как кнопки, то игра "чувствуется иначе" и это никуда не годится.
Схема геймпада для того чтобы не было путаницы с тем что есть триггеры:
То есть сила нажатия передается в игру. Этим можно воспользоваться и задавать уровень приседания игрока в зависимости от уровня зажатия триггера.
Аналогичная тема возникла со стиками. Вернее со связью анимации перемещения и стиков. Пришлось учесть тот факт, что игрок может идти вперед с разной скоростью, а не только с максимальной как это происходит в случае если за движение отвечает кнопка.
Интерфейс меню
Как говорится: из песни слова не выкинешь. Так и в случае с геймпадом: просто так в меню геймпад не вставишь.
Пришлось видоизменить вкладку меню, которая отвечает за геймпад.
Ранее наше меню по форме немного напоминало меню из Portal 2: находилось в левой нижней части экрана и по форме было прямоугольным.
Нам было весьма проблемно "вставить геймпад" потому, что он получался "впихнутым" в окно, что даже смотрится неочень. А ведь нуно еще и дать возможность гибкой и интуитивно-понятной настройки клавиш.
По этой причине мы планируем разместить геймпад в центральной части экрана (места там достаточно и вниманием он обделен не будет), а меню разделим на два подменю (кнопки), которые раположим слевой и справой стороны экрана как условно показано тут:
О поддержке разных геймпадов
Предъявляемые к геймпадам требования о количестве и типам кнопок сделаны для того чтобы была возможность привести все устройства управления к одному общему виду. С одной стороны это позволит разработчикам иметь представление о том как игрок будет играть в нашу игру. С другой стороны мы исключим неподдерживаемые устройства, которые нам не известны. То есть это некая гарантия с нашей стороны (и гарантия со стороны разработчика движка): если у геймпада есть определенный набор кнопок, то игра сможет поддерживать ваш геймпад.
Заключение, тесты
Тесты разных геймпадов проводил с помощью программы reWASD. Утилита позвляет "подменять" геймпад xBox на Playstation, переназначать кнопки и многое другое. То есть игра думает, что у вас в руках геймпад от Playstation.
Отмечу, что для полноценного теста игры, нужно иметь, пожалуй, более одного физического геймпада. Пока еще не все протестировано и нужно попробовать подключить к игре одновременно несколько (не менее 2-х) геймпадов и посмотреть как обработать эту ситуацию.
Хотелось бы узнать непосредственно у разработчиков, какой второй геймад вы бы посоветовали для тестов и нужно ли? Может есть утилита, которая способна создавать виртуальные геймпады?
В последнее время работал над интеграцией геймпадов в T-Reload.
Unity давно выпустила InputSystem, которая значительно отличается от старой Input.
В нашем случае (синглплеерная игра) не возникло проблем при миграции системы ввода с Input -> InputSystem.
Unity выпустила хороший тестовый проект Warriors, который позволяет изучить принцип работы новой системы ввода в действии.
В проекте использовались следующие устройства ввода:
1) Keyboard
2) Mouse (For simulating touchscreen input in the Unity Editor)
3) PlayStation 4 Dualshock Controller
4) Xbox One Controller
5) Nintendo Switch Pro Controller
6) Android Samsung Galaxy S9 (Touchscreen for Virtual Joystick and Virtual Button)
Клавиатура и мышь "воспринимаются" как одно устройсвто, работают. С ними проблем у нас не возникло.
Unity тестировали проект на реальном Xbox One геймпаде. Я не особо разбираюсь в разновидностях, не уверен, но кажется они тестировали игру на этом:
Подключил свой геймпад 4-й ревизии и он почему-то успешно распознался как Xbox One:
Может кто знает как распознать разные версии геймпадов? Тестовый проект этого не умеет делать для геймпада xBox.
А вот разные геймпады Sony определяются по-разному. То есть можно точно знать что подключено: Dualshock или DualSense.
В WarriorsProject Unity использовали PlayStation 4 Dualshock.
Я же приобрел PlayStation 5 DualSense и WarriorsProject его не обнаружил в всписке поддерживаемых геймпадов. Пришлось добавлять.
То есть, получается, что xBox геймпады распознаются все как один, а геймпады Sony распознаются как разные.
Танцы с бубном на этом еще не закончились. Геймпад DualSense подключается по блютузу к разным компам через пень-колоду. До сих по не пойму точно как он коннектится и от чего это зависит. А вот геймпад от xBox подключается по блютузу без вопросов. Да и лампочка помогает видеть состояние xBox-геймпада (включен или нет, что очень удобно). В то же время на DualSense нет индикатора-лампы и непонятно включен он или нет.
С xBox проблем не возникло пока никаких. Ну кроме как impulseTriggers почему-то до сих пор нельзя запустить из коробки (у сони та же проблема).
Геймпад от сони подключается к компу без танцев с бубнами (быстро) если подключать через кабель. Но вот здесь нажатия кнопок почему-то не определяются именно для DualSense:
В сети встречал подобную проблему у NintendoSwitchPro.
Особо удивила вибрация DualSense. Она совсем не работала. Работали все стики, все кнопки, но не вибрация. Я уже начал думать, что геймпад с браком. Случайно подключил его с помощью кабеля и обнаружил, что вибрация все же есть.
То есть у DualSense вибрация работает только при проводном подключении :/Кто бы мог подумать? Нужно читать документацию.
Работа над интерфейсом геймпада в игре
Изучив разные версии отображения кнопок на геймпадах, принял неверное решение: решил провести линию к каждой используемой кнопке и подписать её (так кто-то сделал). В результате много возился с этим и понял, что не использовал опыт предыдущего дизайнера, а повторил его ошибки XD Распиновка геймпада путала игрока, выглядела крайне запутанно (примерно так):
Это дело нас не устроило и мы пришли к такому варианту отображения подписей используемых кнопок:
На этом пока все. Если кто знает, то подскажите где есть список со всевозможными bindingPaths???
Очень нужно знать баиндинги вот этих кнопок:
Наконец закончил интеграцию системы обработки и вывода настроек геймпада в T-Reload на стороне меню. Не прошло и 2-х месяцев...
На картинке представлены геймпады для T-Reload, которые собраны в блендере.Основным требованием к моделям было: минимальная полигональность. У моделей выше около 6к полигонов.
Стояла задача разработать систему, которая позволила бы с минимальными усилиями подключить к игре новый геймпад. То есть новый геймпад должен подключаться примерно так:
- создается модель геймпада с якорными точками всех кнопок и оформляется в префаб
- в редакторе расставялются линии с примерным положением подписей к каждой кнопке
- префабу геймпада задается ID и сопоставляется набор иконок, которые символизируют кнопки геймпада
На начальном этапе система геймпадов должна уметь:
- вращать геймпад в зависимости от того, что игрок настраивает
- поддержка геймпадов xBox, PS4, PS5, NintendoSwitchPro
- поддержка нераспознанных геймпадов
- разработать гибкую систему, которая позволяет подключать новые геймпады путем их добавления в редакторе Unity
Так как модели будут интегрированы в игру, еще нужно принять во внимание стилизационные особенности T-Reload. Но для дизайнеров (разработчиков) это обычное дело, как и вообще все, что ниже будет написано.
Процесс переделки меню под геймпад
Работу начал с анализа того, что было создано другими разработчиками:
Здесь, конечно, очень малая часть того что было изучено, но даже по этим картинкам можно сделать некоторые выводы.
Следующим шагом было разработать свою версию меню с геймпадом.
Первым делом была разработана система линий, которые подключаются к разным элементам геймпада и которые можно настраивать прямо в редакторе:
Первое время пытался протянуть линию к каждой кнопке, но быстро понял, что запутанный паук из кучи линий - это не то, что радует глаз. "Паук" выглядел примерно так:
Потому решил придержаться того подхода, который использовали другие разработчики (группировка кнопок):
Согласитесь, муравей с усиками выглядит лаконичнее :)
Процесс проб и ошибок был достаточно долгим, пришлось исписать много страниц А4 по нескольку:
Разработка моделей
Каждый геймпад должен иметь свою модель. Цена вроде как визуально приемлимых моделей еще вчера составляла около $20. С курсом доллара сегодня это стало дороже в 2 раза.
Но все эти модели достаточно высокополигональные: около 200к полигонов. Самое минимальное, что удалось найти - это 100к полигонов.
По этой причине геймпады пришлось моделить и текстурироовать самостоятельно. Результаты работы приведены на первой картинке статьи.
Последний геймпад - это геймад для случая, когда геймпад не распознан. Внешний вид этого геймпада не принципиален. Потому модель была сделана на основе нескольких реальных геймпадов. В конце, прикидывая то как придется рисовать иконки кнопок, все же пришлось переделать треугольную кнопку. Другие геймпады сильно менять нельзя.
Далее скачал SubstancePainter, создал карты материалов, маски:
А вот и протекстурированные модели:
Модели выше еще были откорректированы (в основном материалы, шейдеры) так как нужно их стилизовать под T-Reload.
Вот модель геймпада xBox в игре:
Геймад от Nintendo заставил немного понервничать. Дело в том, что у меня его нет и по фотографиям из сети я не мог понять, что у него за линии на корпусе. Позже пришел к тому, что корпус геймпада немного прозрачный, а линии - это конструктивные внутренние элементы, которые просвечиваются через пластик.
Так выгдядит редактор наших геймпадов:
А здесь геймпад PS5 и xBox непосредственно в T-Reload:
Не хотелось бы чтобы у игроков были технические проблемы при прохождении нашей головоломки. По этой причине мы решили провести небольшой тест работоспособности базового функционала нашего проекта под техназванием T-Drones. Пока доступны Windows & OSX версии сборок. Позже, возможно, появится Linux.
Тест направлен на проверку работоспособности настойки управления клавиатуры и геймпадов, заодно проверим:
- работоспособность игры
- графику
- игровое меню в целом
Если после запуска T-Drones появился персонаж, есть возможность им управлять и экран выглядит примерно как на рис. ниже, то грфическая часть успешно работает:
Доступ к настройкам можно получить по нажатию на клавишу ESC.
Друзья! Тест частично автоматизирован, в случае каких-либо проблем вышлет разработчикам соответствуюшие логи. Если Вы заметите неадекватное поведение управления (клавиатура / геймпад), то, пожалуйста, уведомите нас об этом.
Заранее благодарен за Ваш интерес :)
Привет всем! Хочется немного поделиться своим опытом по части разработки, интеграции шрифта и локализации нашей игры, которую мы разрабатываем на Unity.
Поиски бесплатного шрифта
Месяцев 7 назад мне пришлось работать над шрифтом. Ранее не доводилось работать со шрифтами (в шрифтах не специалист), так что создавал всё путем поиска наиболее подходящих, на мой взгляд, образцов. За основу нашего шрифта был взят шрифт, которым написано слово "МОЛОКО":
Далее проводились бесконечные попытки начертания глифов в тетради в клетку и их перенос в растровый формат. Перенос глифов в растровый формат - это моя большая ошибка. Правильнее было бы сразу все делать в векторе. Ниже прилагаю сохранившийся материал из процесса работы над некоторыми глифами (первые наброски):
Финальные тесты в Unity:
Перенос шрифта с бумаги в png-файл:
Пример стилизованного символа "Q" :
Так выглядят текстуры наших финальных кириллических и латинских глифов/символов (растровый вариант):
Поддержка языков, проблемы
Предполагалось, что система локализации должна быть максимально гибкой. То есть должна быть возможность добавления новых шрифтов "без проблем".
Разработка шрифта стала для меня большим проектом. Кроме разработки и переноса шрифта в старой системе шрифтов Unity, нужно было вручную разметить участки текстуры, которые отвечали за символы:
Позже возникла необходимость добавить немецкий язык. Пришлось вспомнить о том, как сложно создавать растровые шрифты, а потом настраивать их развёртки. Вся эта работа превращалась в бесконечный ад, который склонял к использованию чего угодно, помимо имеющейся системы шрифтов.
Позже выяснилось, что ручной подход настройки отображения шрифтов изначально был негибким, не учитывали кучу особенностей символов. Основная особенность - в разных алфавитах разное количество букв. А ещё бывают весьма экзотические буквы, которые либо значительно сокращают место на карте текстуры шрифта, либо требуют особой настройки отображения из-за отличающихся габаритных размеров. Например, лигатуры и "умлауты (umlauts)":
Лигатуры - это символы, которые состоят из нескольких склеенных символов (как на рис. выше).
К счастью, в Unity появился бесплатный TextMesh Pro. Это очень хороший плагин, который автоматизирует процесс переноса шрифтов из ttf-формата в текстуру с настроенными параметрами отображения. Часы работы по настройке отображения каждого глифа, задания расстояний и прочего сократились до пары щелчков мышкой. Фантастика!
Зачем нам свой шрифт, когда можно взять бесплатный?
На самом деле, зачем он и для чего? Очень часто у многих встаёт такой вопрос. В сети нередко возникают споры между дизайнерами и остальными разработчиками по поводу того, что на шрифтах можно здорово сэкономить.
К слову, в сети очень часто высказываются в пользу минимизации времени работы над шрифтами, так как многие предполагают, что шрифт вносит незначительный вклад в восприятие игры и в геймплей в целом. Часто предлагают: "не заморачиваться и использовать что-то попроще".
На самом деле есть доля правды в отсутствии необходимости проработки шрифтов. Согласно моему опыту, все зависит от конечного продукта, от его качества, от того, что дизайнеру необходимо передать (в том числе и с помощью шрифта).
Для дизайнера шрифт - это не просто обезличенные символы, это нечто намного большее. Это способ общения с человеком, это качество общения, качество сервиса, эмоции, способ восприятия информации, нарратива. Это целая вселенная.
Сам по себе шрифт - это мощнейший инструмент, который нужно уметь использовать. Подобрав неверный шрифт, можно не то чтобы испортить атмосферу игры, можно просто сделать игру бессмысленной, непонятной, противоречивой.
Давайте рассмотрим следующий пример.
Допустим, у нас игра для детей 7-10 лет, без насилия. В игре есть милые NPC, которые здороваются с вами, сажают овощи, желают хорошего дня, вечера и так далее. Что-то типа игры про весёлую ферму.
И, допустим, в этой игре дизайнер принял решение писать пожелания и все остальные фразы милого зайки-NPC красным цветом и таким шрифтом потому, что шрифт бесплатный и не было времени работать над собственным шрифтом:
Вы прочувствовали всю доброту пожеланий?
Или вот ещё варианты передачи фраз добродушного зайчика посредством шрифта:
Наверно очевидно, что шрифт решает многое и он, часто, крайне важен.
Одна и та же фраза может передавать абсолютно разную информацию. И эта информация заложена в контексте, в данном случае в шрифте.
Пример с зайчиком, конечно, утрирован, но он хорошо показывает мощь и возможности передачи огромной информации с помощью такого, на первый взгляд, незаметного инструмента как шрифт.
Бесплатные шрифты
Согласно моему опыту, у бесплатных шрифтов есть большие недостатки. Во-пепвых бесплатных шрифтов очень много (тысячи). Во-вторых лично мне не удалось найти в этой разнообразной тьме что-то подходящее для нашего проекта. Убив значительное время на поиски, я изрядно замучался и был поражён скудностью огромного разнообразия в бесплатном.
Среди платных шрифтов мне попалась пара подходящих вариантов. Но в этих вариантах отсутствовали либо кириллические символы, либо латинские. Цена использования каждого из таких шрифтов в коммерческих проектах (приложения) была в диапазоне по 90 - 120 тыс. руб за шрифт. Для использования на сайте цена была ниже. Ну а для личного приватного использования плата вовсе не взымалась.
Перед разработчиками стоит непростая проблема:
- либо нужно вложить 2x * много денежных средств на приобретение шрифта
- либо нужно вложить много сил и создать свой шрифт
Для нас выбор был очевиден - придётся работать и создавать свой шрифт.
Создание векторного шрифта
Начну сразу с платного ПО, которое использовал. Birdfont - замечательная программа за $5 на которой мы остановили свой выбор. Программа позволила быстро перенести растровый шрифт в векторный формат.
Достоинства:
- очень дешёвая лицензия
- достаточно удобная (когда освоишься)
Недостатки:
- тормозит, есть баги, недоработки
- интуитивно непонятный интерфейс и горячие клавиши
Возможно есть ещё какие-то недостатки, которые видны профессионалам, но меня пока все устроило (особенно цена).
Тонкости создания глифов
Birdfont сильно упростил процесс создания векторных глифов и мы расширили поддержку алфавита. Добавили поддержку следующих языков (кроме английского и русского):
- немецкий
- французский
- испанский
- итальянский
- польский
- чешский
- венгерский
Кажется ничего не упустил.
В процессе работы над глифами обнаружил, что играл со шрифтами и сильно проиграл.
Ситилизация шрифтов - головная боль для дизайнера. Как можно играть с дизайном глифов и проиграть.
Дело в том, что мы пытались стилизовать шрифты других стран без глубокого понимания того, что можно делать, а что нельзя: упрощали, перерисовывали части глифов на свое усмотрение. Ниже представлены примеры глифов, которые ранее стилизовали неверно:
В конце мы передали свой шрифт друзьям-лингвистам из бюро переводов Code-Switcher, чтобы похвастаться они все проверили. У них, в основном, трудятся переводчики-носители языка, они-то точно должны адекватно оценить нашу работу. Те, в свою очередь, посмотрели и отправили в ответ пренеприятное известие примерно такого содержания:
Ваши символы "A", "B", "C" стилизованы не совсем верно. Символы "D", "E", "F" содержат серьёзные проблемы.Далее следовало уточнение о том, что неверно и почему. В целом наш шрифт вызывал бы неприязнь, отторжение у носителей языка. Забраковали работу :(
Особо отмечу, что сильно забраковали эти два символа, которые похожи на "А" и "С". Вот они:
Заметили мелкие крючки на конце?
Крючки, точки, кружки с отверстием, вопросительный знак перевернутый вверх ногами - неучтенные мною глифы, которые оказались серьёзной болью при дальнейшем расширении языковой поддержки. Ребята из кодсвичера доходчиво объяснили, что наши дизайнеры слабо разбираются в шрифтах и нам необходимо ввести дополнительные символы вопроса и восклицания для испанского языка.
Дело в том, что испанцы сперва ставят перевернутый знак вопроса / восклицания, далее идёт предложение, а в конце ставятся обычные знаки вопроса / восклицания. И без перевернутых знаков в начале предложения никак не обойтись, просто вот совсем никак, вынь да положь.
В итоге мы учли всю критику от ребят из бюро переводов и добавили полную поддержку перечисленных выше языков.
Теперь попробуем сравнить текст на немецком и английском (наш шрифт) и текст на русском (точно не помню какой именно шрифт в примере):
Наверно заметили, что здесь что-то не то с кириллическим русским текстом. Да, это так. Разный шрифт - разный дизайн.
Кажется, что текст выделяется из-за того, что шрифт очень широкий. И все можно исправить простым сжатие глифов. На самом деле проблем больше и простым ужатием шрифта по горизонтали не обойтись.
Штош, что только не сделаешь, чтобы конечный продукт выглядел неразношорстно, в одном стиле. Наш финальный результат:
Привет всем!
Какой-то художник сказал мне, что если бросить карандаш на работу, то она сразу станет лучше.
А еще говорят "уникальная механика игры\хорошая идея - пол успеха", "если назвать игру правильно, то сильно возрастает шанс попасть в топ" или "правильное название фирмы - пол дела".
А я в это все не верю. Терпение и адский труд - вот ингридиенты хорошего продукта.
Шрифт до сих пор просит себя доработать, исправить, стилизовать:
Стим пока что-то тормозит с документами. Ссылки где мы публикуем обновления по игре:
Как Вам картинка и шрифт?
Уважаемые профессионалы, покритикуйте, пожалуйста, картинку.
Продолжение статьи о том как работают провода в TOTAL RELOAD.
Предупреждение: эта статья не является инструкцией, также, скорее всего, она не будет полезна профессиональным программистам, которые имеют опыт работы с процедурной генерацией мешей. Статья содержит картинки, видео и обобщенные объяснения разработанный нами системы генерации проводов.
При разработке проводов, которые поддерживают тесселяцию, мы столкнулись с проблемой: SSAO из Post Processing V2 работал неверно с проводами в режиме Forward. В результате этого все провода имели неверный эффект затемнения. Если задать произвольный “RenderType”, то провода выглядели примерно так:
Так же провода имели проблемы здесь:
Нужно было добиться такого результата:
Все это из-за того, что SSAO, при расчете затемнения, использует _CameraDepthNormalsTexture - текстуру. Провод использовал встроенный RenderType (или использовал наш, который не переопределен) и в результате _CameraDepthNormalsTexture выглядела так (провода здесь нет):
_CameraDepthNormalsTexture - текстура формируется “Internal-DepthNormalsTexture”-шейдером. Чтобы все работало как надо, для режима Forward этот шейдер придется переопределить. Провод после переопределения:
Но это еще не все! Переопределить встроенный шейдер нужно так, чтобы он учитывал тесселяцию. Иначе при расчете карты нормалей будет использована низкополигональная модель провода и тени будут выглядеть криво. Карта нормалей, сформированная без учета тесселяции:
Так «гладко» и красиво выглядит финальный вариант:
Он же без тесселяции (для сравнения):
Главное, при расчетах, меньше ошибаться. Иначе можно получать вот такие вот макароны-спиральки:
Игровой мир является частично виртуальным и мы всячески подчеркиваем это. Провода - это одна из вещей, которая будет намекать игроку о особенности мира. Для этого было решено показать виртуальность мира через небольшую дезинтеграцию проводов в области их пересечения с игроком или другими предметами, которые наделены энергией.
Итого: провод делится на равные сегменты, которые заносятся в Octree.
В области пересечения провода и игрока в шейдере рисуется отверстие:
for(int k = 0; k < _OBJ_COUNT; ++k) {
half dist = length(_ObjPos[k].rgb-i.worldPos);
half sphere = 1 - ( (dist - _GLOBALMaskRadius) / _GLOBALMaskSoftness);
float a = sphere - 0.1;
clip(a);
albedo.rgb += MUL_COL * step(a, 0.1);
}
dist - дистанция от пикселя до объекта
Далее: если дистанция меньше определенного радиуса, то делается ‘clip’. Кроме этого по периметру clip рисуется подсветка.
dist - the distance from the pixel to the object
Также нужно рисовать отверстие и при формировании _CameraDepthNormalsTexture. Иначе SSAO будет неверно затемнять провод.
Кроме этого нужно рисовать отверстие и при формировании _CameraDepthTexture. Иначе тени будут рисоваться там, где провод дематериализовался.
В результате тени и SSAO работают так:
А здесь провод дезинтегрировался (внимание на тень):
Результат работы над внутренностью тонкого провода выглядит вот так:
Дематериализованный толстый провод:
Как это работает
Провод создается на основе сплайна:
берутся необходимые модели (части провода)
изгибаются вдоль сплайна
финальная модель запекается в “Asset” и используется в игре
Так же сплайн, на основе которого был построен провод, используется для отрисовки внутренней части провода:
определяется ближайший подвижный объект и его проекция на сплайн
строится изогнутый вдоль сплайна участок дематериализованных “кубиков”
Если оболочка провода запекается один раз и алгоритм запекания не требует оптимизации, то внутренняя часть провода (дематериализованные кубики) требует оптимизацию. Изгибание модели кубиков вдоль сплайна на процессоре - это тяжелая вычислительная задача:
Было принято решение: гнуть кубики вдоль сплайна на GPU. После этого нагрузка на процессор составила почти 0!
Как быстро “гнуть кубики” на GPU
Основная идея подхода была подсмотрена здесь: https://medium.com/@roy.theunissen/gpu-spline-deformation-in...
Если коротко:
печем параметры (position, rotation, scale) участков сплайна (с эмпирически подобранным шагом N) в текстуру
декодируем матрицы на видеокарте и смещаем вершины
радуемся результату
Когда вы счастливый обладатель хорошей видеокарты, а именно: ваша видеокарта поддерживает тесселяцию, то все замечательно! Провод будет выглядеть высокополигональным и невидимые части кубиков дематериализации будут качественно скрыты внутри провода (в местах изгиба провода).
А что, если вы не такой уж и счастливый обладатель видеокарты и имеете что-то относительно неновое? Тогда ваш провод во-первых будет смотреться как низкополигональный параллелепипед, а во-вторых он будет проявлять (в областях изгиба) кубики дематериализации. Например, этот изгиб проявит кубики дематериализации так как оболочка провода сильно отступает от создающего его сплайна:
А если еще сильнее низкополигонизировать участки провода (зеленая линия имитирует более низкополигональную версию), то будет ужас. Очевидно, что в местах сильного изгиба провода кубики всегда будут предательски торчать:
Решение: просчитать тангенсы и на основе отклонений подменять участки проводов на более/менее полигональные. Просто же, правда?:) Визуализация тангенсов:
В результате создание модели провода работает так: в зависимости от кривизны участка, выбирается соответствующая модель провода (высокой/низкой или средней полигональности). В результате, данный провод способен скрывать (в местах изгиба) внутренние кубики даже на слабых видеокартах.
Модели разной полигональности, которые используются при построении провода:
Видео примера настройки провода:
На этом пока все, ссылки на нас:
TORSHOCK.COM / VK / DTF / Twitter / FB
