Godot Engine - отличный способ реализовать сбор ресурсов в игре

Чекал игры от других инди-разрабов, по тегу “сделано на годот” на сайте itch.io, наигрался вдоволь, много хоть и простых, но вполне интересных нашел, позалипал в них немного.

Всё это тоже часть процесса разработки - поиск вдохновения и просмотр референсов. В моём случае почти самая любимая часть, так как можно прокрастинировать и не делать саму игру, а вдохновляться до потери пульса. Но, нет, всё таки игру делать нужно, иначе материал для девлога будет состоять из одних лишь мемов и футажей из интернета, а вы же не для этого сюда пришли)
Периодически я пытался родить из себя музыкального гения, открывая fl studio и пялясь в экран, как баран на новые паттерны и кракозябры недоаккордов в пиано ролле. Получалась какая-то шляпа, я расстраивался и закрывал секвенсер, матерясь и чертыхаясь. Бывает такое, ну не прёт и всё. Через какое-то время надо вернуться и начать заново со свежей головой, это обычно помогает.

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

Продолжая блуждать по просторам нетленного itch.io я наткнулся на интересный проект на нашем любимом движке - генератор пиксельных планет. Поигрался с ним, поковырял исходники, ничего там не понял, кроме того, что всё работает на шейдерах и работает очень круто, но преисполнился желанием сгенерировать себе такие планеты для бэкграунда. Не, ну а че, по стилистике они очень вписываются и гармонично смотрятся. Лицензия позволяет использовать, в качестве благодарности укажу автора в титрах, если, конечно, игра доживет до такого состояния, в котором появится необходимость в этих самых титрах. Как говорится, вашими молитвами и живем!

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

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

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

Ссылки:
https://deep-fold.itch.io/pixel-planet-generator - генератор планет
https://itch.io/games/made-with-godot - игры по тегу "сделано на годо" на итч.ио

artstation.com/nikovik

3) Модульный стилизованный персонаж

4) Супермаркет (интерьер и экстерьер)

5) Пак с зимним лесом

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

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

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

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

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

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

Деньги. Которые, как известно любят тишину, поэтому все кругом помалкивают.

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

Тут могу сказать что это первая игра из трех, которая принесла хоть какие-то деньги. Примерно получилось ~250к за пол года продаж, хвастаться особо не чем (2 года разработки и поддержки игры). Но ради такого случая зарегался как самозанятый чтобы карту не заблокировали спать спокойно. Пока полет нормальный.

Система оплаты через самозанятого простая: приходит платеж от steam, например поздно вечером, а на следующее утро вы его видите. Добавляете 'продажу', указывая вчерашнее число, Valve corporation как юридическое лицо. Сумму в рублях, которую высчитываете перемножая приход на курс доллара за вчерашнее число по сайту центробанка ( http://www.cbr.ru/currency_base/daily/ ).
После чего у вас сформируется сумма, сколько вы должны государству, а это на данный момент 6% по вышеописанным условиям. Оплачиваете в установленные сроки - готово.

Full HD 4k rtx on GIF:  =)

Я не буду лишний раз дразнить людей, неприемлящих прямые ссылки на Steam.
Игра называется Unferat, кто захочет познакомиться с проектом ближе - легко найдет.

Всем спасибо за прочтение! Буду рад ответить на любые вопросы по игре в комментариях.

С ЧЕГО НАЧИНАЕТСЯ ДРУЖБА:
С Никитой мы познакомились 4 года назад. В одной из групп по разработке игр на Unity я увидел пост о том, что он ищет себе репетитора по созданию игр и решил откликнуться. Мне было интересно взять на себя такую ответственность и обучить его всему, чему научился сам за пару лет. Тем более на то время у меня была необходимость в деньгах, ведь я разрабатывал The Story of Henry Bishop, а разработка - это всегда затраты, особенно если ты стараешься сделать как можно лучше. Мы позанимались около 12 занятий. Все они проходили в Skype и при помощи программы TimViwer, так как Никита живет в Санкт-Петербурге, а я из Беларуси. Никита начинал с нуля, до этого он и понятие не имел что такое программирование и разработка игр. В этом амбициозном человеке я увидел себя. У него было такое же рвение научиться делать игры, как и у меня 2 года назад. Он был готов днями практиковаться и делать все задания которые я ему давал. В итоге мы стали хорошими друзьями. Никита хорошо подтянулся по работе в движке и программированию на C#. Мы вместе сделали пару небольших проектов и я окончательно убедился, что он такой же отчаянный, как и я. Готовый работать за идею, не бросить все на пол пути или через месяц. Я с уверенностью могу охарактеризовать его надежным и ответственным человеком.

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

