А прямо сейчас можно послушать нашего технического директора Сережу с актуальным докладом) https://youtu.be/oVmhxqpZlfI Минут 5 назад началось, по открытой ссылке

Всем привет! Меня зовут Миша, я креативный фронтенд-разработчик в команде Red Collar, и на этой неделе мы с вами погрузимся в удивительный мир трёхмерной браузерной графики.

В качестве краткого предисловия могу сказать, что из-за ограничений, которые на нас накладывает браузер с одной стороны, и возможностей, которые нам даёт OpenGL ES, некоторые вещи приходится реализовать совершенно неочевидным образом. Такие кейсы мы с вами и попробуем изучить, а так же немного поофтопим и поугораем. Готовьтесь, будет очень интересно! А я побежал писать первый пост.

Сегодня с вами поговорим, как же геометрия попадает на экран и как работает камера в WebGL.

Проекция в WebGL, или «алло а камера где дядя»

Когда я только начинал заниматься графикой (а точнее, на тот момент еще геймдевом), совсем зеленый и не нюхавший так сказать полигонов, я взялся за движок Blitz3D. Он был настолько прост, что даже для неподготовленного человека взять и собрать сцену было проще простого. Взял пространство, поставил туда камеру, повесил кубик и уже идешь хвалиться родителям, что ты Senior Graphics Developer. 😎 И вот ты приходишь в OpenGL (да, именно десктопный, про WebGL будет чуть позже) и думаешь «ну я уже все знаю, сейчас все быстренько накину, и все как обычно отрендерится!». Но начинающего разработчика графики ждало крупное разочарование.

На самом деле, в низкоуровневой графике вообще нет такого понятия, как камера. Все, что на самом деле умеет WebGL — это растрировать полигоны, переводя их координаты в экранное пространство.
💅🏻 Так как же это происходит, и что для этого нужно сделать?

WebGL представляет твой экран, как трехмерную координатную систему, где X смотрит вправо, Y вверх, а Z-координата направлена из монитора прямо на тебя (одна из самых нелогичных вещей для неподготовленного человека, так как во всех игровых движках Z обычно смотрит вглубь экрана). Если представить это все в виде куба, то его размеры будут от (-1, -1, -1) до (1, 1, 1), когда (0, 0, 0) будет центром экрана, а ребра этого куба будут краями экрана. И для того, чтобы наша моделька отобразилась, нужно всю ее геометрию преобразовать каким-то неведомым образом так, чтобы она вписывалась в этот куб, иначе мы рискуем отрисовать ее за пределами экрана. Я нарочно не упоминаю про Z-координату, так как не очень просто будет с наскока объяснить, что она из себя здесь представляет, но не волнуйтесь, чуть позже мы к ней вернемся.

🪢 Так как же нам обработать модель так, чтобы она оказалась в этом кубе?
На помощь нам придут матрицы (ну, которые математические, давайте без приколов).

Матрицы в WebGL представляют собой массив из 16 дробных чисел, в виде 4х4, в которых содержится информация о повороте, сдвиге и размере. И вот уже читатель начинает догадываться: «то есть нам надо построить какую-то специфическую матрицу, и уже на нее помножить все точки нашей модельки». И это абсолютно верно, с одной маленькой ремаркой — матриц у нас будет не одна, а целых три: матрица проекции, матрица отображения и матрица объекта. Давайте быстренько их и разберем.

#rdclr_frontend #WebGL

Матрица проекции, матрица отображения и матрица объекта в WebGL

🪡 Матрица объекта — это самая простая в объяснении из всех трех. Допустим, у нас есть стул (ну, в реалиях WebGL это будет просто пачка вершин и треугольников, но давайте оперировать человеческим языком). И вот у нас появляется задача: нужно этот стул переставить в пространстве. Что мы будем делать? Правильно, запишем в матрицу объекта значения, на которые нам нужно подвинуть наш стул. Хотите повернуть его на 90 градусов? Правильно, запишем в матрицу данные о размерах. Стул слишком большой? Я думаю, можно не продолжать.

🧵 Матрица отображения — одна из самых неочевидных вещей, как и Z-координата. Казалось бы, если у нас есть камера, почему бы нам ее не направить на стул и поставить перед ним, и вот он успех, но нет. Не забываем, что для того, чтобы модель отрисовалась, нам нужно вписать ее в тот самый куб, который, к сожалению, двигать нельзя. И как же быть? Да очень просто, мы просто возьмем весь наш трехмерный мир и вместо камеры подвинем и перевернем его. Да, звучит странно, но именно так это и работает. Задумайтесь, во всех играх, в которые вы играли, не камера двигается по миру, а мир вращается и двигается вокруг камеры!

