Upd: в комментах написали, что если бы нормаль была нормализованной, как ей и положено, то формула работает. Присмотрелся, вдумался в написанное: и да, получается мы из исходного вектора вычитаем компоненту движения вдоль нормали (проекцию на нормаль), так что наш вектор «ложится» на плоскость.
Ошибка получается у него не в коде, а только в объяснениях происходящего. Думаю, он загуглил формулу без понимания, потому что на его же примере (0.5; 0.5) действительно получается полная ерунда. Объяснял он это всё тоже очень странно и путано, из-за чего я поспешил сделать вывод, что смысла там нет вообще.
Но готов признать, что в данном случае я поторопился с выводами. Код там в порядке, ошибка только в объяснениях. Что всё равно не очень хорошо для тех, кто собрался учить, но всё-таки намного меньшее зло, чем я выставил изначально.
Ошибка получается у него не в коде, а только в объяснениях происходящего. Думаю, он загуглил формулу без понимания, потому что на его же примере (0.5; 0.5) действительно получается полная ерунда. Объяснял он это всё тоже очень странно и путано, из-за чего я поспешил сделать вывод, что смысла там нет вообще.
Но готов признать, что в данном случае я поторопился с выводами. Код там в порядке, ошибка только в объяснениях. Что всё равно не очень хорошо для тех, кто собрался учить, но всё-таки намного меньшее зло, чем я выставил изначально.
Ixxtension
Не так давно я перевёл свой Crunch House на С++ модули. Надо сказать, это та ещё попоболь, даже если проект пока ещё крошечный.
Во-первых, главные вендоры IDE в 2024 до сих пор не договорились какое должно быть расширение у интерфейса модуля. Настроить это всё дело кроссплатформенно и через CMake — это вообще не тривиальная процедура. Но, слава богу, я эту часть полностью скипнул, так как работаю только под виндой и под вижак.
Однако же, я в полной мере вкусил во-вторых: мешать модули и обычные хедеры нельзя. Если ты сделал
В-третьих, почти нереально модулизировать что-то перекрытое макросами, типа directx 12 API. Оно ещё тянет всякие виндовые хедеры, ComPtr и прочие приколы, которые тоже могут с std законфликтовать. В общем, без хаков не обходится.
Я уж молчу про то, что подсветка IDE конкретно тупит и отваливается на модулях. И всяких банальных удобств нет, типа переключения между cpp и ixx файлами. Последнее меня настолько сильно бесило, что я написал VS extension для этой цели. Назвал его Ixxtension, забирайте, если вдруг таким же страдаете.
Тем не менее намерен дальше пилить модулями. Всё ещё хочется верить, что за ними будущее. Надеюсь, что когда-нибудь это перестанет быть редким инопланетным синтаксисом (как trail return type), а станет мейнстримом. Если это случится, то пусть у меня уже будет модульный проект к тому времени. Потому что портировать большую кодобазу это совсем анрил.
Не так давно я перевёл свой Crunch House на С++ модули. Надо сказать, это та ещё попоболь, даже если проект пока ещё крошечный.
Во-первых, главные вендоры IDE в 2024 до сих пор не договорились какое должно быть расширение у интерфейса модуля. Настроить это всё дело кроссплатформенно и через CMake — это вообще не тривиальная процедура. Но, слава богу, я эту часть полностью скипнул, так как работаю только под виндой и под вижак.
Однако же, я в полной мере вкусил во-вторых: мешать модули и обычные хедеры нельзя. Если ты сделал
import std в одном хедере, то будь добр делай так же во всех (в рамках одного транслейшн юнита). Заинклудил 3rd-party библиотечку, которая где-то там внедрах использует vector? Ну всё, каюк: нечитабельные ошибки тебе обеспечены.В-третьих, почти нереально модулизировать что-то перекрытое макросами, типа directx 12 API. Оно ещё тянет всякие виндовые хедеры, ComPtr и прочие приколы, которые тоже могут с std законфликтовать. В общем, без хаков не обходится.
Я уж молчу про то, что подсветка IDE конкретно тупит и отваливается на модулях. И всяких банальных удобств нет, типа переключения между cpp и ixx файлами. Последнее меня настолько сильно бесило, что я написал VS extension для этой цели. Назвал его Ixxtension, забирайте, если вдруг таким же страдаете.
Тем не менее намерен дальше пилить модулями. Всё ещё хочется верить, что за ними будущее. Надеюсь, что когда-нибудь это перестанет быть редким инопланетным синтаксисом (как trail return type), а станет мейнстримом. Если это случится, то пусть у меня уже будет модульный проект к тому времени. Потому что портировать большую кодобазу это совсем анрил.
Умер король. Трое наследников поссорились и разделились на 3 страны. Они договорились, что через 3 поколения их правнуки проголосуют, объединяться ли назад в одно королевство или жить дальше отдельно.
В каждой из стран все 3 поколения была постоянная рождаемость (у каждого в стране одинаковое количество детей, бездетных нет). Все правнуки дожили до голосования. Жители двух стран были единогласно ЗА, а третьего — ПРОТИВ. И получилась НИЧЬЯ.
Злые языки шепчут, что обязательно был инцест. Докажите, что это не так.
В каждой из стран все 3 поколения была постоянная рождаемость (у каждого в стране одинаковое количество детей, бездетных нет). Все правнуки дожили до голосования. Жители двух стран были единогласно ЗА, а третьего — ПРОТИВ. И получилась НИЧЬЯ.
Злые языки шепчут, что обязательно был инцест. Докажите, что это не так.
Тяжёлые выборы #1: чёртовы оси
В разработке своего движка иногда нужно делать такие выборы, которые со стороны кажутся плёвыми и не особо важными, а на деле их не так-то легко и сделать.
Типичный пример — это кодстайл. Любой дурак знает, что не важно, какой он, главное, чтобы он был один и везде. Но обычно такого выбора и нет — мы просто юзаем тот стиль, который уже есть на проекте или в движке. И совсем другое дело, когда перед тобой действительно стоит полная свобода выбора: тебя начинает метать из стороны в сторону, как сумасшедшего. Потому что это повлияет на то, как ты будешь писать код всю дорогу и это будет не данное упавшее свыше, а твоё собственное решение. Хочется сделать удобно, чтобы не жалеть потом.
На самом деле с кодстайлом я до сих пор не определился до конца, но зато, похоже, наконец-то выбрал систему координат. Я трижды менял её, но сейчас, надеюсь, что это уже финальная версия.
1. Изначально я положил XYZ самым привычным для себя образом: Right-Up-Forward. Так было по умолчанию в классическом DirectX, так сделано в Unity и так сейчас у меня на работе (Clausewitz engine). Это также NDC в большинстве GAPI (кроме вулкана), так что это такой крепкий default для 3D.
Но мой движок в первую очередь предназначен для TopDown игр, а Y-up, как известно, не очень для этого подходит. Я уже делал TopDown игру в такой системе координат (Encased на Unity) и это влекло за собой некоторое количество неудобств:
Во-первых, чтобы не заниматься постоянной перестановкой y и z из Vector2 в Vector3 и обратно, боясь рано или поздно опечататься, мне пришлось завести довольно искусственный VectorXZ и использовать везде его. Он абсолютно такой же как Vector2, но с полями xz вместо xy.
Во-вторых, в такой системе координат по-честному вращение вокруг вертикальной оси должно идти по часовой стрелке. Но мы, естественно, пихали z вместо y во все тригонометрические функции и делали вид, что так и надо. У нас всё начинало вращаться против часовой стрелки, как в школьной тетрадке, но вообще это довольно грешноватенько так делать.
2. Первый логический шаг по улучшению ситуацию — это перейти на z-up, как в Blender. VectorXZ больше не нужен. Вращение по честному начинает идти против часовой стрелки. Красота!
Но я не захотел на этом останавливаться. В получившейся схеме меня бесит, что Y-координата моей тайловой карты смотрит на север, и это не совпадает с тем, как работают координаты в TextureSpace и ScreenSpace. Не знаю, как вас, а меня бесят эти бесконечные перевороты текстур по вертикали. Я хочу работать с тайловой картой по правилам GUI: прибавлять Size спрайта целиком в положительную сторону. Потому что когда нужно прибавлять Width, но отнимать Height — это чистой воды дичка.
В разработке своего движка иногда нужно делать такие выборы, которые со стороны кажутся плёвыми и не особо важными, а на деле их не так-то легко и сделать.
Типичный пример — это кодстайл. Любой дурак знает, что не важно, какой он, главное, чтобы он был один и везде. Но обычно такого выбора и нет — мы просто юзаем тот стиль, который уже есть на проекте или в движке. И совсем другое дело, когда перед тобой действительно стоит полная свобода выбора: тебя начинает метать из стороны в сторону, как сумасшедшего. Потому что это повлияет на то, как ты будешь писать код всю дорогу и это будет не данное упавшее свыше, а твоё собственное решение. Хочется сделать удобно, чтобы не жалеть потом.
На самом деле с кодстайлом я до сих пор не определился до конца, но зато, похоже, наконец-то выбрал систему координат. Я трижды менял её, но сейчас, надеюсь, что это уже финальная версия.
1. Изначально я положил XYZ самым привычным для себя образом: Right-Up-Forward. Так было по умолчанию в классическом DirectX, так сделано в Unity и так сейчас у меня на работе (Clausewitz engine). Это также NDC в большинстве GAPI (кроме вулкана), так что это такой крепкий default для 3D.
Но мой движок в первую очередь предназначен для TopDown игр, а Y-up, как известно, не очень для этого подходит. Я уже делал TopDown игру в такой системе координат (Encased на Unity) и это влекло за собой некоторое количество неудобств:
Во-первых, чтобы не заниматься постоянной перестановкой y и z из Vector2 в Vector3 и обратно, боясь рано или поздно опечататься, мне пришлось завести довольно искусственный VectorXZ и использовать везде его. Он абсолютно такой же как Vector2, но с полями xz вместо xy.
Во-вторых, в такой системе координат по-честному вращение вокруг вертикальной оси должно идти по часовой стрелке. Но мы, естественно, пихали z вместо y во все тригонометрические функции и делали вид, что так и надо. У нас всё начинало вращаться против часовой стрелки, как в школьной тетрадке, но вообще это довольно грешноватенько так делать.
2. Первый логический шаг по улучшению ситуацию — это перейти на z-up, как в Blender. VectorXZ больше не нужен. Вращение по честному начинает идти против часовой стрелки. Красота!
Но я не захотел на этом останавливаться. В получившейся схеме меня бесит, что Y-координата моей тайловой карты смотрит на север, и это не совпадает с тем, как работают координаты в TextureSpace и ScreenSpace. Не знаю, как вас, а меня бесят эти бесконечные перевороты текстур по вертикали. Я хочу работать с тайловой картой по правилам GUI: прибавлять Size спрайта целиком в положительную сторону. Потому что когда нужно прибавлять Width, но отнимать Height — это чистой воды дичка.
3. Чтобы достичь этого, я расположил X на восток, а Y на юг. Получилась довольно упоротая комбинация Right-Back-Up. По крайней мере я никогда такую не встречал. Какое-то время я пытался привыкнуть к такому расположению, но здесь ровно та же проблема, почему я ненавижу систему координат Godot или XNA: Back это положительное направление.
По моему глубокому убеждению, положительными осями должен быть Right, а не Left; Up, а не Down; и особенно, мать твою, Forward, а не Backward. Сколько бы я не смотрел код чуваков, у которых Z+ это back, там всегда какое-то упоротое двоемыслие начинается. То они направление на камеру называют Forward вместо Back, то выворачивают гизмо наизнанку, чтобы синяя палка в негативную сторону смотрела. Словом ты уже не знаешь, чего ждать и кому верить. Да и в целом во всех формулах с участием Z уродский минус появляется, о котором надо постоянно помнить. Лучше его в кодобазу вообще не впускать. Только плюс, только вперёд.
4. И тут (после мучительных качелей туда-сюда), я в итоге пришёл к анриловской схеме Forward-Right-Up. Дефолтное положение камеры становится -90°, но зато исчезает проклятый минус. Бонусом, по умолчанию все объекты становятся ориентированы forward-ом на восток, а не север. Что, типа, более привычно, так как 0° в школьной тетрадке мы рисуем вправо.
Буквально единственный недостаток, который я в этом во всём вижу, это то, что углы будут считаться по часовой стрелке, а не как на уроке математики. Но всё GUI и многие 2D игры зачастую работают с такими углами, и ни у кого жопа не отваливается. Учитывая, сколько других проблем это решает, это довольно малая жертва.
По моему глубокому убеждению, положительными осями должен быть Right, а не Left; Up, а не Down; и особенно, мать твою, Forward, а не Backward. Сколько бы я не смотрел код чуваков, у которых Z+ это back, там всегда какое-то упоротое двоемыслие начинается. То они направление на камеру называют Forward вместо Back, то выворачивают гизмо наизнанку, чтобы синяя палка в негативную сторону смотрела. Словом ты уже не знаешь, чего ждать и кому верить. Да и в целом во всех формулах с участием Z уродский минус появляется, о котором надо постоянно помнить. Лучше его в кодобазу вообще не впускать. Только плюс, только вперёд.
4. И тут (после мучительных качелей туда-сюда), я в итоге пришёл к анриловской схеме Forward-Right-Up. Дефолтное положение камеры становится -90°, но зато исчезает проклятый минус. Бонусом, по умолчанию все объекты становятся ориентированы forward-ом на восток, а не север. Что, типа, более привычно, так как 0° в школьной тетрадке мы рисуем вправо.
Буквально единственный недостаток, который я в этом во всём вижу, это то, что углы будут считаться по часовой стрелке, а не как на уроке математики. Но всё GUI и многие 2D игры зачастую работают с такими углами, и ни у кого жопа не отваливается. Учитывая, сколько других проблем это решает, это довольно малая жертва.
Иронично, но изначально я считал схему Unreal одной из самых упоротых, но по итогу сам к ней пришел.
Но зато я остался верен более нативной для DX левосторонней системе координат. Как видите, microsoft-бой однажды — навсегда microsoft-бой.
Ну и, кстати, забыл упомянуть одну из самых главных киллер-фич левосторонней системы: я правша. А это значит, что когда у меня в руке мышь, левой рукой гнуть пальцы банально удобнее. Впрочем, надо бы обзавестись распечатанной на 3D-принтере гизмой осей.
Но зато я остался верен более нативной для DX левосторонней системе координат. Как видите, microsoft-бой однажды — навсегда microsoft-бой.
Ну и, кстати, забыл упомянуть одну из самых главных киллер-фич левосторонней системы: я правша. А это значит, что когда у меня в руке мышь, левой рукой гнуть пальцы банально удобнее. Впрочем, надо бы обзавестись распечатанной на 3D-принтере гизмой осей.
Проблема праворукой системы координат в том, что даже если определиться, какая ось смотрит вверх, там существует ещё куча вариантов с лево/право и вперёд/назад.
Тим Суини на днях твитнул, что Unreal Engine будет переезжать с координат FRU на LUF. Типа, Right-handed Y-up это стандарт в индустрии. Ну не знаю, насколько это прям стандарт. Тем более именно LUF. По мне так лучше уж RUB выбирать. Он вроде чаще используется в приложениях, если ноги из OpenGL растут.
Иронично, но я в своём движке буду занимать квадрат Анрила теперь в одиночку, хе-хе
Тим Суини на днях твитнул, что Unreal Engine будет переезжать с координат FRU на LUF. Типа, Right-handed Y-up это стандарт в индустрии. Ну не знаю, насколько это прям стандарт. Тем более именно LUF. По мне так лучше уж RUB выбирать. Он вроде чаще используется в приложениях, если ноги из OpenGL растут.
Иронично, но я в своём движке буду занимать квадрат Анрила теперь в одиночку, хе-хе