ДА НАЧНЕТСЯ РАЗРАБОТКА:
Когда я доделал The Story of Henry Bisop, то был уже готов делать что-то новое. Мы с Никитой неоднократно обсуждали создание большого проекта для Steam и вот пришло время погрузиться в совместную разработку. Мы составили план и краткий сценарий игры, потом расписали все подробно, что бы понимать сколько работы нам предстоит. В игре запланировано минимум 5+ часов геймплея, поэтому у нас очень большие локации, состоящие из участков города. Мы определились, что локаций будет 4 и поделили каждому по 2 на создание левел дизайна. Так же распределили все остальные обязанности, например я делаю искусственный интеллект, Никита делает инвентарь и т.п. Все это мы делаем сообща, что бы не возникало проблем при совмещении. Основное время уходит на создание сцен и написание кода. Мы хотим, чтобы игра получилась максимально атмосферной и для нас очень важно создать хорошо проработанные локации.

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

Я очень люблю видеоигры и много играю. Игры, фильмы, книги - это все то, что вдохновляет меня при создании своих собственных проектов. При создании AWAKENING на меня наложили свой отпечаток такие игры как: Resident Evil 2-3, Silent Hill 1-2, The Last of Us 1-2, Alan Wake, Until Dawn, Days Gone, The Evil Within 1-2. Вдохновился - это не значит, что я просто взял и скопировал чей то проект. Я думаю наш проект будет своеобразный, со своей собственной атмосферой и историей. Но об этом уже судить не мне, а тем игрокам, которые захотят поиграть в AWAKENING.

ОБ ИГРЕ:
Майор в отставке Шон Тернер возвращается домой с ежегодной встречи ветеранов войны в Ираке. Приехав в свой маленький провинциальный городок, Шон понимает, что за пару дней его отсутствия здесь произошло что-то ужасное. В этом месте больше нет людей, а пустынные улицы теперь наполняют жуткие твари, отдаленно напоминающие соседей, которые еще вчера мило улыбались Шону. Нужно как можно быстрее попасть домой, спасти жену, дочь и выбираться из этого ада. Но вскоре Шон поймет, что не все так просто и зло, с которым предстоит бороться гораздо страшнее, чем та война, в которой он принимал участие много лет назад.

Мы постарались придумать интересную историю с сюжетными поворотами, диалогами, неожиданным финалом. Так же наградили всех персонажей своим характером. В игре будет несколько видов оружия. Предметы можно будет подбирать и использовать. Игроку предстоит решать различные головоломки и загадки. Будет большое разнообразие врагов, с которыми можно будет вступать в открытое противостояние, либо тихо убить подкравшись сзади. Враги будут слышать звуки шагов, выстрелов. Если вы будете стрелять в кого то, а в это время другие монстры будут неподалеку, то вся орава прибежит на шум, для того, чтобы убить вас. Так же игра будет полностью озвучена на русский и английский, а текст локализован на 11 языков. Еще мы предусмотрели полную поддержку геймпада, для любителей консольных девайсов.
.

ПЛАНЫ:
Честно сказать не знаю, как пойдет дальше, но пока по плану мы хотим сделать полостью рабочие 2 локации и всю механику. Сделать так, чтобы это была не сырая недоделка, а полноценные игровые локации и выложить игру в ранний доступ на Steam в начале весны. Возможно найдутся люди, которые захотят поиграть в нашу игру, а так же поделиться своим мнением, для нас это очень важно. Далее по плану, до конца лета завершить оставшиеся локации и выйти в релиз.