Есть небольшой лайфхак: для того, чтобы быстро построить такую матрицу, мы можем сначала построить матрицу, будто бы мы двигаем именно камеру, а потом инвертировать ее. Если коротко объяснить инверсию матрицы в WebGL, она создает копию ваших преобразований, но наоборот. Например, вы увеличиваете стул в два раза, а инверсная матрица будет его в два раза уменьшать. Подвинули вперед? Инверсная подвинет назад и так далее.

🧶 Что же касается матрицы проекции — это одна из самых сложных в понимании матриц. Она делает так, что пространство как бы сплющивается при ухождении в глубину. Именно за счет нее достигается перспектива (это если мы говорим про перспективную проекцию, существует так же ортографическая проекция, но про нее как-нибудь в другой раз). Здесь же я бы рассказал про Z-координату нашего куба и почему она вообще существует, но про это мы поговорим уже в другом посте, про экранные буфферы.

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

#rdclr_frontend #WebGL

Типы конвейеров в WebGL — шейдеры/1

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

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

Так как OpenGL (как и WebGL) является по сути процедурной стейт-машиной, перед каждой отрисовкой нам нужно объяснить ему, что нам нужно, что нет, какие режимы включить и так далее. Когда мы работаем с фиксированным конвейером, общая последовательность действий такая:

- Установить все три матрицы из прошлого поста - model, view & projection.
- Включить текстурирование, привязать текстуру стула.
- Отправить данные о вершинах на видяху.
- Привязать эти данные в отрисовку.
- Настроить светильники.
- Вызвать отрисовку.
- Отключить светильники, отвязать данные вершин, отключить текстурирование.

И вот эта последовательность действий у нас выполняется каждый кадр для каждой модели. Казалось бы, все логично, но фиксированный конвейер накладывает свои ограничения:
💣 1. Мы ограничены в светильниках, максимум — 8
🔮 2. Мы не можем влиять на отрисовку, все растрирование лежит на зашитых алгоритмах
🧿 3. Сложно сделать красиво, в основном приходится прибегать к хакам

И в какой-то момент ребята подумали, и решили: а почему бы нам не дать разработчикам возможность настраивать рендер целиком? Так появились шейдеры (ждите, ща второй пост).
#rdclr_frontend #WebGL

Типы конвейеров в WebGL — шейдеры/2

Если коротко, то шейдер — это маленькая программка на C-подобном языке, которая сначала выполняется для каждой вершины, а потом для каждого пикселя модели на экране, и определяет какой цвет должен быть в этом пикселе.
Благодаря шейдерам нам становится доступен огромнейший пласт эффектов, ведь теперь мы не ограничены растрированием со стороны OpenGL.

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

💛 Вся матричная математика уезжает на видеокарту — не просто так у нее есть compute-ядра, которые считают перемножения матриц в сотни раз быстрее ЦП, тут и выигрыш.
💙 Освещение целиком и полностью ложится на программиста, так как на пиксели, которые выводит шейдер, не распространяется фиксированный конвейер.
💜 Наложение текстуры тоже теперь должно считаться на видяхе, делается очень просто, но мы можем полностью контролировать какой пиксель с текстуры брать для текущего пикселя.
🤎 Мы можем передавать в шейдеры какие угодно данные: как общие, например текущий цвет освещения, так и повершинные, например текстурная координата этой вершины.
❤️ Вершинный и фрагментный (попиксельный) шейдеры могут обмениваться информацией для удобства рендера.

Но лучше всего будет объяснить это наглядно, чем мы и займемся в следующем посте. 👀
#rdclr_frontend #WebGL

Разбираем тени / 1 (простой пример работы шейдеров)

Из-за того, что Blitz3D, с которого я начинал знакомство с графикой, не сильно был способен реализовать какие-либо графические эффекты (а связано это было с тем, что он был довольно старым и использовал под капотом Direct3D 7), меня всегда впечатляли приемы, которые использовали «взрослые» игры, например — тени. 👣

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

На самом деле, чтобы представить и посчитать тени, мы должны подумать немного нестандартно, и представить: «а что бы мы видели, если бы именно мы были солнцем?» Звучит странно, но именно такой подход является ключом к реализации нашего эффекта. Чтобы полностью понять принцип, мы откажемся от наших мебельных условностей и соберем абстрактную сцену, как на картинке. —>

#rdclr_frontend #WebGL

