Комплексные числа

А раз уж начали про математику, то можно и про комплексные числа поговорить. Сегодня я нашёл совершенно шикарное видео про них. Там всё научно популярно интересно, так что не "отключайтесь" сразу :) Это видео очень круто объясняет связь между комплексными числами и поворотами)

Многие считают, что комплексные числа и их понимание нужны только для каких-то супер-сложных задач. Уравнения Навье-Стокса для симуляции жидкостей, для описания колебаний, деформаций и т.п. Но работая с Unity вы пользуетесь комплексными числами каждый день, даже не понимая их (ну или я надеюсь, что пользуетесь) — это кватернионы. Базовое применение без каких-то зубодробительных формул с рядами и тензорами — это просто повороты.

Углы Эйлера это конечно классно, но у них есть проблемы вроде того, что между ними сложно сделать линейную интерполяцию, сложно их применять на вектора и т.п. А кватернионы отлично для этого подходят. И про них уже так много написано, что даже не хочется повторяться. Например тут. Они в разы удобнее роторов, матриц и углов Эйлера — это по сути главное, что нужно про них знать)

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

Книжка Unity про 2Д

Unity опубликовали у себя в блоге книжку по работе с 2д проектами. Прикольно простое руководство для начинающих https://blog.unity.com/games/our-biggest-e-book-yet-2d-game-art-animation-and-lighting-for-artists И иллюстрации неплохие :)

Cluster-based rendering

Интересные примеры технологий очень похожих на Nanite в UE5. Они как-то прошли мимо меня, но любопытно, как они работают. Конечно они упрощённые, так как там решены не все задачи, которые могут решать наниты, но всё равно прикольно выглядят Unity: https://www.youtube.com/watch?v=28T1UOgiGWw Кастомное решение https://www.youtube.com/watch?v=7JEHPvSGaX8

В целом любопытно, что про кластер бейс рендеринг написано достаточно мало работ, так как поискав по ресерч гейту я нашёл прикольную работу по шейдингу https://www.researchgate.net/publication/289301155_Clustered_deferred_and_forward_shading
и ещё пару работ по теме :) Надо покопаться в теме, думаю много интересного можно накопать :)

Matcap и Unity

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

Забавная обзорная книжка от Unity по всяким инструментам для технических художников. Ничего особо интересного я правда в ней не нашёл, но как некоторая карта "что есть в Unity" может быть полезна) https://resources.unity.com/games/tech-artists-key-toolsets

База математики для игр
Видео

Freya Holmer — очень крутая. Она сделала много крутых ассетов (Shader Forge и Shapes) и в целом многие её проекты, которые можно найти на её сайте, показывают красоту математики в компьютерной графике и играх. Шейдер фордж конечно уже не так актуален, и Фрея перестала его поддерживать. Но тем не менее у неё много прикольных видео, работ и сайд проектов)

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

Часть первая
Часть вторая

Компьютерная графика про математические трюки

На самом деле большая часть работы с шейдерами, VFX, светом и т.п. Это всё математические трюки. Часто смотря на какое-то явление при разработке шейдера или чего-то подобного мы стараемся найти упрощённую математику для него. Когда-то давно я писал серию статей по математике в геймдеве, где через примеры пытался показать применения этой самой математики. Вот для скажем статья с функцией плоской волны. Когда понимаешь концепцию того, что значит "считается в каждой вершине" и "в каждом пикселе" параллельно, то проще понимать как передаются туда аргументы, и как их можно использовать в функциях. Допустим в статье по волне можно представить, что в центре меша у нас есть точка (пивот) и аргументом для функции волны является длинна вектора от пивота до конкретной вершины меша (фаза в уравнении) + время действия эффекта

Поэтому для написания прикольных эффектов полезно понимать некоторые концепции из математики. Но тут конечно в математике есть огромная проблема. Так же как и с чтение того же Рихтера. Рихтера в разы проще читать, когда уже что-то понимаешь в разработке и когда понимаешь зачем он тебе нужен. Я люблю периодически смотреть лекции мфти по вышмату. Они лежат в открытом доступе и очень интересные (на них непростительно мало просмотров) Есть по самым разным темам, и без семинаров конечно усваивать материал сложно, но при желании — можно. И проблема всего вышмата, и всех лекций по нему, что я когда-либо видел. Вышмат всегда идёт от теории, а не от примеров. А с примерами было бы учить в разы интереснее.

Скажем вчера в чатике CG мы обсуждали сферические гармоники. И если посмотреть лекции по этой теме в физтехе, то лучше не надо. Если для вас оператор Лапласа, свёртка функций и т.п. магия, смотреть это нет смысла. И там приводится решение с доказательством абстрактных понятий и абстрактных задач. Но совершенно непонятно "А зачем мне это знать?" Хотя скажем вот эта статья это уже объясняет (если пропустить эльфийский для не эльфов, и почитать описания на английском и картинки) По сути привести примеры из астрономии, компьютерной графики и прочему не так долго. Даже не во время лекции, а хотя бы ссылками на "почитать". Скажем перед лекцией, чтобы на лекции было понятно "зачем это"