ПОДВЕДУ ИТОГ:
Благодаря прогрессу сейчас можно делать массу крутых вещей, о которых я и не мечтал будучи ребенком. Я помню, как впервые увидел игры на PS1 и подумал: «Это же как фильм, ничего себе, это походу предел технологий и лучше уже быть не может». Ps1 у меня никогда не было, зато она была у соседа, который очень любил выпить и он иногда давал мне её на денек поиграть в обмен на бутылку вина. Выходило гораздо дешевле, чем в игровом клубе)
Так вот к чему я. Сейчас технологии и интернет развились на столько, что позволяют создавать игры сидя у себя дома. В интернете полно информации, книг и видео уроков о создании игр и, при желании, практически любой может создавать игры и выкладывать их на всевозможные площадки. Нужны только упорство, желание и время. В интернете куча сообществ, где можно находить единомышленников, общаться или объединяться в небольшие команды. Главное самому быть упорным и найти такого же упорного товарища, а вместе и разработка веселее и процесс идет бодрее.

P.S.
Пост получился достаточно длинным. Спасибо всем, кто дочитал его до конца. Хочется поздравить вас с наступающим новым годом и пожелать вам в новом году, идти к своей мечте. Если у вас нет мечты, то вы просто обязаны её придумать. Найдите себе хобби, которое сделает вас чуточку счастливее и окунет в тот азарт, что был у каждого в детстве, но потом был утрачен с возрастом, под гнетом бытовых проблем и однообразных рутинных дней. Я нашел такое хобби и теперь действительно счастлив. Желаю вам счастья в 2021 году ребята.


Страница игры в Steam: https://store.steampowered.com/app/1488810/AWAKENING/?beta=0
Группа игры в VK: https: //vk.com/blazesgamesvk

Больше ракурсов на  артстанции кому интересно:

https://www.artstation.com/artwork/NxKRbz

- Железнодорожное депо (времен совка)

- Эффекты шлейфа от атак

- Набор объемных стекол

Новый постоянно бесплатный контент:

- Плагин для Легкой Баллистики

- Скины для манекенов в военном стиле

- Мост для красивых автомобильных визуализаций

На этом все :)

Наша группа в других соц. сетях:

- Ютуб -

- Телеграм -

Сейсмическая карта

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

Карта высот

Высота поверхности зависит от того, является ли плита океанической либо материковой (коэффициент WatersKoef), а также от текущего уровня сейсмоактивности.

Температура

С температурой все просто. Чем больше солнца на планете (SunEffectKoef), тем жарче . Чем больше высота, тем холоднее.

Влажность

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

Биомы

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

{BIOM_JUNGLES, BIOM_SWAMP, BIOM_SEASONALFOREST, BIOM_FOREST, BIOM_SAVANNA, BIOM_WOODS, BIOM_TAIGA, BIOM_DESERT, BIOM_PLAINS, BIOM_TUNDRA, BIOM_ICEPLAINS, BIOM_HOTWATER, BIOM_WARMWATER, BIOM_COLDWATER, BIOM_ICEWATER}

Карта со спутника

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

Здесь показаны возможные изменения параметров при фиксированном зерне генератора:

А тут различные варианты зерна генератора (seed) при фиксированных параметрах, близких к земле:

Спасибо за внимание! Дальше буду делать построение региона на основании карты планеты методом diamond square.

Можно скачать на компьютер или играть через браузер:

Ссылка на скачивание игры в посте в ВК: https://vk.com/wall-174686745_11501, потому что Пикабу запрещает ссылки на gamejolt.

Помните игру "Ну, погоди!" (Электроника), в которой Волк яйца собирал? Был миф: если набрать 1000 (тысячу) очков, то вам покажут секретный мультик...

В случае с Совой секретный финал не миф, и очков надо в два раза меньше 😊

Источник

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

Наконец, блюпринты бьют по производительности, так как компилируются в байт-код, который работает на встроенной в движок виртуальной машине. Да, их можно нативизировать, — то есть преобразовать Blueprint-логику в файлы C++, но даже разработчики из Epic рекомендуют этим не злоупотреблять.

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

Источник

Я считаю, что если программисту нужно работать с Tick-функциями, или он использует какую-то сложную математику и пространственные запросы (например, LineTrace), всё это лучше вынести в С++. Отчасти из-за всех перечисленных особенностей Epic Games раздумывают над созданием отдельного скриптового языка для реализации игровой логики в Unreal Engine.

Тем не менее, блюпринты — достаточно мощный инструмент, который в Unreal Engine 4 используется не только для построения игровой логики, но и для работы с анимацией и системой эффектов Niagara. Поэтому каждая студия должна сама найти подходящий баланс между Blueprints и С++. Например, технические дизайнеры Riot Games использовали блюпринты в Valorant только для создания способностей игроков.