Разбираем тени / 2 (простой пример работы шейдеров)

☀️ За первый проход с камерой нужно поступить немного по-другому: нам нужно поставить ее не туда, где мы хотим, чтобы она была, а именно туда, откуда «светит» солнце.

Мало того, что мы по-особенному ставим камеру, так еще и рисуем не прямо на экран, а в отдельный буфер, который на самом деле является обычной текстурой. Плюсом ко всему, нам не нужен цвет или освещение, нам нужно просто понять, насколько отрисованный пиксель находится далеко от «солнца» — поэтому нам хватит текстуры только с красным каналом, куда мы и пишем расстояние от камеры до пикселя. Если все сделано правильно, мы получим карту теней, или shadow map.

🌪Второй проход — это как раз стандартная отрисовка нашей сцены, но с небольшой оговоркой.

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

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

#rdclr_frontend #WebGL

Про стадии рендера на почитать

В качестве наглядного пособия сколько всего происходит в графике за один кадр, можно изучить отличнейшую статью про стадии рендера в Grand Theft Auto V. 🚗
Хотя игра уже далеко не новая, в сегодняшних реалиях мало что поменялось в подходах рендеринга сцены с отложенным освещением/затенением и экранных эффектов.

#rdclr_frontend #WebGL #read

А вот все то же самое, только уже в виде видоса, с разделением по дроуколлам. 🛴

#rdclr_frontend #WebGL #read

Привет, меня зовут Юля, я frontend-разработчик.
Надеюсь, мои знания и мысли пригодятся кому-то и сейчас, даже в столь сложной ситуации.

🦚 На этой неделе мы с вами поговорим о дизайн-системах для фронтенда, обсудим Component Driven Development и заглянем в Storybook.

Зачем это все?
Современные приложения стали сложнее. Они растут, развиваются и масштабируются, а значит, их нужно поддерживать и расширять функционал. Чем больше приложение, тем проблематичнее это делать.

🕵🏻 Перейду сразу к примеру. (Все имена и персонажи выдуманы, любое сходство считать совпадением)

Представим, что разработчик Серёжа пишет приложение с нуля. Все кажется понятным и простым. Но со временем кодовая база разрастается, заказчик вносит правки, на которые Серёжа не рассчитывал, дизайнер переделал пару макетов, а дедлайн все ближе. Что происходит? «Быстрые» правки и костыли превращаются в снежный ком, который растет вместе с проектом. Проблема? Проблема.

🧑🏻‍🌾 Второй пример. Разработчик Ваня попал в проект, который писал Серёжа. Ваня долго вникает в исходники, пытается что-то изменить в подходе, но это трудно: система негибкая и зависимая. В результате Ваня вынужден подстраиваться под проект, чтобы ничего не сломалось. Работа идет медленнее, трудо- и времязатраты увеличиваются, количество багов растет. Проблема? Проблема.

Думаю, оба примера знакомы многим. Что делать?

🍅 1. Если заказчик дает добро, финансы и время, можно переписать проект. Но это очень редкий случай.
🍒 2. Можно нанять больше разработчиков, чтобы быстрее выполнить задачи. Но это дорого и неэффективно в долгосрочной перспективе.
🥝 3. Можно начать внедрять компонентный подход (CDD) и собирать дизайн-систему для UI — медленно, но верно.

🚀 Самый лучший вариант — использовать CDD с самого начала и стартануть проект с дизайн-системы.

Дальше расскажу, что дает Component Driven Development и как его использовать. Не переключайтесь.

📌 Итак, Component Driven Development

CDD в разработке интерфейсов — подход, в котором вы сначала создаете систему компонентов, а потом собираете из них UI, как конструктор Lego.

Компонент — независимая строительная единица интерфейса. Сам процесс разработки идет «снизу вверх»: от базовых элементов (компонентов) — к блокам (композиции из компонентов), а затем к страницам, из которых собирается проект.

Какие преимущества дает CDD?

✏️ Качество кода.
Подход предполагает фокусную разработку компонента. Вы концентрируетесь на определенном элементе, описываете его интерфейс, все состояния, пропсы, проверяете все сценарии использования.

✏️Простое тестирование.
Тестировать код на уровне компонента гораздо проще и эффективнее.

✏️Скорость разработки в долгосрочной перспективе.
Да, на начальном этапе разработка займет больше времени, в отличие, например, от Page-based development. Но если проект большой или его нужно масштабировать, это получится сделать гораздо быстрее и безопаснее за счет переиспользования компонентов.

✏️ Простота обучения команды.
Если к работе подключается новый разработчик, он быстрее разберется в коде и вольется в проект.