Просто я не разделяю позиции многих преподавателей, что "это всё неважно, теория объясняет весь спектр применений". Так как зачем самостоятельно повышать входную планку? Я только через 2 года после начала коммерческой разработки смог нормально читать и понимать Рихтера, через 3-4 года чистую архитектуру как просто "понятную брошуру". Так как у меня уже были насмотренность и опыт на практике. И сейчас тоже самое с вузовскими знаниями. У меня была мат. база из-за моей вышки, но по сути я сейчас часто изучаю всё заново, просто в разы быстрее, так как понимаю, как воспринимать эту информацию. В целом математику самостоятельно изучить можно даже стартуя со школьных знаний, сейчас много открытых источников. Но это конечно будет тяжелее, чем в вузе, потому что информация особо не структурирована в плане порядка изучения)

Клёвый мануал по 2д

Мне сложно называть книги выпускаемые Unity книгами, это клёвые подробные мануалы. И вот тут вышел новый разбирающий эту демку от Unity. Почитать его можно тут, и если вы работаете с 2д, то он очень полезный. Особенно для начинающих мне понравилась картинка со слоями и с разбором, как работает 2д свет :)

Вообще я чёт ничего не пишу про 2д, всё про 3д. Надо будет про что-нибудь в 2д написать, даже про тот же VFX. После следующей статьи подумаю про что можно написать в 2д играх :)

Классная рекомендация по организации 2д анимаций https://youtu.be/nBkiSJ5z-hE Переключать стейты «руками» в разы лучше, чем организовывать граф состояний, когда вам не нужен блендинг и blend tree

Крутой репозиторий с блюром

https://github.com/PavelDoGreat/Super-Blur — старый репозиторий, но всё ещё прекрасный. Неплохо работает на мобильных устройствах. По сути на одной из его старых версий я когда-то делал свой акрил https://www.youtube.com/watch?v=7CtoEqyu3fI Может кому пригодится :) У автора ещё крутой репозиторий с жидкостной симуляцией на вебгл)

Прикольный туториал по электрическому шейдеру на шейдер графе :) https://youtu.be/u9lOaPVtSqg

Поучаствовал в небольшом подкасте по метавселенным (в первой части) https://metauniverse.mave.digital/

Кривые Безье

Чтож, тут тоже мало смысла повторяться, так как есть шикарный ролик. Советую посмотреть. Кривые в целом супер полезная штука очень много для чего, так как благодаря ним помимо того, что описывает Фрея, делается ещё достаточно много разных эффектов в VFX, в процедурной генерации графики и т.п. Кривые Безье по сути частный, удобный и быстрый вид сплайнов. А сплайны уже в свою очередь — это маст хев знание, так как они очень сильно упрощают жизнь в анимациях, в построении уровней и т.п.

— Уже скоро 30, устройся на работу!
— Я и так работаю, мам!

Иногда в продакшене бывает трудно объяснить чем ты занимаешься и что это настоящая работа :)

Инкремент номера билдов

Номера билдов в мобильные сторы. Задавать их руками это какой-то особенный вид удовольствия, а если настроен CI&CD так вообще странно. Я тут на просторах интернетов нашёл полезный скрипт с с автоматической инкрементацией билдов. Я бы конечно его чутка переписал, но в целом даёт понимание, как на препроцессе билда автоматом инкрементить версию и номер билда. Просто в айос дико бесит, когда ты взял, собрал икскод проект, собрал в нём архив, начинаешь заливать в коннект и оно говорит "обнови версию". И тебе надо заново собирать архив)

New Input System и XR

Погорячился я с прекрасностью новой InputSystem. Ну хотя ей всего лишь год, а что такое для Unity год? Как бы было бы удивительно, если бы всё работало хорошо из коробки. Но судя по всему никто этой системой особо не пользуется, и я сейчас просто убил 2 часа на абсолютно великолепную задачу. Но тут нужна небольшая предыстория + моё решение может сэкономить вам уйму времени)

Клавиатурный ввод в VR — это одна из основных проблем. Сколько бы клавиатур не делали они неудобные. Ни с точки зрения копирования откуда-либо, ни с точки зрения печати. Ну это просто неудобный инструмент и не сравнится с функциональностью обычной клавиатуры. И по этой причине я очень часто в VR системах делаю оверлей интерфейс куда выносится вся печать, и интерфейс в VR в котором просто "нажми кнопку". Это очень хорошо зарекомендовало себя по UX во всяких профессиональных инструментах и аналитических системах. Есть просто типа админка в видео Overlay UI.