Valorant

Сами Epic Games рекомендуют использовать блюпринты, когда в проекте очень много ссылок на контент, а его логика работает в первую очередь на визуальную составляющую. Также они пригодятся в создании прототипов, прямолинейной или редко используемой логики, которая не является частью основной архитектуры. Всё, что не получит преимуществ в С++ с точки зрения производительности, масштабируемости и стабильности, тоже может быть создано в Blueprints.

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

Словом, с любыми важными переменными, перечислениями и типами данных C++ работает лучше. Но и работа в Blueprints не отменяет классический подход, а только органично дополняет его в необходимых случаях. Так что разработчикам от визуального программирования никуда не деться.

Для начала, нам нужны единичные векторы dx и dy, перпендикулярные друг другу и вектору взгляда, чтобы построить на них плоскую систему координат, которая будет для нас экраном. Вектор dy у нас уже есть («Вектор, показывающий, где у "глаза" верх» в исходных данных). Что же на счет dx? А тут приходит на помощь векторная алгебра, из которой мы помним (или нет), что результатом векторного произведения двух векторов является вектор, перпендикулярный векторам-множителям, с нормой равной площади параллелограмма, построенного на этих векторах. Соответственно, если исходные векторы перпендикулярны друг другу и оба с длиной равной единице – длина результата тоже будет равен единице. А это прекрасно, ведь нам нужен именно единичный вектор.

Таким образом,

dX[0] = tv[1]*dY[2] - tv[2]*dY[1];
dX[1] = tv[2]*dY[0] - tv[0]*dY[2];
dX[2] = tv[0]*dY[1] - tv[1]*dY[0];

где tv — вектор направления взгляда, а dY вектор, показывающий где у взгляда верх.

Дальше, было бы неплохо определиться с длиной векторов dx и dy, определив таким образом размер экрана (по сути, это управление углом обзора). Мне оптимальным показался вариант, когда у экрана размер равен единице

dX[0] /= max_x;
dX[1] /= max_x;
dX[2] /= max_x;
dY[0] /= max_x;
dY[1] /= max_x;
dY[2] /= max_x;

Где max_x – разрешение экрана по x. Да, dy тоже делится на max_x, чтобы длина вектора dx была равна вектору dy, так как иначе изображение будет растянуто по одной из осей.

Итак, у нас есть:

dX, dY – векторы, определяющие плоскость экрана.

dZ – вектор направления взгляда.

for (int y = 0; y <= max_y; ++y) {
for (int x = 0; x <= max_x; ++x) {
tv[0] = dZ[0]+x*dX[0]+y*dY[0];
tv[1] = dZ[1]+x*dX[1]+y*dY[1];
tv[2] = dZ[2]+x*dX[2]+y*dY[2];
// tv – вектор, показывающий направление луча из точки [x,y] экрана
// ...
};
};

В рамках этого цикла мы и будем работать дальше.

2. Пересечение луча с поверхностью.

Обычно лучший способ найти в пространстве точку пересечения луча с поверхностью, которая задана формулой – это решить систему уравнений, состоящую из уравнения плоскости и уравнения луча. Но если в уравнение плоскости проникает тригонометрия – решений становится бесконечное множество (буквально бесконечное, вида x = 0 ± 2πn, где n∈R ), и что делать программно с этой бесконечностью – не ясно. Поэтому мы будем искать точку пересечения итеративно:

1. Определяем параллелепипед, ограничивающий нашу поверхность (мы помним, что по условиям ограничили ее в размерах).

2. Ищем точки пересечения луча и параллелепипеда. Получаем 2 точки – «вход» и «выход» в пределы параллелепипеда.

3. В точке «входа» переводим координаты из глобальной системы координат в локальную для параллелепипеда.

4. В локальных x и у находим по формуле поверхности координату z. Если найденная координата z больше, чем у точки «входа», фиксируем, что мы «под» поверхностью. Иначе – фиксируем, что мы «над» поверхностью.

5. От точки «входа» до «выхода» проверяем аналогичным образом все точки на луче с заданным шагом. Как только на следующем шаге состояние отличается от того, что было на предыдущем – значит, нашли точку пересечения.

6. Если до точки «выхода» состояние не менялось – значит пересечения не было.

Теперь по пунктам.

Существует простой и понятный алгоритм быстрого поиска пересечения прямоугольника с лучом на плоскости. Для его понимания нужно ввести пару терминов:

Точка входа – точка пересечения луча с прямой, в случае если нормаль этой прямой направлена навстречу лучу.

Точка выхода – точка пересечения луча с прямой, в случае если нормаль этой прямой направлена навстречу лучу.

Алгоритм такой:

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

К чему это я? А вот к чему. Этот подход отлично работает и в пространстве, если заменить 4 прямые на 6 плоскостей.

Как мы помним, поверхность задана точкой и нормалью и ограничена в размерах по x, y и z. Причем эти x y и z – в локальных координатах. То есть наш параллелепипед, ограничивающий поверхность, должен уметь вращаться вместе с поверхностью.

Поэтому для начала определим эти плоскости с учетом поворота параллелепипеда с поверхностью. Для этого нам понадобятся 3 вектора:

ddX[3] = {0,0,0}; // единичный вектор, который направлен вдоль оси X нашей поверхности
ddY[3] = {0,0,0}; // единичный вектор, который направлен вдоль оси Y нашей поверхности
ddZ[3] = {0,0,0}; // единичный вектор, который направлен вдоль оси Z нашей поверхности

с ddZ все понятно – это нормаль к поверхности.

С ddX и ddY сложнее. Одной только точкой и нормалью можно задать в пространстве только бесконечную поверхность. А тут нам нужно зафиксировать поворот этой плоскости вокруг оси z. Это можно сделать разными способами – я беру еще одну точку на плоскости и фиксирую ее координаты в глобальной системе координат. Допустим, это точка point2, а нулевая точка поверхности — point. Тогда

ddX[0] = point2[0] - point[0];
ddX[1] = point2[1] - point[1];
ddX[2] = point2[2] - point[2];
len = sqrt(ddX[0]*ddX[0]+ddX[1]*ddX[1]+ddX[2] *ddX[2]) ;
ddX[0]/=len;
ddX[1]/=len;
ddX[2]/=len;

Как мы видим, я не забыл, что нам нужен именно единичный вектор (с длиной равной единице), поэтому я посчитал длину вектора от точки point к точке point2 и разделил каждую координату на длину. Эта процедура называется нормализация вектора – приведение его к единичной длине с сохранением направления.

Ну и ddY по старой схеме (как в пункте 1, где мы экран рисовали) определяем как векторное произведение ddX на ddZ:

ddY[0] = ddX[1]*ddZ[2] - ddX[2]*ddZ[1];
ddY[1] = ddX[2]*ddZ[0] - ddX[0]*ddZ[2];
ddY[2] = ddX[0]*ddZ[1] - ddX[1]*ddZ[0];

Таким образом, мы можем задать все 6 плоскостей. Например, плоскость, ограничивающая параллелепипед «снизу» определяется так:

spoint[0] = point[0] - z * ddZ[0];
spoint[1] = point[1] - z * ddZ[1];
spoint[2] = point[2] - z * ddZ[2];
n[0] = -ddZ[0];
n[1] = -ddZ[1];
n[2] = -ddZ[2];

где point — нулевая точка нашей поверхности, а z - половина высоты параллелепипеда.

Остальные – по аналогии, меняем только - на + и буквы координат.

Дальше нужно в общем виде понимать, как мы будем искать точки пересечения луча и плоскости. Допустим, плоскость задана точкой point[3] и нормалью n[3]. Луч задан точкой tp[3] и вектором tv[3]. Еще одна картинка в стиле «я у мамы paint master»:

Несложно догадаться, что если векторы n и tv имеют единичную длину, то расстояние от точки tp до точки пересечения с плоскостью будет равно -h/p. Шучу, сложно догадаться. Но при желании вы можете это проверить. Даже так – если вы сейчас в школе проходите векторную алгебру – вы должны это проверить и выложить в комментариях доказательство. Иначе вам поставят двойку. Или что там сейчас ставят в школах…

Как же найти эти h и p? Тут на помощь снова приходят определения из векторной алгебры. Скалярное произведение векторов численно равно длине проекции одного из этих векторов на другой. Как определить скалярное произведение? А примерно так:

float MulVecSc(float *Vec1, float *Vec2){
return Vec1[0]*Vec2[0] + Vec1[1]*Vec2[1] + Vec1[2]*Vec2[2];
};