✏️Удобный рефакторинг.
Внося изменения в одни компоненты, вы не сломаете другие, потому что они изолированы.

В результате вы получаете собранный UI kit с чистым, читабельным кодом. Круто, но это все еще не дотягивает до конструктора Lego. Чего не хватает?

🍹Хороший UI — это результат плотной работы дизайнеров и разработчиков. Чтобы спроектировать такой интерфейс, нам нужно создать мост, который объединит усилия команд дизайна и разработки в единое целое. Этот мост — дизайн-система.

О ней я расскажу завтра. А вы пока подумайте, как начать разработку не с хедера или футера)
#rdclr_frontend #product

Дизайн-система для frontend-разработчика
Как будто что-то на дизайнерском. Но нет.

Дизайн-система — это набор компонентов, правил и паттернов проектирования UI.
Это результат совместной работы дизайнеров и разработчиков, единый источник правды в процессе разработки проекта.

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

Что должно быть в дизайн-системе:
🌔 набор стилевых правил - цветовая палитра, шрифты, типографика;
🌓 набор компонентов и блоков интерфейса;
🌒 документация — для каждого элемента есть описание интерфейса, свойств и состояний;
🌑 иерархия — компоненты разделены по уровням.

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

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

🌪 И еще один момент: дизайн-система — не конечный результат, а живой организм. Она растет и развивается вместе с проектом, поэтому у вас всегда будут задачи по ее поддержке.

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

#rdclr_frontend #product

Storybook
(ссылка в конце)

Мы выяснили, что дизайн-система — это часть инфраструктуры проекта, как дизайн-макеты и кодовая база. А значит, было бы неплохо иметь инструмент, который позволяет удобно c ней взаимодействовать: разрабатывать, хранить, документировать и пользоваться.

⚙️ Знакомьтесь, это Storybook. Он позволяет делать все то, что я перечислила выше. Его используют Airbnb, Microsoft, Audi, JetBrains, Atlassian и еще много-много компаний. Он дружит с React, Vue, Angular, Svelte и даже Vanilla JS. Подключить его в проект очень просто, а пользоваться реально удобно.

Для каждого компонента, блока или целой страницы создается история — файл с расширением .stories.js (ts, mdx), который и отвечает за отображение вашего элемента. Storybook собирает все эти файлы и формирует библиотеку компонентов. Он разворачивает в браузере интерактивный интерфейс, где можно посмотреть каждый элемент библиотеки изолированно: как он выглядит, как работает, какие у него состояния и пропсы. И да, со всем этим можно взаимодействовать.

⚗️ Я не буду описывать, как подключить Storybook, потому что у него отличная дока и много понятных демок — они расскажут гораздо лучше. Если коротко: скачали npm пакет, запустили из консоли — все. Дальше все зависит от того, насколько хорошо вы опишете компонент. Придерживайтесь правила: одна история — один компонент со всеми его состояниями.

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

Я думаю, вы уже поняли, что Storybook — крутая штука. Так что я предлагаю не медлить, а пойти и установить! Потыкайте и посмотрите, как он работает: не оторваться! Вот вам ссылка https://storybook.js.org/ и увлекательное занятие на выходные. 😜

#rdclr_frontend #product

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

Для компутерщиков про компутерщиков, так сказать. Так что, если не знали, что посмотреть в выходные — теперь знаете. «SAO» мы сюда включать не стали!

— «BPS» или «Battle Programmer Shirase» — анимешка старая и больше для тех, кто с компьютером на «вы», но дух программирования передан неплохо.

— «Калигула» — действие происходит в месте под названием Мёбиус, где вы будете свободны от ужасов реальности, а любое желание будет исполнено. Управляет пространством виртуальный идол Мю, каким-то образом обретший сознание сознание. Она поет и заманивает людей в цифровой рай. Оттуда — нет выхода в реальность, там — нет понятия возраста и пола, ведь все равны.

— «Виртуальный спецназ» — пятеро опытных хакеров решают решают провернуть последнее совместное дело и разбежаться, однако все идет наперекосяк.

— «Нет игры — нет жизни» — История фокусируется на Соре и Сиро, брате и сестре, репутация которых как безупречных NEET, хикикомори и игроманов породила легенды по всему интернету. Вся их жизнь — очередная «отстойная игра».

Дополняйте список чем-нибудь, что считаете качественным.

Всем привет!
👋

Меня зовут Настя, я middle QA в компании Red Collar, и на этой неделе мы с вами поговорим о тестировании.