WebGL *

В прошлой статье про ГИГАХРУЩ мы показали игру как живой weird-проект: браузерный survival horror / ARPG без движка, ассетов и спокойной жизни.

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

Разберем, как ГИГАХРУЩ устроен под бетоном: один активный клеточный этаж, typed arrays, плоские сущности, WebGL raycasting, A-Life, самосбор как мутация мира, сохранение, ограничения и MESH PASS как render-only объем поверх клеточной симуляции.

Уж казалось бы, онлайн гляделок dxf — пруд пруди. Но кто сталкивался с удивительным форматом dxf знают — сколько вьюеров, столько и вариантов отображения. К тому же, большинство таких гляделок используют бэкенд для рендера. Но зачем, неужели так сложно отобразить 2D‑чертёж в браузере? Насколько это может быть сложно?

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

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

На примере демонстрационного проекта на Rust, WebAssembly и ThreeJS рассматриваю связь между осью вращения, матрицами поворота, комплексными числами и кватернионами, а также показывается, как эти математические конструкции используются для вращения реальной 3D‑модели.

Как я собираю ГИГАХРУЩ: survival horror / ARPG в браузере без Unity, Phaser и ассет‑пайплайна. WebGL/canvas raycasting, procedural textures/sprites/sound, A‑Life, самосбор как мутация мира и миллиарды LLM‑токенов, которые всё равно не компилируются.

Это третья статья из серии про инженерные решения в ONEMIX — моём мессенджере на React Native. В первой я разбирал трёхуровневый кэш сообщений, во второй — реализацию Double Ratchet E2E. Сегодня — про звонки.

Звонки в мессенджере — это та функция, которая работает либо отлично, либо никак. Пользователь привык что WhatsApp/Telegram звонят мгновенно, показывают входящие на заблокированном экране, переживают переключения Wi-Fi/LTE, и работают из фона. Если твоя реализация делает хоть что-то из этого хуже — пользователь это сразу заметит и переключится на "нормальный" мессенджер.

Я потратил несколько месяцев на то чтобы довести звонки в ONEMIX до production-уровня. В процессе пришлось изучить WebRTC изнутри, разобраться с iOS CallKit и VoIP push notifications, и собрать десяток граблей которые в туториалах не упоминают. В этой статье — как это устроено, какие решения оказались критичными, и что бы я сделал по-другому.

Сразу оговорка. Я не использую готовые SDK типа Agora, Twilio, 100ms. У них отличное качество и поддержка, но они не дают полного контроля над процессом — а для мессенджера контроль критичен. Когда звонок не проходит, пользователь винит приложение, а не "SDK от третьей стороны". Плюс готовые SDK стоят денег, которые на раннем этапе продукта лучше направить в другие места.

В моей коллекции лежат фильмы в формате Top-Bottom стереопары. Без 3D-телевизора или VR-очков смотреть их без потерь нельзя. Поляризованные очки и активные затворы на десктопе работают плохо или дорого. Анаглифные красно-синие очки убивают цвет.

Хотелось третьего варианта — смотреть на обычном мониторе, без очков, с минимальным железом. Идея, на которую опирался: head-coupled perspective, известный с 2008 года по знаменитому Wii-демо Johnny Chung Lee. В октябре 2025 бывший инженер Meta Daniel Habib опубликовал True3D — head-tracked Window Mode, где экран ведёт себя как окно в 3D-сцену. У них под капотом MediaPipe FaceLandmarker + iris tracking + off-axis projection matrix + volumetric scene на Gaussian splats. Я попробовал перенести подход на готовую Top-Bottom стереопару из коммерческих фильмов. И тут начались интересные компромиссы.

В статье — технический разбор моей реализации: пайплайн сглаживания трекинга в четыре ступени (EMA + velocity buffer + jump threshold + adaptive scaling), predictive tracker на double exponential smoothing (метод Холта) для компенсации end-to-end лага в 65 ms, фрагментный шейдер на GLSL с view switching и blend zone через smoothstep, попытка извлечения disparity через OpenCV StereoSGBM. Подробное сравнение моего подхода и True3D с таблицей: где в их волюметрической архитектуре получается то, что у меня в принципе невыводимо из двух фиксированных 2D-видов.

Финал — пять документированных проблем (jitter на резких движениях, ghosting в blend zone, потеря половины разрешения, латентность, UV-параллакс vs настоящий off-axis) и шесть открытых вопросов к читателю: про DepthAnything в WebGPU+ONNX, про RIFE/DAIN как view-интерполяторы, про DIBR на compute shader, про принципиальную возможность восстановить volumetric scene из стереопары в реальном времени.

Генератор GLSL-кода для WebGL, позволяющий писать шейдеры буквально на JavaScript с некоторыми условностями, используя все удобства IDE, такие как рефакторинг, подсветка синтаксиса, автокомплит и проверка на ошибки, а в математических выражениях использовать обычные JS операторы: +, -, *, /, =, +=, -=, *=, /=, ++, --.

Orillusion + кастомные шейдеры: полный разбор процесса

Как зарегистрировать WGSL-шейдер, связать его с геометрией, настроить атрибуты и добиться анимации. Разбираем compute-шейдеры для GPU-вычислений и инстансинг на примере пяти вращающихся 4D-тессерактов. Если вам интересно то код и небольшие пояснения ниже.

Начнем с того, как микросервисы могут общаться? На самом деле все просто, сложные приложения могут состоять из нескольких разных микросервисов.

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

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