Как мы видим из рисунка, h – это проекция на нормаль вектора от точки tp до точки point, принадлежащей плоскости, а p – это проекция на нормаль вектора tv.

vp[0] = point[0] - tp[0];
vp[1] = point[1] - tp[1];
vp[2] = point[2] - tp[2];
p = MulVecSc(n,tv);
h = MulVecSc(n,vp);
t = - h/p;

Знак p покажет нам, с какой стороны плоскости мы находимся (а значит покажет, нашли мы точку «входа» или «выхода»).

Резюмируем. В пространстве точки пересечения луча с параллелепипедом находятся так:

float ddY[3] = {point2[0],point2[1],point2[2]};
float ddX[3] = {0,0,0};
float ddZ[3] = {n[0],n[1],n[2]};
tmMulVec(n,ddY,ddX);
// 6 плоскостей. Ищем самый поздний "вход" и самый ранний "выход"
// Плоскость 1
spoint[0] = point[0] + x * ddX[0];
spoint[1] = point[1] + x * ddX[1];
spoint[2] = point[2] + x * ddX[2];
vp[0] = tp[0]-spoint[0];
vp[1] = tp[1]-spoint[1];
vp[2] = tp[2]-spoint[2];
n[0] = ddX[0];
n[1] = ddX[1];
n[2] = ddX[2];
p = tmMulVecSc(lv_n,tv);
t = - tmMulVecSc(lv_n,lv_vp)/p;
if(p>0.0f){ // выход
if(t<t_out)
t_out = t;
}else{ // вход
if(t>t_in)
t_in = t;
};
// Плоскость 2
spoint[0] = point[0] - x * ddX[0];
spoint[1] = point[1] - x * ddX[1];
spoint[2] = point[2] - x * ddX[2];
vp[0] = tp[0]-spoint[0];
vp[1] = tp[1]-spoint[1];
vp[2] = tp[2]-spoint[2];
n[0] = -ddX[0];
n[1] = -ddX[1];
n[2] = -ddX[2];
p = tmMulVecSc(lv_n,tv);
t = - tmMulVecSc(lv_n,lv_vp)/p;
if(p>0.0f){ // выход
if(t<t_out)
t_out = t;
}else{ // вход
if(t>t_in)
t_in = t;
};
// Плоскость 3
// ...
// Плоскость 4
// …
// Плоскость 5
// …
// Плоскость 6
// ...
if(t_in<t_out&&t_out>0){
// есть пересечение
};
Так. Теперь мы знаем, что в промежутке от t_in до t_out мы внутри параллелепипеда.
Дальше, как и планировали, будем проверять каждую точку с неким шагом h на то, находится она выше или ниже поверхности в локальных координатах.
Что такое локальные координаты?

Это система координат, образованная теми самыми ddX, ddY, ddZ которые мы определили выше. Как очевидно из рисунка (на этот раз действительно очевидно), если у нас есть точка p, то вектор, ведущий от нулевой точки нашей поверхности до точки p будет определяться векторной суммой x*ddX+y*ddY+z*ddZ, где x y и z локальные координаты этой точки. Что ж, в таком случае, зная глобальные координаты точки p мы можем получить локальные таким образом:

vtp[0] = p[0]-point[0];
vtp[1] = p[1]-point[1];
vtp[2] = p[2]-point[2];
x = MulVecSc(ddX,vtp);
y = MulVecSc(ddY,vtp);
z = MulVecSc(ddZ,vtp);

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

F = F_xy; // тут у нас определение значения функции, описывающей плоскость. Его мы рассмотрим позже, в 3й части.
if(z<F){ // определяем, находимся мы в точке входа «над» или «под» поверхностью
in = true;
}else{
in = false;
};

Дальше – просто делаем это в цикле, перемещая точку p:

for(t = t_in+h;t<=t_out;t+=h){
pt[0] = tp[0] + tv[0]*t;
pt[1] = tp[1] + tv[1]*t;
pt[2] = tp[2] + tv[2]*t;
vtp[0] = point[0]-pt[0];
vtp[1] = point[1]-pt[1];
vtp[2] = point[2]-pt[2];
x = -tmMulVecSc(ddX,vtp);
y = -tmMulVecSc(ddY,vtp);
z = -tmMulVecSc(ddZ,vtp);
F = F_xy;
if(z<F){ // сейчас внутри
if(!in){ // были снаружи
break;
};// были снаружи
}else{ // сейчас снаружи
if(in){ //были внутри
break;
};//были внутри
}; // внутри/снаружи
}; // for t_in ... t_out
if(t>=t_out){
break; // никакого пересечения не было
};
// на данный момент t – это расстояние от точки tp до точки пересечения
// фактически точка на расстоянии t уже после пересечения с плоскостью, поэтому
// в качестве точки пересечения берем t-h
t-=h
collision_pt[0] = tp[0] + tv[0]*t;
collision_pt[1] = tp[1] + tv[1]*t;
collision_pt[2] = tp[2] + tv[2]*t;

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

3. Определение освещенности точки.

В рамках этой задачи мы не будем заморачиваться с источниками света – будем считать, что у нас один источник и он расположен непосредственно за «глазом». В таком случае расчет освещенности сводится к простому определению нормали к поверхности. Чем меньше значение проекции – тем темнее точка, так как свет падает под большим углом. Поскольку векторы у нас единичные, значение проекции будет изменяться в диапазоне [0..1], что позволяет просто домножать значение цвета на проекцию и получать нужную картинку.

Итак, вернемся к «простому определению нормали».

Пора наконец определиться с тем, какую поверхность мы рисуем. В коде ранее была конструкция F = F_x; Тут F_x это макрос, в который я подставляю формулу, которую хочу рисовать. Разумеется, в последствии в код можно будет подставить любую формулу, но для примера нужно взять что-то конкретное. Я выбрал такое:

#define F_xy cos((x*x+y*y)/20.0)/(1+(x*x+y*y)/100.0)

Чтобы понимать, что мы хотим увидеть в программе, построим этот график в каком-нибудь инструменте, который это уже умеет:

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

Для примера возьмем двумерный график:

(графики касательных смещены для наглядности)

Функция Y=x^2. Её производная Y'=2x. Соответственно, в точке X=0.5 коэффициент угла наклона равен единице, а в точке 2 – четырем. Из графика видно, что коэффициент угла наклона с обратным знаком показывает угол наклона линии, перпендикулярной касательной. Эта же логика работает и для более сложных графиков. Так же она работает и в пространстве.

Поэтому запишем уравнение поверхности в виде cos((x*x+y*y)/20.0)/(1+(x*x+y*y)/100.0) - z = 0 и возьмем производные по трем координатам:

F'x = ((sin((x*x+y*y)/20.0)*x/10.0)*(1+(x*x+y*y)/100.0)-(x/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))

F'y = ((sin((x*x+y*y)/20.0)*y/10.0)*(1+(x*x+y*y)/100.0)-(y/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))

F'z = -1

Вернемся к коду. Теперь зная точку пересечения и ее локальные координаты – мы можем найти нормаль. Она будет определяться как N[3] = {-F'x,-F'y,-F'z}. Но нужно помнить, что это ее значения в локальных координатах. Чтобы перевести в глобальные – нужно каждый компонент умножить на значение вектора той оси, которой он соответствует:

#define F_x ((sin((x*x+y*y)/20.0)*x/10.0)*(1+(x*x+y*y)/100.0)-(x/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))
#define F_y ((sin((x*x+y*y)/20.0)*y/10.0)*(1+(x*x+y*y)/100.0)-(y/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))
#define F_z 1.0
float Fx = F_x;
float Fy = F_y;
float Fz = F_z;
collision_normal[0] = ddX[0]*Fx+ddY[0]*Fy+ddZ[0]*Fz;
collision_normal[1] = ddX[1]*Fx+ddY[1]*Fy+ddZ[1]*Fz;
collision_normal[2] = ddX[2]*Fx+ddY[2]*Fy+ddZ[2]*Fz;

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

Shade = 255.0f * MulVecSc(collision_normal,tv);
if(Shade < 0)
Shade = -Shade;
r = Shade * rgb[0];
g = Shade * rgb[1];
b = Shade * rgb[2];

Оценим результат:

Сменим формулы:

#define F_xy 0.3*(sin(x)*cos(y/2.0)+cos(x/2.5)*sin(y/1.5))
#define F_x -0.3*(cos(x)*cos(y/2.0)-sin(x/2.5)*sin(y/1.5))
#define F_y -0.3*(-sin(x)*sin(y/2.0)+cos(x/2.5)*cos(y/1.5))

Ок.

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