⚙️Log #8

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

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

Ссылка: https://webglfundamentals.org/webgl/lessons/resources/webgl-state-diagram.html

⚙️Log #9

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

В общем, у нас есть экран HD 1920x1080.

WebGL в свою очередь рендерит все что помещается в диапазон от -1 до 1 как по X, так и по Y. Все что за пределами - не попадает в зону видимости. Собственно это clip space (пространстве отсечения).

Так вот, чтобы от рендерить экран - нам нужно его нормализовать. Это значит чтобы мы позиции точек по ширине в диапазоне от 0 до 1920 (видимый диапазон) - преобразовали в диапазон от -1 до 1 и тоже самое нужно сделать по высоте.

Для этого необходимо наши позиции точек разделить на наш размер экрана Screen (1080, 1920). Ну типа два вектора поделить между собой.
Например у нас точка на нашем экран P1, находится в таких координатах (200, 200)

Поэтому для преобразования в диапазон от -1 до 1 (нормализовать), нужно сделать P1 / Screen = (200 / 1080, 200 / 1920) = (~0,18, 0,10).
Результат округлил, чтобы не писать много цифр, но и webgl умеет тоже округлять качество значений с плавающей точкой через precision в шейдере.

Так вот, мы получили нормализованные координаты, но прикол в том, что они находятся в диапазоне от 0 до 1. Получается что наши позиции точек будут нахдоится где-то сверху в правой части экрана. Почему? Ну потому что webgl рендерит область от -1 до 1 и центр у него находится ровно в (0, 0). А так как у нас нормализованные координаты находятся от 0 до 1, то это справа сверху.

Здесь я не мог понять, потому что не хватало теоретических знаний, но до меня дошло, когда я начал рисовать это дело.

Так вот, помимо того, что у нас нормализованные координаты сверху справа, так они еще и в два раза меньше нашего экрана в конечном итоге.

Чтобы привести в нужный вид, нам необходимо сначала заскейлить это дело, ведь не гоже наши точки уменьшать, для этого нужно умножить на x2 и нормализованные координаты выйдут в диапазон от 0 до 2. Берем нашу нормализованную точку: P1 * 2 = (~0.18 * 2, ~0.10 * 2) = (~0,37, ~0,20).

Ну вот, теперь нормально. Однако, если координаты точки были бы больше 1, то в данный момент webgl их бы не от рендерил за пределами видимой области (clip space).

Теперь нам нужно сделать смещение / перемещение. Собственно так как у нас все находится по прежнему в правом верхнем углу экрана, то нам нужно это сместить ровно на 1 влево и на 1 вниз, потому что наш диапазон теперь от 0 до 2. Берем нашу нормализованную и отскейленную точку: P1 - 1 = (~0,37 - 1, ~0,20 - 1) = (~-0,63, ~-0,79).

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

Как нам это провернуть? Ну тут все тоже просто, достаточно умножить наши координаты точек на инверсивный вектор. Например сейчас у нас в левом нижнем углу, значит нам нужно поменять только позицию по высоте, отразить их. Для этого берем вектор (1, -1), где X будет 1, потому что нам не нужно менять позиции по X, но будет -1 по Y, чтобы отразить все координаты. P1 = (~-0,63, ~-0,79) * (1, -1) = (~-0.63 * 1, ~0.79 * -1) = (~-0,63, ~0.79)

А вот собственно и весь шейдер данной операции:

#version 300 es;

precision mediump float;

attribute vec2 a_position;
uniform vec2 u_resolution;

void main() {
    v_color = a_color;

    vec2 n_position = a_position / u_resolution;

    vec2 sn_position = n_position * 2.0;

    vec2 clip_space = (sn_position - 1.0) * vec2(1, -1);

    gl_Position = vec4(clip_space, 0, 1);
}

P.S. На скрине все в кучу, но это было очень эффективно :D

⚙️Log #10

Было интересно создавать объект для управления цветом. Раньше понимал как оно устроено, но сам никогда не делал этого.

Базово реализовал:
- Работа с 10-тичными значениями от 0 до 255
- Перевод 10-тичных в нормализованные значения от 0 до 1
- Работа с hex (rrggbbaa)
- Трансформация цвета в Uint8Array и просто Array для удобства взаимодействия при рендеринге.

Вот простенькая реализация для работы с hex:

public static fromHex(rrggbbaa: string): Color {
    let hex = rrggbbaa.trim();

    hex = hex.replace('#', '');

    const r16 = hex.substring(0, 2);
    const g16 = hex.substring(2, 4);
    const b16 = hex.substring(4, 6);
    const a16 = hex.substring(6, 8);

    const r0255 = Number.parseInt(r16, 16);
    const g0255 = Number.parseInt(g16, 16);
    const b0255 = Number.parseInt(b16, 16);
    let a0255 = Number.parseInt(a16, 16);

    if(Number.isNaN(a0255)) {
        //Set default alpha value
        a0255 = 255;
    }

    return new Color(r0255, g0255, b0255, a0255);
}