Меня собственно новую инпут систему заставил попробовать OpenXR, так как сейчас на старой системе казалось геморнее пробросить все инпуты и т.п. И проблема в общем-то даже не в самой инпут системе, а в InputSystemUIInputModule. С ней всё окей. Но Unity не были бы Unity, если бы всё работало. И видимо этой системой в целом в XR мало кто пользуется пока, так как в кейсе выше не работает мышь! Это просто фентези! Короче, так как юнитеки подумали наконец-то решить старую проблему видимо, что поинтеры и канвасы в VR не юзают и обычно пишут либо свои инпутсистемы, либо делают на коллайдерах, они решили сразу это сделать. Проблема в небольшой такой детали "Поинтер может быть только один". Поэтому выбирай, либо мышь, либо XR Controller в качестве поинтера. Правда же? Выбирай?

А вот и нет, у тебя нет такой роскоши, как право выбора. Если у тебя в целом включена поддержка XR контроллеров, то мышь не работает. Поставить приоритет (если у тебя нет в VR интерфейса) так же нельзя. То есть хочешь инпут с контроллеров — забудь про мышь, они ведь тебе не могут быть нужны. Типа фиг с ним, что не поддерживается всё и сразу, хотя ограничение немного непонятное. Но то что даже выбрать нельзя — это кайф. И вот на это я потратил 2 часа своей жизни.

Если кому-то нужен workaround рабочий. В плеер сеттинге ставите поддержку и старой, и новой инпут системы. Кидаете на EventSystem скрипт StandaloneInputModule игнорируя "фикс" и сообщение о том, что ничё работать не будет. Так как если в плеер сеттингах включить обе инпут системы, то ивентсистема с мышью работает — профит.

Всегда интересно смотреть разные VFX Breakdown видео, чтобы "подглядеть" и возможно использовать какие-то подходы и техники в своих проектах https://www.youtube.com/watch?v=GSnRTKswzEc Когда видишь скелет реализованного в целом понятно, как это сделано)

Как я номера распознавал

Математика вещь великая. Есть такая штука, как дистанция или расстояние. Обычно оно воспринимается между координатами, но в целом никто не мешает создавать свои дистанции. Когда-то давно я делал проект, где нужно было распознавать номера автомобилей и сравнивать с тем, что задан в системе. Но неиронная сеть, которой я пользовался возвращала достаточно шумные данные. А мне нужно было при нахождении номера слать нотификацию. И тут я подумал, надо как-то определять, что номера "похожи")

Ввести расстояние удобно чисто по той причине, что можно настраивать "что считается похожим" с точки зрения некоторой точности. Типа возьмём две строки. Если расстояние между ними условные 10 или условные 100, и мы настраиваем какие значения мы принимаем за "правильные". Очевидно, что 100 может получиться менее точным, так как будет группировать в одну больше строк. Вторая причина — удобная визуализация. Распознавания с видео-камеры представляют из себя временной ряд "строка" и кадр. И в данном случае очень удобно можно введя понятие расстояния видеть, как проходило распознавание и по какой "дельте" группировать. Но вернёмся к задаче

Расстояние Левенштейна — достаточно известная штука в компьютерной лингвистике. Определяется, как если сравнивать две строки, какое количество букв нужно поменять, чтобы получить другое слово.
Например kitten → sitting — расстояние 3. Меняем k на s, e в конце на i и добавляем g в конец. Получается 3 операции.
Это было первое, что я попробовал и конечно же оно не работало. Проблема в структуре "шума" нейронки. Левинштейн очень не устойчив к перестановкам символов, что было довольно частой ошибки той нейронки)

Что Левинштейн не подошёл, давайте придумаем своё. Посидев недельку с данными, посмотрев на то, как выглядит ошибка неиронки. Я придумал следующее решение. Нашёл самые часто путающиеся символы, посчитал их количество. Задал им веса таким образом, чтобы сумма любой пары весов не давало какой-то другой вес (простые числа). И дальше просто суммировал символы по весам. Номера case insensitive — так что нужно было сравнивать только символы и числа. Допустим объединив цифры A и H которые неросеть часто путала, задав им вес 1 получалось что номера AA123A и HH123A — это одинаковые номера. Тоже самое с цифрами 3 и 8, то есть AH128H — это тот же самый номер по весу. Это работало лучше, но проблема оставалась. У нас нет расстояния, так как веса из простых чисел дают суммы, которые никак не назовёшь расстоянием) Поэтому это как-то работало, но уточнять смотря на графики не получалось

А что если поместить символы и цифры на круге? Представляем, что мы те же группы символов разместили на единичной окружности, а те которые тоже "путаются", но не так часто, просто постарались поставить соседями на этом круге. А что же является расстоянием. В номерных знаках фиксированное число символов (там есть различия с транспортными номерами, но их проще обработать программно). Поэтому в качестве расстояния мы используем — площадь многоугольника получившегося из точек на этой окружности. И вот это уже работало довольно неплохо)

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