Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.

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

И самое интересное заключается в том, что так было не обязательно.

И тут интересно вспомнить XIX век. Тогда математики как раз ломали головы над тем, чтобы придумать нормальный универсальный язык для описания пространства – не мелочиться кучей частных формул на каждый случай жизни. William Rowan Hamilton придумывает кватернионы: компактный инструмент для вращений в пространстве, который становится сегодня основой всей компьютерной анимации (даже те же Unity и Unreal ими внутри манипулируют).

Параллельно Hermann Grassmann выносит мозг коллегам идеей: почему бы алгебре не оперировать сразу плоскостями и объемами целиком? Ну действительно: мы привыкли складывать числа и векторы, а как быть с более сложными сущностями? Дальше подключается William Kingdon Clifford, собирает всё это в одну систему – получает Геометрическую Алгебру.

По сути, Клиффорд пытался создать универсальную операционную систему для геометрии.Но индустрия пошла другим путем.

Когда физикам и инженерам понадобилась удобная математика для электромагнетизма и механики, Josiah Willard Gibbs и Oliver Heaviside взяли идеи Клиффорда и разрезали их на части. Из цельной алгебры были извлечены только самые прикладные куски – скалярное и векторное произведения. Так появился привычный нам vector calculus, который сегодня преподают во всех технических вузах и используют почти все графические API.

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

Она дает вектор, перпендикулярный двум другим. На ней построены нормали, вращения, ориентация треугольников и половина графического пайплайна. Но есть неприятный нюанс: эта операция нормально существует только в трехмерном пространстве. В двумерном мире полноценного векторного произведения нет вообще, а в четырехмерном результат уже перестает быть обычным вектором. То есть одна из фундаментальных операций всей 3D-графики – это математический хардкод под конкретное число измерений.

Клиффорд предложил гораздо более общую идею. Вместо отдельного скалярного и отдельного векторного произведения он ввел единую операцию:

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

Первая часть привычное скалярное произведение. Число. Ничего нового. А вот – это внешнее произведение Грассмана. И его результатом является не вектор, а новый геометрический объект – бивектор.

Бивектор очень трудно понять, если смотреть на него через призму привычной линейной алгебры. Нас с детства учили, что результат взаимодействия двух векторов – это либо число, либо еще один вектор. Но Грассман предложил мыслить иначе. Если два вектора натягивают параллелограмм, то естественным результатом их комбинации должна быть сама ориентированная площадь этого параллелограмма. Не стрелочка, торчащая перпендикулярно плоскости. А сама плоскость.

Бивектор хранит площадь и ориентацию обхода. По сути, это элемент поверхности. Вот тут у многих мир переворачивается: оказывается наше привычное векторное произведение («дай-ка найду нормаль к плоскости») – это такой засекреченный хак ради удобства старой учебной математики! Мы подсознательно заменяем настоящую плоскость перпендикулярным ей вектором просто потому, что так проще считать по старинке. Но Геометрическая Алгебра говорит: зачем вообще выбрасывать информацию о самой плоскости?

А затем появляется самая странная и одновременно самая мощная концепция – мультивектор. А дальше начинается магия серьёзной математики. Стоит расширить наше 3D-пространство до пятимерного (!) за счет двух спец-направлений – одно станет отвечать за начало координат вселенной, другое символизирует бесконечность во всех смыслах слова. Получаем Conformal Geometric Algebra (CGA): звучит максимально экзотично и сначала похоже на сугубо теоретические упражнения… Но вот что удивительно: CGA позволяет описывать сферы, окружности и прочие объекты как такие же элементы своей алгебры так же естественно, как вы оперируете обычными точками или прямыми.

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

Для программиста это звучит почти еретически. Представьте движок, в котором Plane, Sphere, Ray и Lineперестают быть независимыми структурами и становятся вариациями одной и той же геометрической сущности. Но самое важное начинается дальше.

Сегодня практически любой физический движок содержит десятки специализированных функций:

IntersectRaySphere()
IntersectRayPlane()
IntersectSphereSphere()
IntersectCapsuleTriangle()

Каждая написана отдельно. У каждой свои edge cases. В каждой свои проверки на epsilon, вырожденные случаи и численные артефакты.

В CGA идея совершенно другая: пересечение – это не набор специальных алгоритмов, а базовая операция самой алгебры. Вместо огромного набора формул появляются универсальные операции вроде внешнего произведения или операции Meet. Геометрия начинает выглядеть не как коллекция инженерных костылей, а как цельная система преобразований. Еще более радикально это проявляется в трансформациях.

Современная графика использует целый зоопарк представлений. Повороты кодируются кватернионами. Переносы – матрицами. Масштабирование – другими матрицами. Для анимации часто добавляются dual quaternions. Внутри движка постоянно происходит конвертация между разными представлениями одной и той же геометрии.

В CGA все это заменяется единым объектом – ротором. Любое преобразование записывается одинаково:

И неважно, что именно делает RR. Если он кодирует вращение – объект повернется. Если перенос – объект сдвинется. Если масштаб – масштабируется. Формула остается одной и той же.

Для человека, который годами писал графический код, это выглядит почти незаконно. Особенно впечатляет то, как меняется сам стиль программирования. Например, в библиотеке clifford код начинает напоминать скорее школьную геометрию, чем традиционный graphics programming:

from clifford.g3c import *

# Создаем две точки в конформном пространстве
point1 = up(eo + 1*e1)
point2 = up(eo + 5*e1)

# Линия - это просто внешнее произведение двух точек и бесконечности
line = point1 ^ point2 ^ einf

# Сфера с центром в point1 и радиусом r
r = 2.0
sphere = point1 - 0.5 * (r**2) * einf

# Ищем пересечение линии и сферы. ОДНА СТРОЧКА!
intersection = line.meet(sphere)

В этом фрагменте почти шокирует отсутствие привычных вещей. Нет матриц. Нет ручной тригонометрии. Нет вызовов cos() и sin(). Нет километров условий вроде if(dot < 0). Код начинает выражать не алгоритм вычисления, а саму геометрическую идею. Именно поэтому многие люди, впервые столкнувшиеся с GA, испытывают странное чувство. Возникает ощущение, будто вся современная 3D-графика десятилетиями решала геометрические задачи окольным путем.

Но тогда возникает очевидный вопрос: если Геометрическая Алгебра настолько красива, почему индустрия до сих пор массово не перешла на нее?

Потому что у этой красоты есть цена. Главная проблема – производительность. В конформной алгебре мультивектор в 5D содержит  коэффициента. Для сравнения: обычный Vector3 хранит всего три числа. То есть даже простая точка внезапно становится огромной структурой данных. Для CPU-кэша и особенно для GPU это настоящая катастрофа.

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

Есть и другая проблема – психологическая. Геометрическая Алгебра требует полностью перестроить мышление. Разработчик должен отказаться от привычной модели вектор + матрица + кватернион и начать воспринимать геометрию как единую алгебраическую систему. Это не просто новая библиотека. Это почти смена языка мышления.

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

Самое интересное, что индустрия может прийти к Геометрической Алгебре не через университеты, а через компиляторы. Уже появляются генераторы кода, которые умеют анализировать мультивекторы на этапе сборки, выкидывать нулевые коэффициенты и превращать красивые абстрактные формулы в очень эффективные SIMD-инструкции. То есть разработчик пишет чистую геометрию, а компилятор превращает ее в быстрый машинный код.

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

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

Всем спасибо за внимание!

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