В данной статье (а возможно цикле статей) речь пойдет о собственной разработке облачного SPA приложения по моделированию пространственных стержневых систем методом конечных элементов с численно-аналитическим решением для инженеров-проектировщиков в основе которого математическая модель Эйлера-Бернулли, вариационные принципы и итерационный метод сопряжённых градиентов применяемый для большеразмерных СЛАУ с разреженной матрицей жёсткости с одной стороны, и JavaScripts экосистема облака, выполненного в стеке Node js, Express js бэкенд части, и React js, MobX, Three js, glsl shaders фронтенд части с другой стороны. Отображение эпюр усилий в пространственных стержневых элементах реализовано на шейдерах vertexShader и fragmentShader. Это позволяет вычислять эпюры для каждого стержня на лету и выполнять отображение графиков (в общем случае полиномов 5 степени) в пространстве мгновенно.

Зачем запускать тяжелый Fusion 360 или ArtCAM, чтобы просто вырезать фланец или прокладку? Я написал свой CAM-процессор на чистом JavaScript и Three.js, который готовит G-code из DXF за пару секунд прямо в браузере.

В статье разбираем архитектуру легковесного инженерного софта: парсинг DXF, визуализацию траекторий на WebGL, алгоритмы оффсетов и опыт парного программирования с нейросетью.

В последние годы спрос на 2D/3D-инструменты в веб-сервисах растет довольно стремительно, технологии развиваются, появляются новые подходы и библиотеки — а вместе с ними растёт и путаница: что где использовать, где грань между похожими решениями и почему у разработчиков часто возникают противоположные мнения?

Так что я решила устроить небольшой тест 2D-решений: посмотреть, на что они реально способны, понять, почему результаты местами вызывают большое удивление, и ответить себе (и вам) на вопрос: а WebGPU вообще зачем?

Спойлер: всё далеко не так очевидно, как кажется.

Так как я не сильно разбираюсь в математике и в геометрии, буду использовать подход графического 3D-программирования, потому что подход, применяющийся там, хорошо подходит и для проецирования четырёхмерных пространств. Поэтому для чтения этого материала рекомендую иметь хотя бы базовые знания о том, как работают матрицы преобразования и как с их помощью точка из трёхмерного пространства преобразуется в точку на экране. Код будем писать на JavaScript с использованием WebGL и библиотеки matrix-gl.

Технологии 3dfx Interactive навсегда остались в истории как символ золотой эпохи компьютерных игр. Их графические ускорители Voodoo открыли эру аппаратного ускорения 3D-графики, а API Glide стал неотъемлемой частью многих культовых игр конца 90-х. 

Сегодня, спустя более трех десятилетий, я попытался вернуть это наследие прямо в браузер — без плагинов и нативных компонентов.

Возникла необходимость зафиксировать опыт с последнего проекта по прокачке производительности картографического сервиса. Так сказать, чтобы 2 раза не вставать при передаче опыта. И начнём с постановки, чтобы сразу определиться с аудиторией, кому мимо, а кому больше узнать как "прожевывать" и отображать на UI от 100К объектов в секунду и не лагать. Ну а кто-то вообще не в танке про картографические сервисы и хочет "на борт".

Что вас ждёт по катом.

1. MapTiler/Maplibre - картографический провайдер и UI фрэймворк для работы с ним.

2. Создание своих слоёв данных на карте.

3. Рендеринг большого объёма данных на WebGL/WebGPU. Начнём от 100К.

4. Оптимизация рендеринга с ручной подготовкой буферов для GPU.

5. Обновление данных слоя в realtime. Начнём молотить от 1M объектов.

6. Сериализация данных в ArrayBuffer для передачи напрямую в GPU.

Привет! Меня зовут Владимир и я создатель МояДоска. Сегодня я поделюсь историей о том почему я решил создать доску, как я ее написал... и переписал, а потом выпустил ее в свет, взял первое место на ProductRadar, набрал тысячи пользователей, и вошел в реестр Российского ПО, а потом...

Хотя я немного разочаровался в web-движке PlayCanvas, после того как его апгрейды поломали мне первый диаблоид - для каких-то очень маленьких легковесных игр он остаётся достаточно хорош. Поэтому для разнообразия реанимировал аккаунт и немного погрузился в программирование на js, написав аркаду (с механикой что-то вроде специфического урезанного BattleCity, но на сфере), где инопланетный космический кораблик летает над некоей планеткой.

Этой статьей я хочу представить сообществу разработку www.ruinsworld.ru, которой, по сути, посвятил пять последних лет жизни. Все начиналось с браузерного сингл‑шутера, потом была не очень удачная и быстро наскучившая попытка в стратегию, после чего я поставил себе, казалось бы, невозможную задачу. Реально ли, используя все эти наработки, построить многопользовательский шутер в браузере, да еще не просто «стрелялку внутри небольшой коробки», а с большим открытым миром и огромным количеством неписей в нем? Чтобы можно было «идти куда хочешь во все стороны и делать что заблагорассудится», как в самых лучших постапокалиптических РПГ?

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

Мы делаем карты 2ГИС реалистичными, чтобы приложение максимально детально отражало город вокруг: чтобы у зданий были не гладкие стены, а настоящий фасад, в парках росли деревья и стояли лавочки, а скульптуры выглядели точно так же, как и в реальности. Такая реалистичность помогает в навигации: гораздо проще сравнивать то, что ты видишь в реальности, с моделью этого здания, а не с гладкой коробкой. Поддержка освещения объектов, которую мы добавили на 2gis.ru — ещё один шаг к реалистичности.

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