В планах сделать еще поддержку HS[V/L] и обратно, хочу поэкспериментировать с этим делом, а будущем можно будет юзать для систем градиентов и каких-нибудь эффектов.

HSV (Hue, Saturation, Value) удобен для работы с оттенками. Например, можно быстро сделать цвет ярче или темнее, просто изменяя V.
HSL (Hue, Saturation, Lightness) часто используется в графическом дизайне, так как L (светлота) позволяет легко контролировать пастельные оттенки.

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

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

⚙️Log #11

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

Что успел сделать:
- Поправил систему сборки, чтобы удобнее было тестировать.
- Реализовал систему Scene -> Node -> Component
- Написал базовую систему работы с ресурсами, что бы уже хоть что-то загружать и использовать.
- Создал компонент для рендеринга спрайтов. Реализовал возможность установки спрайта и выбора цвета (пока логику шейдеров для спрайтов обернул в материалы).

Что изучал:
- Ознакомился с Batch Rendering. Сейчас думаю, как интегрировать это в текущую систему.
- Просмотрел видео о 2D рендеринге, что оказалось очень полезным.
- Наткнулся на интересный блог Sean's GameDev, который рассказывает о геймдеве и затрагивает темы разработки движков.

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

P.S. Начал параллельно делать на этом движке Flappy Bird, иду так скажем целенаправленно. Начинаю что-то делать и вижу что не хватает этого или это работает не удобно и так далее. На скрине можно увидеть первый в мире спрайт, созданный через vecxy!

⚙️Log #12

Спрайт, над которым теперь можно делать преобразования — скейлить, вращать и менять позицию.

Для этого я немного углубился в основы работы с матрицами, изучил как их умножать, складывать, умножать на скаляр и прочее. Осознал, насколько важно правильно работать с матричными операциями, чтобы точнее контролировать трансформации объектов в пространстве.

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

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

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

В этом туториале очень качественно эти преобразования объясняются и визуально демонстрируют в софте Nuke Studio. Сегодня себе его установил, чтобы по CG всякие штуки визуально закреплять.

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

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

⚙️Log #13

Это первая птица-иконка, которая научилась двигаться в этом движке!

⚙️Log #14

Ну это уже выглядит неплохо, почти готовый Fappy Bird! В целом если еще разработать систему коллизий, то этого будет более чем достаточно, чтобы полностью реализовать данную мини игру.

⚙️Log #15

🟢 Начал делать простенькую либу для создания дев-интерфейса. Для отображения какого-то поля, достаточно повестить декоратор и оно будет выведено в общий контейнер для редактирования. (все это на уровне DOM)

Примерно вот так:

@property(NUMBER, SLIDER, -10, 0) 
private _ground_speed = -2;

В целом мне с этим работать удобно, так как очень быстро можно выводить параметры, однако сама реализация мне не нравится, пока что думаю как можно создавать кастомные компоненты и прикручивать к ним стили. На данный момент думаю делать через innerHTML + DOMParser, но тоже весьма сомнительно. В любом случае это пока только для тестов, потом начну думать над каким-то редакторским инструментарием.

🟢 Сделал анимацию для птички, чтобы у нее крылья шевелились. Пока что в тупую в компоненте самой птицы, думаю потом вынести это в отдельный компонент для анимаций. Очень простое решение, где каждые N фреймов будет происходить переключение спрайта. В будущем хочу подумать над интеграцией Spine или Dragon Bones (но тут похоже полная жопа будет, так как посмотрел как это делали Cocos или Phaser, то это сложная таска и буду над ней долго страдать)

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

🟢 Еще немного оптимизировал текущий рендеринг спрайта. Раньше каждый кадр рассчитывал данные для вершин (позиция + uv), потом понял, что достаточно это делать только при установки спрайта, так как дальше они не пересчитываются, им это и не нужно. Все остальное делает уже ортографическая матрица проекции и матрица преобразования.

Что планирую делать дальше:
1. Сделать объект камеры и в нем сделать view матрицу, чтобы уже относительно камеры строить проекцию.
2. Сделать компонент для анимаций в виде spritesheets
3. Подумать над логикой стилей и создание компонентов для дев-интерфейса + сделать группы и более удобный апи для этого дела.
4. Начать думать над системой коллизий
5. Сделать ограничения для мира птички, чтобы она не вылетала за границы и могла стукаться о землю.
6. Сделать трубы, которые двигаются справа на лево и о них можно врезаться.

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

И еще, чуть не забыл упомянуть. Движок все таки в будущем (Когда освою базовые вещи с 2D) не будет сконцентрирован на 2D играх, так как я не фанат подобных игр, а если я играл во что-то, то это очень большая редкость, потому что меня тянет больше в 3D игры и это основное что я потребляю как игрок. А так как движок в первую очередь - это инструмент для разработки игр, то мне бы хотелось именно вести его в этом векторе.

⚙️Log #16

Мне тут мемчик создали в честь др, сохраню для истории.

P.S. Если что, там я читал правила для the binding of isaac настольная игра